Setting path to default Pathauto value

Patch updated.
We use the same method as Pathauto does: http://drupalcode.org/project/pathauto.git/blob/e95ceafa6b4638084cc37aea...

With this patch I can use Pathauto, modify alias or delete it via node edit form.

This works. Please oh please roll this into your next release :)

Those patches look great but for some reason calling pathauto_create_alias() crashes my site? No error messages or warning it just hands and then crashes.

I've tested with function_exists() and the module & functions are accessible ok. Calling pathauto_create_alias() seems to be ok up until I pass it the node data array('node' => $node). I've tried an empty array, just $node and even node_load($node->nid)) but it crashes each time.
All my modules are up to date(not dev) including workbench_moderation. Any ideas what's going wrong?
I'll keep trying but everything seems to be fine, I don't understand...

@omcateer, does it happens when workbench_moderation is disabled?

No. It only crashes when I apply the patch "1852244-setting_path_to_default_pathauto_value-3.patch"
Editing the patch code I found it hangs on this line pathauto_create_alias()

I'm not sure exactly why, but I un/re-installed workbench_moderation, cleared the cache, ran update.php and now it's working correctly now?
I'll keep looking as to why this is now working and let you know if I find anything. But bottom line #3 patch works fine!

No sorry it's still not working. reinstalling the module simply disabled "Enable moderation of revisions" on each node, which doesn't run the code and therefor doesn't crash.

If I add the following right after the patch code the below is outputted:

    print $pathauto_alias;
    print_r($path);
    die('STOP');

privacy-policy
Array
(
    [pid] => 210
    [source] => node/121
    [alias] => privacy
    [language] => en
    [pathauto] => 
)
STOP

Everything looks as it should and I don't know why it crashes?
If I remove the patch and manually add $path['pathauto'] = true; // or false it works fine?...
I've check Drupals, PHP & Apache error logs but nothing. The browser just replies an "ERR_CONNECTION_RESET" error.
What should I look at? test or try to help debug this?

I am a little unsure of the above patch, because IMHO I don't think pathauto should be firing at all because of workbench_moderation's node_save when it has already fired properly on the original node_save. It just means that workbench_moderation will need to be as smart as pathauto when it comes to creating aliases, which I don't believe it is as shown in the line:

@@ -1041,6 +1041,13 @@ function workbench_moderation_node_data($node) {
       'language' => isset($node->language) ? $node->language : LANGUAGE_NONE,
     );
 

...where it sets the path language to the node language, which means that it will not work properly with entity translation. I am temporarily using this in the function workbench_moderation_store to get workbench_moderation's node_save to leave the original node_save's path in tact.

   1587   $pathauto_current_state = isset($live_revision->path['pathauto']) ? $live_revision->path['pathauto'] : FALSE;
   1588   $live_revision->path['pathauto'] = FALSE;
   1589   // Save the node.
   1590   node_save($live_revision);
   1591   // replace pathauto state if pathauto module is enabled
   1592   if (module_exists('pathauto')) {
   1593     pathauto_entity_state_save('node', $live_revision, $pathauto_current_state);
   1594   }

I know it is not the best solution, but it I thought I would post it as food for thought.

The use of https://drupal.org/project/pathauto_persist is supposed to solve this issue and is highly recommended on Workbench Moderation installs.

I am fairly certain that path_auto persist is built into pathauto now...I think the pathauto_entity_state_save is exactly that functionality.

No it's not. I'm the pathauto maintainer, so I kinda know if it is or not.

Lol...oops, I will need to do some homework to figure out where I got that then. Thanks!

This is really new info. From reading project notes on workbench and pathauto or pathauto_persist I don't understand why I need pathauto_persist and that this is a requirement. How often I read project details of pathauto_persist I do not understand why I need this. If Workbench require pathauto_persist we need to document this and make this a module dependency.

Are there plans to integrate this module into pathauto?

I think a patch must have been added to my distro, this code is from the pathauto.install:

213   drupal_load('module', 'pathauto');
214   module_load_include('inc', 'pathauto');
215 
216   if (!isset($sandbox['progress'])) {
217     // Initialize the defaults for populating the table with Batch API.
218     $sandbox['progress'] = 0;
219     $sandbox['last_nid_processed'] = 0;
220     $sandbox['max'] = db_query("SELECT COUNT(*) FROM {node}")->fetchField();
221     $sandbox['pathauto_persist'] = FALSE;
222 
223     // If the user used Pathauto persist, utilize the existing table.
224     if (db_table_exists('pathauto_persist')) {
225       db_rename_table('pathauto_persist', 'pathauto');
226       module_disable(array('pathauto_persist'));
227       drupal_set_message(t('Pathauto persist has been disabled. This release of Pathauto includes its functionality and the old module may be removed.'));
228       $sandbox['pathauto_persist'] = TRUE;
229     }

Sorry for the confusion I may have caused.

Seems to me that pathauto_persist should be rolled into pathauto. If not, pathauto_persist should be made a dependency of workbench.

If pathauto_persist were a dependency of workbench_moderation, that would imply that pathauto is a dependency as well, but athauto is not required for workbench_moderation. There is a note about this on the installation documentation: drupal.org/project/pathauto

Since pathauto is so widely used, it would maybe be wise to have a more prominent note about this on the main project page since not everyone goes through all of the documentation when installing modules.

@Dave Reid, we just encoutered this issue on a site using Workbench Moderation 1.3, Pathauto 1.2 with the patch from comment #115 from #936222: Merge in pathauto_persist module functionality to prevent losing manual aliases with node_save() calls (which incorporates pathauto_persist)

A draft with automated alias is scheduled for publishing using revision_scheduler. When it is published, it has the global pathauto pattern rather than then one that should generate. The patch from #3 fixes that issue, so I'm happy with the patch.

Last but not least, I agree that there should be a note on the project page about the need of either pathauto_persist or pathauto with the patch that incorporates it.

Cheers,
Dan

This should be in the next release.

Which is going in the next release, this patch or the recommendation to use pathauto_persist?

I am running out of memory when I use the patch in #3. It occur when install my site (drush site-install). During the install I'm creating some nodes programmatically, then rebuild node access at the end of the install.

Could it be
module_load_include('inc', 'pathauto');
that increade memory usage if we create several nodes programmatically?

Thanks,

FYI the patch in #3 still applies, just with a line offset.

@mattew: Can you change your installation procedure to do less inline data processing, or move it to a separate step in the installation profile?

@mattew: Also check the Pathauto issue queue for possible improvements, also Redirect's queue if you are using it.

patch in #3 still does not apply even with the line offset. I encountered a similar issue to Mattew, except it was not during installation.

There is an issue with the line
$pathauto_alias = pathauto_create_alias('node', 'return', $path['source'], array('node' => $node), $node->type, $path['language']);

I'm working on resolving the issue.

Rerolled.

--EDIT--

Patch failed as rolled against v 7.x-1.4 - should have taken better notice of the version related to this issues.

New issue created at - https://www.drupal.org/node/2616854

After testing the current dev version with Pathauto 7.x-1.3 on clean standard install of latest Drupal (7.41) I can confirm that all is OK and there are no issues with the saving of the state or URL alias during moderation.

I recommend that this issue can be closed.

--END-EDIT--

Latest version of pathauto 7.x-1.3 has merged the functionality of the pathauto_persist with the inclusion of the pathauto_state table. The function workbench_moderation_store() breaks the setting of the state on the hook_node_save as invoked by the shutdown function in workbench_moderation_moderate by declaring the $live_revision->path['pathauto'] variable as 0.

I'd suggest that the following attached patch - using the pathauto_entity_state_load function to set this variable is a better plan of attack than the previous patch.

I also don't see the need for setting the path['pathauto'], as per previous patch, in workbench_moderation_node_data()

The patch in #27 seems to have the unintended consequence of recursive calls to pathauto_create_alias, thereby blowing out the call stack. Will try the patch for #28 instead.

I can no longer reproduce this issue using Pathauto Version: 7.x-1.3 and Workbench Moderation version Version: 7.x-1.4. Can anyone else confirm this?

I can confirm that #28 works on Workbench moderation 7.x-1.4 and pathauto 7.x-1.3.

Thank you for that patch.

Like #31, I can no longer reproduce this issue using Pathauto Version: 7.x-1.3 and Workbench Moderation version Version: 7.x-1.4. I made sure I removed the patch, and everything worked fine.

Recommend closing ticket with one more corroboration.

We're building a site with entity translation, pathauto 1.3 and workbench moderation 1.4 . The pathauto settings would not persist between moderated versions of a node. With #27 patch they do.