A small patch file for adding support for the term name in path pattern by defining another local token, e.g. using %tname in addition to %tid. I use the term name as an argument to a photo gallery view, which makes nicer SEO URLs (at least I think so). Since the module is coded to use the l() function the terms with spaces are being properly encoded and the resultant URL seems fine. May I am missing something.

CommentFileSizeAuthor
taxonomyblocks-termname.module.patch64 bytesLarryS

Comments

PixelClever’s picture

PixelClever commented

Hello Larry,
Are you using it in a context where Drupal isn't able to convert the href into an internal path? For standard Drupal taxonomy paths it converts to the term name.

I can see this being useful for situations where the tid can't be converted. Have you tested this with a view that accepts term name arguments to insure that it gets accepted?

LarryS’s picture

LarryS commented
Title: Extra Token for Term Name » Extra Token for Term Name or Vocabularies

Hi Aaron,

Thanks for the reply.

Are you using it in a context where Drupal isn't able to convert the href into an internal path?

No, I am not confronted with a problem like that.

Have you tested this with a view that accepts term name arguments to insure that it gets accepted?

Yes, and it works fine; but, I am a bit new to Drupal, and am still learning Views and the URL setups for arguments. I have not tested across browsers and platforms (I work on a Mac) or with funky characters in term names. Just felt it was better to have the URLs written properly on output (view still works, and extra keywords in links), versus URL being converted on each request.

Similarly, the vocabulary id (or name) could be tokened to allow links for the vocabulary list headers, which appear to not accept any type of custom URL in this version. Can the token module be used for custom URLs when parsing the taxonomy tree(s)?

Side Note: I am using AdvTaxBlocks to populate a term tree for linking to a photogallery view setup. I would like to use it for extensive 'drilling down' through a product catalog in my next project, which would require linking to the main container category, i.e. vocabulary, to load just that vocab's structure in another region. That project will require working with extensive taxonomy (literally, a semi-complete dinosaur taxa).

I prefer hierarchical trees over hidden, fly-out menus, and AdvTaxBlocks works great for that.

Larry

PixelClever’s picture

PixelClever commented
Category: feature » task

"Can the token module be used for custom URLs when parsing the taxonomy tree(s)?"
That's a good question. That would probably be a lot easier than adding option after option with our own tokens if it would work. The only thing I'm not sure of is whether the tokens module is really designed for being called inside of a function that isn't getting its information from the page being currently visited.

It would also probably be a tricky upgrade though since we would have to switch out the existing path patterns.

I'm glad you are bringing this up. This is exactly the direction I want to head with the module. More token options. In fact I have the idea of allowing args() tokens. For instance if you want part of the link to be drawn from arg(1) of the url we could add something like %arg-1.

Rather than just patch the one item you submitted, I'd like to figure out the best way to add these tokens in general and either add a set with %user-id, %user-name, %arg, %vid, %termname etc... or implement the existing token module if possible

Let me know what you think.

LarryS’s picture

LarryS commented

It looks like http://drupal.org/project/menu_token may have some similar code, though it appears to be forcing an override of existing URLs as opposed to creating fresh ones. There is a new Drupal 6 version download at http://drupal.org/node/363742 (bottom of page), but the developer says tokens aren't working yet.

Token module looks somewhat easy to implement, but the question is what will be available to the user for tokens. The http://drupal.org/project/custom_breadcrumbs module (which I installed recently) has a similar problem in that just global, non-node tokens are available, unless you are actually visiting a node (obvious, I suppose). The developer just got it to work with views, too. Since AdvTaxBlocks is building links for a block that can be shown on a variety of pages (or all), you may need to work with multiple means of pulling usable data for tokens.

For example:

Assign args() values, as you described, to new token.module tokens.

Assign the relative id and names of taxa (term, vocab) when working with them programatically to new token.module tokens.

Using the global tokens from token.module and the newly assigned ones, users can utilize the familiar [tokens] style in their path building, and you only have to write one token.module replacement function, with some iteration to take care of random number of possible arguments. You would need to list all available and custom tokens below the Path Pattern field.

Just some thoughts.

LarryS’s picture

LarryS commented

Since blocks can be configured with "Show block on specific pages:", then the full assortment of tokens from token.module is available relative to the loaded page or node. A user of AdvTaxBlocks can freely use those tokens and make sure the custom Path Pattern will work by limiting the block to only paths that make sense for the tokens. Just doesn't look like an easy way to 'find out' ahead of time what tokens those would be. Probably just leave it up to the user to experiment and find out the possibly available contextual tokens, since the 'specific page' could be anything.

PixelClever’s picture

PixelClever commented

The more look at the token module the more I think it is overkill. All we are doing is string replacement and I think we can narrow down a list of useful tokens and implement them with much less overhead than the token module.

My version of the list would be:
%tid
%termname
%vid
%vocabularyname
%arg[1],%arg[2] etc...
%useruid (current user)
%node-uid (uid of the user that created the current page)
%node-type
and perhaps a administration options for creating new tokens that are determined by a user defined callback function or php code.

What do you think? Can you think of any others?

LarryS’s picture

LarryS commented

That seems simpler and more to the point of what a menu should be doing. Between a useful core group of defined tokens and drupal's URL aliases, a user can really make the menu links do whatever.

and perhaps a administration options for creating new tokens that are determined by a user defined callback function or php code.

That sounds interesting. Not quite sure how it would work, but it would be extensible and you wouldn't have to code any more special tokens. And, it would nix the dependency on the token.module.

I'm certainly willing to beta test anything you come up with.

Thanks for working on it Aaron.

PixelClever’s picture

PixelClever commented

I have committed a version to HEAD that has the following tokens:
%tid
%termname
%vid
%vocabname
%useruid (current user)
%nodeuid (uid of the user that created the current page)
%nodetype

I tested it out and it seemed to work fine, however you should give it a spin as well Larry.

I am holding off on adding it to an official release until I get the %arg[1],%arg[2] etc... added (if it is workable).
Let me know what you think.

LarryS’s picture

LarryS commented

I tried it out and it works fine for my usage with the termnames. Thanks!

I haven't tested the vocab id or name since it makes sense to me that that token should be replaced in a link that would be assigned to the vocab names when they are listed as headers in the menu (line 612 in module). Contextually, the vocab heading is different than the term and, I think, should have its own link configuration, separate from those applied to terms.

Vocabs have no link now, and don't show up if there is only one vocab. Maybe they should be user-choose-able as to whether they are shown?

Thanks again for your work on this. I think it is very flexible now, especially when sending arguments to a view.

Larry

PixelClever’s picture

PixelClever commented
Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.