Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The location tokens are not always available/formatted when using different token-aware modules. For example, when using the auto_nodetitle module, the [location-province_name_0] toekn is not available. Additionally, if you attempt to use [location-province_0], you will get the entire province name (eg. "California"), rather than the province code (eg. "CA"), when initially saving the node. Sub-sequent edits of the node, without changing the location, shows the proper province code. It appears that these tokens are being generated BEFORE the location module has had a chance to clean node->locations.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | location.token_.inc_.diff | 2.05 KB | rwohleb |
Comments
Comment #1
rwohlebHere is a quick patch for this issue. It attempts to perform some normalization when setting token values.
Upon further research, it turns our this issue is caused by the way auto_nodetitle sets the title during the validation stage. It assumes that everything should be in place for node_previews and that any CCK fields will have gone through the 'process form values' step. If the location module moves to just using CCK, this should go away.
Comment #2
Anonymous (not verified) commentedThis has been happening to me too.
I use the variables in my .tpl.php files to print out location information, but sometimes this doesn't work as Robert mentioned above.
I haven't tried the patch yet though...
Comment #3
bdragon commentedHmm, good point. I was assuming that locations had already been loaded, this obviously isn't the case at the time that pathauto has to run.
Comment #4
yesct commentedtagging.
bdragon, did you want to try to work this patch in?
Can someone try to apply the patch and re-roll it against the newest dev version to make it easier for bdragon to work with?
Comment #5
yesct commentedis this a duplicate of #326755: Location CCK tokens not rendering in private messages?
Please try the most recent official release or dev release, many changes have been made. Please do an updated summary of the behavior problem if it exists in the new release, if it is still there, please let us know and change the status back to needs work, or if you re-roll it (http://drupal.org/patch/create) and post an updated patch that applies to the new dev, then make the status needs review. Thanks.
Comment #6
sreynen commentedI'm still having this problem in both 3.1 and 3.x dev. location.token.inc looks completely different than it did in the patch above, but I believe that's still where the problem is. Specifically, pathauto is rejecting the _N tokens location supplies. I've traced the code through the following functions:
_pathauto_validate_pattern_element()
token_element_validate_token_context()
token_get_invalid_tokens_by_context()
token_get_list()
_location_token_list()
When something like "[location-province_0]" is passed through token_get_invalid_tokens_by_context(), it comes up as an invalid token, because it's not listed in _location_token_list(). There doesn't seem to be any accounting for the kind of wildcard tokens location is using. Seem like either wildcard checking should to be added to token_get_invalid_tokens_by_context(), or location should stop using wildcards.
Populating the wildcard replacements as _location_token_values() does won't work in a context like pathauto's admin page where there's no specific node/object to check against.
Comment #7
Timbalord commented#6 same to me
pathauto gives the [location-city_N] as [location-city_N] same with [location-city_0]. I used location as cck field nodetype user in in userprofile.
Comment #8
vishun commentedJust wanted to note that this was working fine for me with [location-city_0] *until* i updated Token module as it kept recommending. So perhaps there's something specific about a recent update that made this stop working, or rather, that's specifically what my situation insinuates.
[EDIT] since i had already changed [location-city_0] to [location-city_N] because pathauto was saying that it was invalid, it wouldnt go back to _0 due to the form validation. the first thing i did was locate this pathauto entry in the database (which was an entry in the variable table) and i changed the database entry back to _0 and now it works just as well as it did before. so perhaps in the meantime if you want to force it to work, try this.
Comment #9
freelockIt looks to me that Token added validation in 1.14, but only for exact matches. So either Location needs to submit a list of all actual location tokens, or the token validation needs to allow the _N pattern.
I wonder how many other modules use this pattern? Just in case there are some, I went ahead and patched Token to support this pattern: #883804: Token 6.x-1.14 breaks location wildcard tokens with Pathauto 6.x-1.4.
Comment #10
legolasboClosing old D6 issues as D6 is end of life