BIKESHED: Token for a term or menu item's entire tree/hierarchy

If it helps to give a realworld example. When I set up the structure of a site I mimic the path structure for book pages with article pages via taxonomy. If my website is about my garden then the hierarchy of the site could be

HOME
-Fruit
--strawberry
--apple
--banana
-Vegetables
--peas
--carrots
-Flowers
--roses
--tulips

So I use url patterns to create top level books Fruit, Vegetables, Flowers that have auto generated urls
/fruit
/vegetables
and child pages Strawberry, Apple, Peas, Carrots that have auto generated urls
/fruit/strawberry
/fruit/apple
/vegetables/peas
/vegetables/carrots
so far so good
but if I want to use the blocks to show info relevant to all particular sections/books OR articles I can duplicate the structure above in taxonomy so that an article eg "Fred wins prize for best Bramleys in show" this would be tagged with 'apples' and have a url of
/fruit/apples/fred-wins-prize-best-bramleys-show
Thus a block about a new apple book could be told to appear on all pages with url fruit/apple/*
without any way to use termpath in D7 I wont be able to use this method and dooesnt look like there is an alternative.
hope this example is of value

Just popping in to bikeshed...

> [term:tree]? [term:tree-path]? [term:parents]? [term:hierarchy]

Out of those, I would say [term:hierarchy] is the clearest.

#2: I think not including the current item in the token makes sense, since it's pretty trivial to add the current term to the end if needed. However, if it was included in the hierarchy token it would make instances where it's not wanted impossible.

I think both [term:parents] and [term:hierarchy] are more self-descriptive than [term:tree].
I visualize 'tree' in the other direction, from the root down with branches rather than the single chain of ancestors.

'Hierarchy' seems a little ambiguous as to whether it will include the current term or not, while 'parents' is more explicit that the current term is not included.
I prefer 'hierarchy' though, as it more clearly indicates that it represents the chain of ancestors (e.g. "grandparent/parent/").
Even though multiple parents are probably uncommon for taxonomy terms, 'Parents' makes me think that it may only list the direct ancestor(s) (e.g. "parent/" or "parent1, parent2").

What about something similar to the way it worked in Drupal 6? Something like [node:menu-path]? I really need this and can't understand how that is missing in the new Version?

Really looking forward for that feature, if it will be the same like in d6 or if the current item will not be included.

When it comes to which term is being used, menu-path sounds good for me, but if there are reasons for other terms I wouldn't mind...

subscribing

Are we moving forward?

Right now this is a showstopper for me and I guess many others.

subscribing

[node:rootline] or [node:menu-link:rootline] ?

But please please hurry! It's not so important how you call it but that it works!

[object:lineage] - idea taken from Hierarchical Select module.

I would prefer a clear distinction from a [term:parent] token that would only contain the singular parent of the node, were such a token to exist.

I like 'lineage', 'ancestors', or 'hierarchy'. I think both 'lineage' and 'ancestors' match well conceptually if you think of terms in parent-child relationships.

----

Array-type tokens sounds like it could be a very powerful and flexible feature.

How would array tokens be dealt with if the join: token is not provided? Would all modules using tokens then have to be aware of alternate token data types?

As well, in what order would the terms be provided in?
taxonomy_get_parents_all() gets terms child to root, which would require pathauto to reverse the array ([term:lineage:reverse:join:/] ?).

Subscribing

Subscribing

Subscribing

My personal preference is hierarchy, though lineage is rather nice too.

As for array-type tokens I pretty much just want to echo #15 by saying that they sound like they'd add a lot of flexibility.

That said, I feel that a separate 'hierarchy' token has merit. Partly because I suspect it'd be easier to implement and thus you could get a solution to this issue committed sooner, but also after array-type tokens have been implemented as a kind of 'shortcut' token to the most common use case.

Subscribing

Subscribing

Sub... I have used termpath-raw in my drupal 6 sites, and am looking to upgrade to D7.

I think there should be a token named Paths and in use you would choose path:term or path:menu etc...

Of course I've only looked at this whole new token system for about a half hour so please take with a grain of salt. I definitely need the termpath available to pathauto to upgrade though.

subscribe

Dave,

There is a whole thread of folks here in the bikeshed thread not wanting to bikeshed, just wanting the functionality, no matter what it is called. Can we just get the functionality? I thought progressless bikeshed color debates were things to avoid, not nurture?

My vote is for [node:parents-path] and [term:parents-path].

UPDATE: To be fair, it looks like the dev discussion is going on here #1047740: Add an [array:*] token type and a [user:roles] token

seconded on all points. [node:parents-path] and [term:parents-path].

Subscribing

Subscribing

At this point with the new array token, they will be [node:menu-link:parents] and [term:parents]. For use with Pathauto they will be [node:menu-link:parents:pathauto] and [term:parents:pathauto] so that each individual item can be 'cleaned' properly with Pathauto.

Will these also work with the entity field tokens (from entity api module)?

The entity api module defines its own tokens so it won't change to follow that pattern.
Shouldn't be any reason they don't 'work' together though.

Dave, is there an ETA on this, or does this already work in some -dev version somewhere? I've been planning to write a separate (non array) module to provide the old tokens, but if this is working in a branch somewhere, I might wait for it to surface.

Another request for an ETA on this. As taxonomy, menu and books are some of the most used modules, these tokens are very important.

subscribe

+1 for [node:parents-path] and [term:parents-path].
Omg, just do it.

I wrote a [node:menupath] token for personal use, might help some other people so I created a sandbox project with the token here:

http://drupal.org/sandbox/beretta627/1199264

Creates paths for this structure:

One
- Two
-- Three
--- Four

one/two/three/four

I also attached it to this post.

I found one solution, [node:menu-link:parent:url:alias]/[node:menu-link:title], from this other post, http://drupal.org/node/962760 . Not sure it solves every issue, but it's a start?

#36 works for me!

#35 works fine so far for me and it's something like this that we need to get in as combinations of existing tokens don't work

Related issue: #962760: Equivalent of [menu-path-raw]

Subscribing

#35 worked for me until I had a menu item using the < firstchild > declaration as a path. Any node I placed under that would not receive the correct menupath alias. Is there a way around this? Having this token function is critical.

Thanks, #36 is working good for me.

Subscribing

Sub. Really need this functionality as soon as possible.

Sub, and also I asked a similar issue it seems here : #1265384: add [node:field_term_reference:parents] for deeper taxonomy trees (just focusing on taxonomy and in my case pathauto which accepts tokens)

Wouldn't the most logical place to offer the taxonomy parents in Drupal 7 be via the tokens for the field that holds the term reference?

For example I could have any number of term_reference fields , within each I already have [node:field_term:parent] and [node:field_term:term] and this offers a logical grouping for X term_reference fields, so extending to [node:field_term:parents] makes sense in regards to terms?

Addendum: Getting my modules mixed up, I got here from a reply from Dave, however I posted my origional query in Entity Api module as it is the module responsible for exposing field:tokens I believe. So its not quite a duplicate but echoes the same base desire or a taxonomy parents token/s.

Can't quite figure out what the status of this is...

So in a drupal 6 site I have this pathauto setting:
[termpath-raw]/[title-raw]

in drupal 7 I can't seem to replicate this... Any help would be much appreciated

Cross-posting what should be the proper solution to this issue
#1266928: Add [term:parents] and [menu-link:parents] array tokens

This worked for me: [node:menu-link:parent:url:path]/[node:menu-link:title]

#47 worked for me...most of the time. Getting random nodes with the node/ and nid in them, but children of those pages have correct urls? Seems like the recursion isn't working too well?

[node:menu-link:parent:url:path]/[node:menu-link:title] doesn't work for me.

Why is there still not a token for this? Already implemented a token just for this case on one site, need it on another site now, seems the only way out at the moment is for everyone to write their own tokens.

Do you have any resources or guides for writing your own tokens, under Drupal 7?

If I had an idea I'd have a crack at a patch next week. Tokens is not something I've delved into under Drupals hood and the module code was quite dence when theres no api/documentation...

Check #1266928: Add [term:parents] and [menu-link:parents] array tokens for a patch that solves this.

I know peeps keeps saying use [node:menu-link:parent:url:alias]/[node:menu-link:title] or [node:menu-link:parents:join:/] but this does not work if your menu does not resemble your taxonomy!

This patch solves one aspect of the problem, not all, I need to track the parent terms on a term reference field that has no relation to the menu.

I'm happy to have a crack at creating a new token, issuing a patch et al. for the term parents, but need a starting point to do so...

I've been breaking my head about this issue for several months now and I finally found a solution that seems to work:

http://drupal.org/node/741914#comment-5025862

In short, I created a custom module that exposes a few extra tokens (which can be used in modules like page title or pathauto). In the code-behind, the tokens are replaced by the full hierarchical taxonomy path of either the node or the taxonomy term (there are tokens aimed for the url and others aimed for the page title).

The actual implementation can be found in the discussion at the linked page.

I hope this might help some people with their own implementations.

Thanks vlacatocc,

I'll check that out, I did ask somewhere (at some point) how to write tokens but got lost in the token modules code! Your module will help me get 'how to' :)

As of today, with the dev version, I finally got the solution I wanted, and what BIKESHED wanted with this:

[term:parent:parents]/[term:parent]/[term:name]

I only have stuff three deep, so can't vouch for it working deeper than that.

Finally [node:menu-link:parents:join:/]/[node:menu-link:title] works for me.

Example:
- page1
-- subpage1
-- subpage2
--- subsubpage1 --> this page shows the full url path: page1/subpage2/subsubpage1
--- subsubpage2
-- subpage3

Thanks for this good working solution!

I'm using this on several D7 sites, [node:menu-link:parent:url:alias]/[node:menu-link:title]

But it's not working on a new one, so I found and used this, [node:menu-link:parents:join:/]/[node:menu-link:title]

This 2nd method is working now on the new site, although I had to go into my Pathauto/URL Alias settings, and tell it to NOT remove the slash (/) from URL aliases, to really get it working properly.

Am I on the right path now? Was the method I was using before still valid, or is that now depreciated?

#35 Works great, but there is a problem. You have to rewrite the .info file as is corrupted. Thanks

You can try my solution http://drupal.org/sandbox/georgemastro/1929944

Is there any solution that can be used with default paths were you don't know if there'll be 2 or 3 parents?

The problem with solutions like #56 is that if you have 2 parents instead of 3 the url will look like

mysite.com///termname

and that is not what we expect.

I use [node:menu-link:parent:url:path]/[node:title] on almost all projects for hierarchical aliases. It works with any number of parents, you just have to ensure parent aliases are generated before child aliases. This seems to work OK with bulk updating.

There are also easy ways to automatically update children aliases when a parent is updated, e.g:

function my_module_menu_link_update($link) {
  $nid = db_query("SELECT nid from {menu_node} where mlid = :mlid", array(':mlid' => $link['mlid']))->fetchObject();

  if (empty($nid)) {
    return;
  }

  if ($link['has_children']) {
    $children = _my_module_get_children($link['mlid']);

    $nids = array_keys($children);
    array_unshift($nids, $nid->nid);
  
    pathauto_node_update_alias_multiple($nids, 'update');
  } 
  else if ($node = node_load($nid->nid)) {
    pathauto_node_update_alias($node, 'update');
  } 
} 
    
/** 
 * Recursive helper function to get all children of a menu item
 *  
 * @param $plids - array of parent menu ids
 *  
 * @return an array of children mlids.
 */ 
function _my_module_get_children($plid) {
  if (empty($plid)) return array();
  $mlids = array();

  $rs = db_query("SELECT mn.nid, ml.mlid, ml.has_children
                  FROM {menu_links} ml
                  INNER JOIN {menu_node} mn ON mn.mlid = ml.mlid
                  WHERE ml.plid = :plid",
                  array(':plid' => $plid));
  foreach ($rs as $result) {
    $mlids[$result->nid] = array(
      'mlid' => $result->mlid,
      'nid' => $result->nid,
    );
    if ($result->has_children) {
      $mlids += _my_module_get_children($result->mlid);
    }
  }   
      
  return $mlids;
}