[bookpath], [menupath], [*path] tokens not cleaned: aliases without punctuation removed, lower casing, etc.

Tokens that end in 'url', 'path', 'alias' or those words plus the -raw suffix will not be modified by pathauto since they are assumed to be URL aliases already.

Ok we're going to have to specialcase some token names that end with path-raw as the violate the naming convention enforced by pathauto.

subscribing

I've committed a fix to make sure pathauto_cleanstring() is applied to the [bookpath], [bookpath-raw], [menupath], and [menupath-raw] tokens. Those are the only ones I could find that would be affected. [termpath] and [catpath] are not affected since they already apply pathauto_cleanstring() internally.

http://drupal.org/cvs?commit=406132
http://drupal.org/cvs?commit=406134

The fix will be available whenever the -dev releases regenerate, which is always within 12 hours.

I think this is a major bug and should be addressed asap as it breaks sites working with Pathauto 1.3.

The attached patch implements Dave's suggestion from #3.

It's already committed to CVS on both 6.x-1.x and 6.x-2.x.

Marked #880744: latest commits makes [bookpath-raw] not get lowercase or separator as a duplicate of this issue.

Aw, sorry, crossposted.

@Dave Reid:

However, what about the exceptions approach?

Note that if you are using [bookpath-raw] I would highly recommend changing it to [bookpathalias-raw].

two times :)

@platch: That's is the approach that was committed to CVS. You can check out the actual code I committed with the links I put up in #5.

Yeah, I saw it. I was just wondering if making exceptions configurable (as I did in #7) made any sense.

Here is the patch committed in #5 for people needing it NOW :)

Changing title to help others find this issue

Not quite to sure what's going on... comments are saying the problem is fixed, but also saying it'll take twelve hours?

Is the patch (pathauto-881270-14.patch) the fix, or is it that supposed to be temporary?

Not new to Drupal, but definitely new to using patches in .inc files... not sure what to do with the patch, is there going to be a new release instead?

I am experiencing this issue with tokens from the node hierarchy module, [fullhierarchypath], for example. Aliases are no longer being converted to lower case and spaces are not removed. Do I understand correctly that this is this the expected behavior? Is there a particular reason this changed going from 1.3 to 1.4?

@steven_kropp

As I understand it you can use the patch now, or wait for the next dev-release which will be released within 12 hours (which apparently is an automated process). This dev-release will include the patch.

For applying patches yourself (in case you can’t wait for the dev-release) see http://drupal.org/patch/apply.

The development releases that include this fix have been repackaged:
6.x-2.x-dev: http://drupal.org/node/710692
6.x-1.x-dev: http://drupal.org/node/95354

@Dave Reid:

They won't solve the problem cited in #18, I am afraid.

Ok I think we will need to roll back skipping any tokens with the 'path' or 'path-raw' suffix and standardize if your token uses an URL alias, you must use the 'alias' or 'alias-raw' suffix for D6. This will require changing the [node-path] names in Token.module to [node-alias]. Or we can whitelist certain tokens that use the 'path' suffix. I'm not sure how to best proceed.

We absolutely need to decide on a standard for what tokens that use 'path' and 'alias' mean. My thoughts:
node:path = internal Drupal path (e.g. node/1)
node:alias = the URL alias of the Drupal path
node:url = absolute URL of the path (since it is run through url() it is also aliased)

If you need a token that is not an actual path, alias or URL, but you need something that looks like foo/bar/ferzle/omg, what is the common token suffix that should be used? tree? parents? hierarchy? (also see #860082: BIKESHED: Token for a term or menu item's entire tree/hierarchy)

I'm still waiting for a new release. This bugs breaks the module's functionality, but I don't want to use -dev on my production site. It was said a new release would be published yesterday, but it seems that hasn't been done so far. Is this going to happen or should I go back to 6.x-1.3 (which, I think, has security issues)?

subscribe

Because no one's bothered to help solve the larger problem at hand. For such a critical issue to everyone, there has been no response to my comment #22 at all.

The security vulnerability is if you're using the [bookpathalias], [termalias] or [catalias] tokens to display HTML output. If you're only using them to make Pathauto aliases, then you are not vulnerable.

I've applied the patch which works great, except that it's not scrubbing punctuation (at least not apostrophes, like in don't or wasn't). I am using a [menupath-raw] token with one of my content types. Does this bug exist with the new 6.x-2.0 revision candidate?

Subscribe

I have the same problem with a token called [field_alias-raw] as described here:
#882166: Not 'cleaning' tokens after upgrade to 6.x-1.4

6.x-1.x-dev doesn't solve the problem so I went back to 6.x-1.3.

Is there a reason pathauto_cleanstring() can't be applied to all tokens automatically?

No because that the slash character is configurable now. For instance the default for character replacement in pathauto is to remove. If we were to run cleanstring on a [menupath] token like 'Parent menu item/Clild parent item/My node title' would end up like 'parent-menu-itemchild-parent-itemmy-node-title'. The only way forward is to solve #22.

To anyone else posting "I'm having the problem too" comments, they're not helpful at this point, so please don't. Let's focus on solutions at this point. And that requires constructive, valid input.

Subscribe.

From talking this over with Dave Reid. I think for 6.x we should try to take steps that will be minimally disruptive and then fix it "for real" for Drupal 7.

also affects ['content_taxonomy']['termpath-raw']

@_double - you mean from http://drupal.org/project/content_taxonomy ? That module would need to fix it's naming.

Yeah, but I just realized that the token is actually supplied by this patch. http://drupal.org/node/420240#comment-2703168.

It looks like it follows the same naming convention as the standard [termpath-raw]. How should I properly format the token names — [term-path-raw]?

Ok, so patch against 6.x-2.x that will apply pathauto cleanstring'ing to all -path* tokens except for node-path.

#38: 881270-pathauto-stupid-path-tokens.patch queued for re-testing.

subscribe

subscribing.

Subscribing

can someone pls change the title to something like
"Pathauto bulk generating/updating doesn't work - wrong aliases are generated"
as in my opinion present title doesn't reflect the problem to someone who's searching for solution to it and we're getting duplicates

cheers

Updating title to match the problem.

I'm experiencing the same problem after updating.

I tried brainstorming on this more this past weekend and there's more complications. Now that we made the forward-slash a controllable character, we can't reliably use explode('/') on [-path*] tokens. For instance, if I have taxonomy terms named 'animals/pets' and a sub-term called 'cats', the termpath is going to look like 'animals/pets/cats', and will incorrectly get split inbetween 'animals/pets'. This is such a mess.

The only way to fix this is to expect all other contrib modules to have run pathauto_cleanstring() on each segment in its token generation. Which if that's the case then we don't have to process those tokens at all.

Same thing here I rolled back/sideways to 1.x-dev and the problem cleared up. subscribing

subscribing.

subscribing.

subscribe

For example, a Webform page with [menupath-raw].htm:

Title: Coupon
Placement: Primary Links: Homes

Result: Homes/Self%20Qualifying%20Coupon.htm

[menupath].htm:

Result: Homes/Self%20Qualifying%20Coupon.htm

I've noticed some people have a problem with placing .dev modules on their site...

What are the risks or issues involved with that?

Are "Development" modules going to cause future problems, when I update later on down the road?

For me I typically just follow what Drupal report and drush say is available as a stable release. I am more comfortable doing that than throwing on .dev, unless I have read through issue queues.

subscribing

subscribe

subscribe

This is super critical, because using the [menupath] (very very common on all my customer drupal installations) will not be rewritten (no lower case, transliteration at all).

I had to correct all lot of aliases because I updated to 1.4. Please release a new stable version as soon as possible.

I agree with #59. Can the changes be reverted as a minor release? Most people who upgraded because of drush or seeing stable release may not realize this, read the forums, or know to downgrade to 1.x-dev. It would be one thing if this were an obscure module, but its not.

Does the dev release resolve the problem? I just went back to 1.3 since 1.4 broke my setup...

I tried the dev-version and it solved things for our installation (menupath-issue).

I tried installing the dev version, but it didn't help -- I just created a page and the path didn't use the separators. The pattern is: [fullhierarchytitlepath-raw]

The 1.x-dev version from August 13th?

Subscribe. I love using [save-lineage-vid-termpath-raw].

As for #22 and #860082: BIKESHED: Token for a term or menu item's entire tree/hierarchy, I'd drop "parents" and would prefer "hierarchy" (more) or "tree" (less) instead.

I have had problem described first by psmith when I used Token 6.x-1.14 and Pathauto 6.x-1.4 I got for pattern [menupath-raw] this output: "úvod" was title of page and generated url was "úvod" too. But I tested Pathauto 6.x-2.x-dev and same Token version and problem is now like this: "úvod" was title of page and generated url was "vod". It looks like the problem described in title of this topic is solved, but now in devel version is another problem (in short - pattern removes [not substitutes] letters written in local language).

thank you very much. the 6.x-1.x-dev version has resolved this for me both with menupath-raw and bookpath-raw. Much appreciated.

Thanks for the fix in 6.x-1.x-dev. A 1.5 release would be nice so I don't have to explain why a "development version" is running live.

subscribe

The 6.x-1.x-dev version still doesn't clean some tokens : I encounter the issue with [menu-trail-parents-path-raw] as well as the non-raw version [menu-trail-parents-path], which are tokens from the Menu Trails module. They were working fine with Pathauto 6.x-1.3.

Subscribe.

subscribe

subscribe

subscribe

subscribing

Following #66 the attached patches (branches 1.x and 2.x) introduce support for segment cleaning for tokens ending with "hierarchy"/"hierarchy-raw".

This is needed by #867288-5: Pathauto path generation.

Honestly the best approach forward here for D7 is to *stop* using any kind of tree tokens at all. Do not allow them. Enforce use of [mything:parent:alias]/[mything:name]. I'm still at a loss on how to address properly for D6.

@Dave Reid:

Honestly the best approach forward here for D7 is to *stop* using any kind of tree tokens at all. Do not allow them. Enforce use of [mything:parent:alias]/[mything:name].

I ain't sure I follow you: would the [mything:parent:alias] token return a string like 'foo/bar/baz'? If so it seems you are proposing to call those kind of tokens 'parent'. If not how would I get a string with a dynamic number of levels?

I'm still at a loss on how to address properly for D6.

Cannot we agree on a "hierarchy"/"parent"/"tree" suffix to trigger the segment-cleaning mode?

Cannot we agree on a "hierarchy"/"parent"/"tree" suffix to trigger the segment-cleaning mode?

Because we added making the forward slash configurable in the punctuation settings, how do we determine where the segments start and end when the segments themselves have a slash in them (for example, a term named 'cats/dogs')?

Maybe that is a good question to ask. Which is more of a priority: having the ability to convert the forward slash or being able to use forward slash delimited segments?

::

Spent some good time today brainstorming solutions and I think it's been narrowed down to two solutions:

1. Roll everything back. Crappy solution that really doesn't make anyone happy. We'll still have problems down the road.
2. Implement http://drupalbin.com/16075. Basically make an 'API change' that if modules want to provide a tree-style token that should have each segment cleaned up by Pathauto, they need to provide an array value of the segments if $options['pathauto'] = TRUE. This has several advantages with the one downside that this will not work 100% until all modules providing a tree-style token convert to using this.

subscribe

I would vote for solution #1 since #2 would probably take quite some time to reach full functionality again.

@Dave Reid:

I really like solution #2, I'd make only a simple change to it: modules implementing hook_token_values() could return their favorite segment delimiter through the following (or similar) data structure array('segments' => $term_tree, 'delimiter' => ':').

That said, IMHO the right way to proceed here is roll everything back for the 6.x-1.x-dev branch, since there are lots of broken tokens out there right now, and implement #2 in the 6.x-2.x-dev and 7.x-1.x-dev branches.

Edit: Perhaps $options['context'] = 'pathauto' would be more general.

/agree with plach

I think $options['context'] = 'path' is a more generic and still descriptive enough. I'm not prideful enough to think pathauto deserves it's own context ;)

I could go either way on whether we make this change to the 1.x branch. I think it's up to Dave since he's doing the work. My impression is that the most popular tokens affected by this are in pathauto/token module itself and therefore we know we can fix those quickly.

@greggles:

I think $options['context'] = 'path' is a more generic and still descriptive enough. I'm not prideful enough to think pathauto deserves it's own context ;)

In my mind 'context' was a generic value that could be the calling module's name or any other useful info.

My impression is that the most popular tokens affected by this are in pathauto/token module itself and therefore we know we can fix those quickly.

A brief summary of the modules implementing tokens reported here not to be working: Token, Node Hierarchy, CCK, Content Taxonomy, Hierarchical Select, Menu Trails, Menu translation (Node).

IMO we could have a forward compatible solution in the 6.x-1.x-dev branch: i.e. the same code posted by Dave in #86 (I can't access it anymore) without the if branch that prevents the '/(path|alias|url|url-brief)(-raw)?$/' tokens to be cleaned. We could then "break" non compatible tokens in 6.x-2.x-dev.

subscribing

I don't like the idea of each module defining their own context unless it's legitimate. I can only think of a few real "contexts": html, plain text, paths.

A brief summary of the modules implementing tokens reported here not to be working: Token, Node Hierarchy, CCK, Content Taxonomy, Hierarchical Select, Menu Trails, Menu translation (Node).

That doesn't indicate their popularity in usage on live sites. My impression is that the most commonly used tokens are in pathauto and token. CCK is probably next most popular, but even those are confusing to a lot of users. The rest are cases where the modules themselves are not that commonly used so the tokens are probably even less commonly used.

A 'paths' context doesn't really make sense to me because this is a special case that Pathauto only needs an array. Although html and plain text contexts make sense - URLs would just be 'plain text' though I think - in which case it would make more sense to use $options['html'] = TRUE just like we do elsewhere in Drupal hooks. Normally we would never *ever* want that. We can bikeshed this as well: maybe use 'path_array' => TRUE to show it's explicit that fake paths need to return an array. I'm still partial to 'pathauto' => TRUE.

I'm looking into whether this change would break backwards compatibility with 6.x-1.x, but I have a feeling it will be fairly easy to fix the major modules (we can coordinate a pathauto/token release).

subscribing

subscribing

@Dave Reid:

[...] I'm still partial to 'pathauto' => TRUE.

No strong preference about this, it was just a notice.

I'm looking into whether this change would break backwards compatibility with 6.x-1.x, but I have a feeling it will be fairly easy to fix the major modules (we can coordinate a pathauto/token release).

I don't think this would be a great problem too, but we can always rollback the changes for the 1.x branch and give time to module maintainers to get their module working with the 2.x one.

However you decide to proceed I'd love to have the possibility to provide an array of token segments to be cleaned/glued together (as you suggested in #86) even in the 1.x branch. Also having the possibility to specify the glue string would be nice :)

Another consideration: if use an option like 'path_array' => TRUE or 'segments' => TRUE we won't need to make Token tokens aware of Pathauto existence. Theorically any module could exploit that option.

posting to subscribe -
moved to dev version to use menupath-raw, which I use to have child pages in a menu use the parent's body class of "section-xxx" in a zen based theme.

subscribe

subscribing

subscribing

subscribing

Attached are the current patches for both pathauto and token to implement #86-2.

$options was not being accepted by pathauto_token_values so I added that.

Then I got hung up on _token_array_merge which very handily navigates the token tree, looks for tokens that are an array, and squashes the array down to a single string assuming that this is an error.

We could add in logic to that function that looks to see if it's a strpos($token, 'path') !== FALSE token and, if so, allow it to have an array. That doesn't guarantee that it's behaving properly, however, so really we should also test !empty($options['pathauto']).

That would fix the problem but it puts pathauto specific code into token which feels wrong.

Can we use a more generic name for the $options value now? ;)

I think what actually needs to happen is I need to revert the array-checking token merging to an actual requirements check in token.install to actually check if a token is defined twice. token.module shouldn't care *at all* about the return values of tokens. Then there's no pathauto-specific code.

I could post a comment...

I think these are ready to go. They seem to solve most of the problem.

@yan in #29, your situation is weird because the text field is named "alias" so the token is "field_alias-raw" and for the pathauto module it means something important when a field is named like that. I suggest renaming it so that "alias-raw" is not at the end. Something like "field_alias_manual-raw" works fine.

#921988: Move duplicate token check to token_requirements() has been committed to token.module so should make this easier.

#109 has been committed to CVS for 6.x-2.x. Will need to be ported to 6.x-1.x. Likely it will need to be brought forward to 7.x-1.x as well, but there are currently no tokens which require this behavior.

http://drupal.org/cvs?commit=427086

Great! A couple of minor things:

+++ pathauto.inc	24 Sep 2010 21:06:31 -0000
@@ -653,17 +653,20 @@ function pathauto_clean_token_values($fu
+      // The token value is an array if we specified $options['pathauto'] = TRUE,
+      // then we should assume this is a 'segment' URL that should be pieced back

The line wrapping is over column 80.

+++ pathauto.tokens.inc	24 Sep 2010 21:06:31 -0000
@@ -83,16 +83,15 @@ function _pathauto_token_values($type, $
+        ¶

Trailing whitespaces.

Powered by Dreditor.

Follow-up patch to cleanup and revise the inline docs.

Looks good.

Edit: I'll have a last try: what about the following?

$glue = $options['pathauto'] === TRUE ? '/' : $options['pathauto'];
$replacements[$token] = implode($glue, $segments);

The proposal in #116 doesn't look intuitive to me.

Sorry, wrong code, I meant something like:

<?php
$glue = isset($values['delimiter']) ? $values['delimiter'] : '/';
$replacements[$token] = implode($glue, $values['segments']);
?>

subscribing

I swear I posed this already...

Here's a 6.x-1.x-dev patch including the fixes in #115.

+++ pathauto.inc	27 Sep 2010 14:19:22 -0000
@@ -543,9 +543,11 @@ function pathauto_get_placeholders($type
+  ¶

Trailing whitespaces.

+++ pathauto.inc	27 Sep 2010 14:19:22 -0000
@@ -559,24 +561,26 @@ function pathauto_get_placeholders($type
+      // construct an value resembling an URL.

Forgive my english: is "an value" correct?

+++ pathauto.inc	27 Sep 2010 14:19:22 -0000
@@ -559,24 +561,26 @@ function pathauto_get_placeholders($type
+      // Tokens is not an URL, so it should have its value cleaned.

Maybe "Token"?

Powered by Dreditor.

#115 and fixes in #121 committed to 6.x-2.x.

And now 6.x-1.x as well: http://drupal.org/cvs?commit=428186

Thanks, plach!

Based on earlier comments I think this is postponed for 7.x until we have a real problem token there.

I have the drupal 6 dev version and [menupath-raw] is still not getting cleaned. Is there a particular version of Tokens I need to have?

@amak:
Pathauto 6.x-2.x-dev from Sep 24th or later
Token 6.x-1.x-dev from Sep 24th or later

Or Pathauto 6.x-1.x-dev tarball from tomorrow or CVS today.

subscribe

I'm having this bug on a live site after upgrading as well. menupath-raw.
I just tested 6.x-1.x-dev from 2010-Sep-27. It did not work.

Update: Per suggestion in #132, I also upgraded Token to the dev version and now it works.

As per comment in #126, Token 6.x-1.x-dev from Sep 24th or later makes this possible. Cleans previous issues for me.

Latest 6.x-1.x-dev fixed issue that I had with [term-raw]/[bookpath-raw]/[title-raw] token...

@augiem: Can you please re-confirm if you are using the latest 6.x-1.x-dev version of Token as well, otherwise this fix won't work.

@Dave Reid #132: I didn't realize I had to update Token as well. I've done that and now the menupath-raw tokens are working again. I should have read the whole thread I guess. Sorry. Thanks for the quick reply and the help!

Confirming that Token 6.x-1.x-dev (2010-Sep-24) + Pathauto 6.x-1.x-dev (2010-Sep-27) fixed this issue for me. Using Drupal 6.19.

Pattern for all Page paths: [menupath-raw]

I tested with Token dev tarball (Sep 25) and Pathauto dev (Sep 28). Translitteration is on and Pathauto settings is to change aliases to lowercase.

While built-in tokens are cleaned correctly ([title-raw], [menupath-raw]), tokens set by third-party modules are not cleaned at all (for example, [menu-trail-parents-path-raw] from Menutrails module). Will every third party module exporting tokens have to update its code, unless users will get incorrect aliases containing upper-case and non-translitterated characters?

@mdupont
I believe this is the case, all modules that make use of pathauto require updating

Perhaps someone could summarise the API change
And give an example of how to update a module that worked fine with 6.x-1.3 to again work fine with 6.x-1.x-dev from Sep 27th or later

Thanks Network. If modules exposing tokens that can be used by Pathauto require updating, I suggest to put a notice on Pathauto's module page.

Is this confirmed? I need to know so I can add an issue for modules that need to update their tokens.

subscribe

I tried upgrading to the latest PathAuto 6.x-1.x-dev and Token 6.x-1.x-dev releases, but it still isn't replacing spaces and such correctly like it did in version 1.3. I'm using this for my pattern:

[fullhierarchytitlepath-raw]

This is what it did with the path:
/Student%20Resources/Clubs%20%2526%20Activities/Phi%20Theta%20Kappa/test%20test%20page

It should have put dashes where it found spaces.

I'm using the latest release of Node Hierarchy: 6.x-2.x-dev

We need people to file issues with modules providing fake-path tokens to get them to use the new format detailed here.

@Dave Reid

Where is the most complete documentation of the new format?

::

It's fairly simple if the token name includes the word 'path':

Before:

function mymodule_token_values($type, $object = NULL, $options = array()) {
  $values = array();
  $my_token_path_raw = array($object->something, $object->otherthing);
  $my_token_path = array_map('check_plain', $my_token_path_raw);
  $values['mytokenpath-raw'] = implode($my_token_path_raw, '/');
  $values['mytokenpath'] = implode($my_token_path, '/');
  return $values;
}

After:

function mymodule_token_values($type, $object = NULL, $options = array()) {
  $values = array();
  $my_token_path_raw = array($object->something, $object->otherthing);
  $my_token_path = array_map('check_plain', $my_token_path_raw);
  $values['mytokenpath-raw'] = !empty($options['pathauto']) ? $my_token_path_raw : implode('/', $my_token_path_raw);
  $values['mytokenpath'] = !empty($options['pathauto']) ? $my_token_path : implode('/', $my_token_path);
  return $values;
}

If the token name does not include the word 'path' then the token name will need to be changed.

Thanks.

::

Upgrading from 6.x-1.14 to either 6.x-1.x-dev or 6.x-2.x-dev has not resolved my issue with [menupath-raw]. The only way to resolve for me has been to downgrade to 6.x-1.13, which has the security issue. Please advise.

@pianomansam - You must also upgrade Token to the latest dev.

I'm still not really understanding what's going on here. Two months (!) ago there was a new release (6.x-1.4) to fix security issues. But that release broke a good part of the module's functionality, which is why many people (like me) are forced to use the insecure 6.x-1.3. Did the security fix change things that led to the breaking of the module in such simple cases like using a CCK field to create a path? If not, wouldn't it be the best to simply revert those changes to make the module work and then work on the structural changes?

Sorry, but I'm really confused. Now, this issue is even set to 7.x-1.x-dev, "normal" and "postponed" although the latest release for 6.x has critical problems.

(My case is explained in #29)

Reading comprehension ftl.

The security fix was not the problem, it was a combination of bug fixes and feature requests that would have been difficult to roll back and pissed more people off. This has *already* been fixed in 6.x-1.x-dev and 6.x-2.x-dev and we're rolling new releases today.

Yesterday has come out the new Token module. Updating Pathauto and Token to the latest stable release has solved this problem for me.
That said, it is a shame that it has taken THREE MONTHS to sort out this issue, caused by the way by a security fix done in hurry.
It's not possible that EVERYTIME there's an upgrade to do to Drupal, something broke!

I just tried with Pathauto 6.x-1.5 and Token 6.x-1.15 but to no avail: My problem from #29 stays the same. I use a CCK field ("alias") to create the path but

* Spaces are not converted into dashes (the separator)
* Special characters are not replaced at all (should be as defined in i18n-ascii.txt)
* "Reduce strings to letters and numbers from ASCII-96" has no effect

Going back to insecure 6.x-1.3 again.

subscribing

@xeontheme - this is your first comment in the issue and all you have to say is a complaint? You also haven't contributed (in the form of code, documentation, simpletests, money, etc. as far as I can tell) to the improvement of module quality. And yet you expect me to somehow provide you with free services *and* listen to your complaints? Your karma just went down in my book. Note that the GPL comes with no warranty, but I offer a money back warranty on all my modules. If you have a bug I will fully refund the price you paid me for them.

@yan - I answered you already in http://drupal.org/node/881270#comment-3490014 - you seem to be ignoring it. If you change the status again I will see about having your account blocked for inappropriate use of the issue queue. If my explanation is insufficient for you, open a new issue.

Hi greggles, calm down please, I didn't mean to offend you or anybody else. I guess I overread your comment #110 when you posted it, sorry for that. I guess I'll have to rename then, although I don't like it very much.

btw, if there are names that don't work with pathauto, shouldn't there be a warning or a hint? Or did I just not see it?

I've started writing a book page at http://drupal.org/node/936068 to document the standards that Pathauto applies to token names.

updating to pathauto 1.5 and Token 1.15 solved my issues with [menupath-raw] . Thank you !

just remember to delete and regenerate your aliases.

A Big thanks to all contributers above for working out a decent solution! (It fixed the [menupath-raw] alias issue for me..)

Thanks Dave. That means that modules shouldn't 'send' tokens that have the mentioned patterns to Pathauto, right? Now, CCK allows free naming of fields which can easily lead to a situation like mine (naming a field 'alias' or so). What would be the steps to prevent that those fields are treated as 'special' fields? Should the CCK module take care of that, i.e. for example by adding a -cck or whatever? Or would it be a task for the Token module? Or maybe a warning on the Pathauto settings page if such a pattern is detected?

I posted the solution, and someone has taken advantage of it (#155).
That said, I am unsatisfied in the general way in which Drupal is carried along. Your free work is welcome.

Can't remember seeing you contribute the solution..
I also don't understand what you mean by '...the general way in which Drupal is carried along.." ?

@xeontheone #158:
For the sake of clarity: could you be more specific about your dislikes ?

[EDIT] plach #161 is right:
@xeontheone: There is no need to be so cynical, there's a difference between thanking someone for his hard and dedicated work and complaining about it. So i guess, taking plach's comment in consideration, if you have any suggestion on improving things, start working on it.... in another issue.

In another issue, please.

I just noticed that it's not possible to change the machine readable name of a CCK field. That means I have to fix my issue directly in the database? That would leave me very unsatisfied with a production website with a couple of thousands of nodes.

@yan - The answer is to add a new field to the node, do a database level update query, and then delete the old field.

Subscribing

Upgraded Pathauto 6.15 and Token to 6.15, my aliases still aren't changed to lowercase for [menupath] or [menupath-raw].

Is this something I will be able to do with the recent changes? I like to have it set as menupath so the alias looks like path_section_title/parent_page_title/child_page_title.htm.

Is there another token that could facilitate this?

Wait a second... for some reason Drupal still thinks Token 1.14 is installed, even though the files are 1.15 and I've ran update.php.. wonder what happened.

@Kevin: That usually means you have a sneaky version of Token hiding somewhere else. You can check your {system} table for the filepath of the module.

subscribing

subscribing

is not a solution, but i downgrade version to pathauto 1.3 and now if that works

Thanks for the in-depth knowledge passed on here. The karma is great just a couple of entries from those not perceptive of the work and thinking going on here.

I am new here nothing loaded yet just reading the extensive documentation.

As a newbie should I load Pathauto 6 or 7?

I previously had pathauto 6.x-1.5 and token 6.x-1.1.5 but using [hierarchypath] token was not converting spaces to dashes. I didnt check the issues and just upgraded to 6.x-2.0 alpha3 and the problem still persists. Unlike Kevin at #165 my drupal shows the latest token yet still I can't use the [hierarchypath] token. Does [hierarchypath] tokens covered in the updates and bugfixes? or just menu-path?
From the discussion I am I think any token that ends with path keyword should work?

Menupath token seems to be working but hierarchypath is not. Honestly speaking I never know the difference between the two :)
For previous pathauto versions I guess hierarchypath worked for me thats why I used it. Anybody knows the difference?

@Blackstallion: It needs to be fixed in the nodehierarchy module in #883604: Fully supporting and integrating PathAuto and Token.

Yes I just got the hold of the issue and finished reading the node hierarchy issue. Came here to update my post that Its a nodehierarchy issue but you were prompt and replied before me. My apologies, I should research more before posting, Probably the reason why I don't post in issues. Great work Dave!
Regards

is there a way to regenerate all aliases in 6.x preserving the old ones?

if it's nodes, go to admin/content/node, select the nodes that you like to update and select Update URL alias from the select list form to update.

ok. what if there are about 8000 nodes?

If there are hundreds or more of nodes use Views Bulk Operations.

by default, I think it will list only 50 nodes? You either do this for all your 8000 nodes (160 pages) or you may create your custom page using something like VBO.

anyway, I think it's better that you create your own queue regarding your issue or post your question in the forum.

Hi,

I am not entirely sure if I should be posting my question here or in the token issue queue. However, this seems to be the cause for the problem I am seeing. I am fairly new to Drupal and have never build my own tokens. Could someone please clarify the impact of this discussion on custom tokens?

In the site I maintain a custom token is generated in a module. These tokens stopped working properly after the upgrade to Token 6.x-1.15 and Pathauto 6.x-1.5 (punctuation and spaces not removed, not converted to lower case etc.). Below is the code to create a limited menupath (2 levels only). The site uses the workflow module and hence needed some extra checks because workflow influenced the values that some of the functions returned.

function fogs_custom_token_list($type = 'all') {
  if ($type == 'node' || $type == 'all') {
    $tokens['node']['menupath-limitedpath']            = t("The menu path (as reflected in the breadcrumb) to a fixed depth, not including Home or [menu]. Separated by /.");
    $tokens['node']['menupath-limitedpath-raw']        = t("The unfiltered menu path (as reflected in the breadcrumb) to a fixed depth, not including Home or [menu]. Separated by /. WARNING - raw user input.");
    return $tokens;
  }
}

// This fn was originally based on node_token_values() 
function fogs_custom_token_values($type, $object = NULL, $options = array()) {
  $values = array();
  switch ($type) {
    case 'node':
      $node = $object;

      $trail_raw = array();

      // Try to get the menu data.
      $mlid = db_result(db_query("SELECT mlid FROM {menu_links} WHERE link_path = '%s'", 'node/'. $node->nid));

      // Now get the menu related information.
      if (!empty($mlid) || !empty($node->menu['mlid']) || !empty($node->menu['plid'])) {
        $menu_link = menu_link_load($mlid);
        $trail_raw = _menu_titles($menu_link, $node->nid);
        
        // "->workflow" is the state that we are setting it to if we are changing states, and 
        //   "->_workflow" is the state it is already in. 
        $_my_workflow = isset($node->workflow) ? $node->workflow : $node->_workflow;

        // for some reason, _menu_titles() only returns "dir1/dir2/.../dirN" if the node is still in draft.
        //   if it is approved, then it returns         "dir1/dir2/.../dirN/page_title".
        //   So we crop off the last one if approved.
        
        if ($_my_workflow >= 5) {
          array_pop($trail_raw); 
        }

        // Truncate -- limit to 2 directory levels.
        if(count($trail_raw) > 2) {
          array_splice($trail_raw, 2);  // just keep the first 2 entries
        }

      }

      // Make $trail to mirror $trail_raw, in a non-raw way.
      $trail = array();
      foreach ($trail_raw as $title) {
        $trail[] = check_plain($title);
      }

      $values['menupath-limitedpath']     = implode('/', $trail);
      $values['menupath-limitedpath-raw'] = implode('/', $trail_raw);
      
      break;
  }

  return $values;
}

Based on Dave's comment in 142, is it enough to just replace

     $trail = array();
      foreach ($trail_raw as $title) {
        $trail[] = check_plain($title);
      }
      $values['menupath-limitedpath']     = implode('/', $trail);
      $values['menupath-limitedpath-raw'] = implode('/', $trail_raw);
     

with

      $trail = array_map('check_plain', $trail_raw);
      $values['menupath-limitedpath']     = !empty($options['pathauto']) ? $trail : implode('/', $trail);
      $values['menupath-limitedpath-raw'] = !empty($options['pathauto']) ? $trail-raw : implode('/', $trail_raw);
     

or do I need to run something through pathauto_cleanstring() as well?

Sorry about this lengthy post, but with my limited Drupal experience I do not get the full picture of this discussion and would appreciate your help. Thank you.

Had some problems with [menu-trail-parents-path-raw] as well (D6), a working patch can be found here;
http://drupal.org/node/899482

Cheers

Has anyone else experienced this issue for FileField Paths while using PathAuto 6.x-1.5 and Token 6.x-1.15 (and FileField Paths version 6.x-1.4)?

I am using [menupath]. Prior to the security update for PathAuto, my FileField Paths for file attachments would look like:

"animals/cats-dogs/kitty.jpg"

Since the upgrade, a new attachment to the same node is created in a new folder called:

"animals/cats and dogs/kitty.jpg"

Most Pathauto cleanup settings seem to be ignored.

- The letters ARE transformed to lower case
- Separator "-" is ignored, an empty space is shown between the words
- Special characters are not being stripped out as they previously were

This issue started occurring after we upgraded PathAuto to version 6.x-1.5 in late October '10. I assume we jumped right from 6.x-1.3 to 1.5.

We do use Menu Trails on our site, but I wasn't sure if this mattered being we are using [menupath] and not the custom tokens from the Menu Trails module?

Any help or insight is appreciated.