Hi

I've experienced this issue on various projects i've worked on, including a clean install with only the bare essential modules enabled (pathauto, token). I am using the 6.x-1.15 version of Token. I am aware there have been issues with menupath token aliasing recently, but think this may be unrelated.

Steps to reproduce:
- Set a node alias patten to [menupath-raw]
- Create a node with no menu entry (leave blank). The resultant url is a system url, ie node/x
- Update the node and add a menu entry (as many clients do after forgetting to add an entry on creation), and no alias is created. The url is still the system url, node/x
- Go to the bulk alias generation screen and generate aliases. The alias is now created.

I think the cause of this may be that the 'auto alias' checkbox is unticked on the node form when updating. Should it not stay ticked in certain cases such as the one i've described?

Thanks, keep up the good work ;-)
Rich

Comments

As you mention, this is caused by the "Auto alias" checkbox code. and the way that the module checks for a custom alias and tries not to clobber the custom alias. Since your alias (none) is different than what it expects (the menu path token based one) it unchecks the checkbox.

The problem can be stated more generally: change your patterns and you'll see it for all nodes of the type where the pattern was changed.

You're right that the bigger bug is that it should create an alias consistently since you never told it not too.

I've been following #936222: Merge in pathauto_persist module functionality to prevent losing manual aliases with node_save() calls since its beginning and I'm pretty sure that that issue is about remembering the state of the "Generate automatic URL alias" checkbox between successive node edits. So, I don't see how that would solve this issue here (or how it is even related for that matter).

What this issue here aims to solve is this scenario:

1. create a [menupath-*] pattern for a node type
2. create such a node but set it to not have a menu entry
-> result: the node gets the default core path (node/nid)
3. edit the same node again and this time assign it a menu entry
-> result after save the node is assigned a path according to the [menupath-*] pattern

So I think it is clearly related to #1408576: [menupath-*] alias generation/update should be triggered when menu settings of a node or any of its parents are changed. (and perhaps even a duplicate).

@klonos if you read the comment in #1 from @greggles he says "As you mention, this is caused by the "Auto alias" checkbox code.", that is exactly what pathauto persist fixes.

I created the issue #1408576 so I know this is not a duplicate or even related to that. Maybe try reading into issues a bit more.

Ok, I (partly) stand corrected. Please let me explain myself...

This issue here just might be fixed by #936222: Merge in pathauto_persist module functionality to prevent losing manual aliases with node_save() calls. Since Pathauto Persistent State actually implements #936222 I will test if using that module fixes this issue and report back.

#1408576: [menupath-*] alias generation/update should be triggered when menu settings of a node or any of its parents are changed. is definitely not a duplicate of this issue here though (the other way around could be true). As I see it, this issue here will possibly be resolved by persistent states because it involves a node edit and a successive node save. The issue reported in #1408576 though might or might not involve a direct node edit/save since a node can be assigned to a menu item by other means too (the menu administration form for starters). Pathauto needs to fire and do its magic in such cases too.

...Since Pathauto Persistent State actually implements #936222: Merge in pathauto_persist module functionality to prevent losing manual aliases with node_save() calls I will test if using that module fixes this issue and report back.

Ok, I tested this over at simplytest.me with two different sandboxes one included pathauto_persist while the other did not. The sandbox with pathauto_persist installed did creat the path after editing the node and assigning it to a menu. It even succeeded in updating the path when the node was assigned to a new menu (as expected naturally).

The culprit in this case is that pathauto unchecks the "Generate automatic URL alias" checkbox if after the initial node save it failed to generate a path according to defined pattern. Since Pathauto Persistent State (and #936222: Merge in pathauto_persist module functionality to prevent losing manual aliases with node_save() calls of course) keep the "Generate automatic URL alias" checkbox checked after successive node edits, the path generation fires after menu assignment/change. Problem fixed!

So, I guess we could either postpone this issue here over #936222: Merge in pathauto_persist module functionality to prevent losing manual aliases with node_save() calls or even close it as a duplicate of it. #1408576: [menupath-*] alias generation/update should be triggered when menu settings of a node or any of its parents are changed. is a whole different story...

Since pathauto needs to hook on the menu edit functions whether they are triggered from the node edit form directly this will be partially handled by #936222: Merge in pathauto_persist module functionality to prevent losing manual aliases with node_save() calls. What will not be handled is these two cases though:

- If one does not edit the node in order to assign a menu entry to a node but they do it through the menu admin page instead.

- If one edits either a node or a menu entry that is a parent of one or several children nodes. The paths of these nodes need to be updated recursively down the menu tree hierarchy. #936222: Merge in pathauto_persist module functionality to prevent losing manual aliases with node_save() calls simply does not account for this case.