Token module integration

Can you bump these into .dev please mate? It would make it a lot easier for me to test the changes out, I don't have a clue about CVS...

Cheers.

Hmm.... this works, but... :)

The breadcrumbs are now fine, however the tokens now introduce a new issue. If I have created a root node, and section nodes beneath that, I have a nested structure. Obviously my root node relates to the home page.

However, if my home page is called "home", and I use the [fullhierarchytitlepath-raw] token, I end up with correct breadcrumbs, but the paths are like / for home page (obviously) and then for "services" section, I get "/home/services" and therefore "/home/services/service-1" etc.

I'm thinking that there are obviously advantages to having a root node, as you can display the children of the root node *in* the root node. However at the moment, to achieve the site structure with the right paths etc as I've described, the paths don't work, and I would have to delete the root node and use each section node as a root node.

I'm not sure, but I think this might make things more complicated - might it involve implementation of the concept of a "master" root node? Actually, maybe there could be a "default" home parent in the parent drop down? That would then make things more simple to implement I think.

Sorry for throwing more spanners in the works! :P

Edit: addition of the "master" node would also maybe help out with the breadcrumb issue...? Also, the other tokens suffer from the same problem, it's not just the [fullhierarchytitlepath-raw] one.

The home page would obviously be the best candidate for the site root - this is stored in the variable "site_frontpage", as a path string.

Not sure what you have changed here...? I see no impact on the resulting paths. If my home page is called "front" I still get "front" in my paths. Hence, my paths look like this:

front                                          node/1
front/story-1                               node/2
front/story-1/story-1a                    node/4

and they should be like this, as the "front" node is supposed to replace the home page:

front                                          node/1
/story-1                                     node/2
/story-1/story-1a                           node/4

I note that there is no check in the token code to establish whether or not the front segment of the path is the home page, and negate it if that is the case. I can't see how this part of the module will work without either that check (again, against the site_frontpage variable, presumably) or the "magic" node as previously described.

Still an issue here, should have changed the status previously.

AFAIK this is still not fixed - I am not really happy about using this module until this fix is implemented - should be fairly simple, no?

Duplicate of #190168 - and solved there.