Supposedly this was fixed in 1.3 as seen here: https://www.drupal.org/node/936222 but this is not the case. I just lost a s***-ton of custom aliases when I had updated a bunch of content with node_save() in a custom module. The site did not use pathauto_persist at all previously as it wasnt necessary at the time. So after updating core/modules and seeing the change log, I THOUGHT this would have been fixed and the pathauto_persist module wouldnt be required, but that was just wishful thinking. I had backups so its fine, but this is a super dangerous bug that could cause serious problems if not fixed. I'm assuming that the same problem existed in the pathauto_persist module and that bug was carried over maybe?

Comments

crystaldawn created an issue. See original summary.

crystaldawn’s picture

Issue summary: View changes
crystaldawn’s picture

Also, it should be noted that this can be worked around with the following:

//If $node->path doesnt exist, you'll need to populate it on your own, it didnt exist on my nodes so I had to populate it manually.  This essentially set the current path in stone and disables pathauto so that when node_save() runs, pathauto doesnt do it's badness and overwrite the path with something completely new.
$node->path = array('alias' => $path, 'pathauto' => FALSE);
node_save($node);

This workaround shouldnt be necessary.

damienmckenna’s picture

In your custom code were you doing a node_load() or entity_load() to load the nodes?

crystaldawn’s picture

Hmm, interesting question but the answer is NEITHER :) I used menu_get_object() to get the nid of a given path. Note that I did not actually use current_path(), I had passed the alias in from a spreadsheet CSV file. But current_path() insinuates get the alias anyway and may be easier to understand. It does the exact same thing. Anyway, the method of object loading was that of menu_get_object(), how the path was retrieved is not relevant to the issue.

   //Assume that current path is a custom alias, so look up it's real path,  this should work even if it's not an alias I believe (such as node/1 type paths).
   $path_source = drupal_lookup_path("source", current_path());

   //Load the node object using it's path source.
   $node = menu_get_object("node", 1, $path_source);
rooby’s picture

menu_get_object() indirectly uses node_load().

dave reid’s picture

Status: Active » Closed (works as designed)

If you did not have the Pathauto Persist module enabled and storing data for any of your nodes before the update, then the old behavior of "doing a node_load() then node_save() will generate an automatic alias unless you manually set $node->path['pathauto'] = FALSE" will still continue to be true only once for each node. At that point, we are able to store the fact that you set $node->path['pathauto'] to FALSE and it will continue to be set in the future for that node.

This is a problem with existing content. We don't really know how to handle them, but if you submit the node form, or set the $node->path['pathauto'] property when doing a node_save(), that state will be saved going forward.

Basically, the Pathauto module works as it did before, until you save every pre-existing node, then each node gets the new behavior.

crystaldawn’s picture

Is this behavior documented somewhere? If so, where (as I didnt find it) If not, it needs to be if its going to continue to be true. Imo there should be a method to select the behavior rather than forcing it upon a user. That to me would be the correct fix for this.

farse’s picture

I have been using pathauto 1.3 and now have tried the latest dev but I am still having problems. Normal nodes are fine, but Webforms are messing up. I also have workbench moderation installed. How I have reproduced: 1. create a Webform with 'generate url alias' ticked (save to published in workbench). 2. edit the node unticking the 'generate..' box and putting in a custom alias. When I resave (straight to published) I am taken to the 'generate' alias. Although the custom alias also works, but if you try to go to it you get redirected to the auto one (a redirect isn't created, but both aliases exist in the URL aliases admin when I search for them).