Improve motivation to also use path_redirect

I must admit that I do not really like the idea of adding a module dependency if it isn't really dependent on it. And this isn't. I wouldn't oppose a "life is better with path_redirect, won't you try it?" message though, as that still leaves the final decision to the web admin.

Hello, I would like a bit more Info about path redirect and global redirect. Should I use both or with Path redirect it's enough?
I have installed Path redirect but I don't know how to configure it to automatically work with pathauto. There are no information regarding to that in the README files of both Pathauto and Path redirect.

It would be really helpful a bit more information about how they work together and how to configure them (if it's not automatically done) It would be also really good if someone could provide more information about how to configure together Pathauto, Pathredirect, Transliteration and XML Sitemap. Thanks!

PS: more information would be enough motivation :)

Subscribing to see how I can help with this issue from the path_redirect side.

So I was brainstorming on how we can really improve this, and I've come across a few things:

1. Definitely need to implement a pathauto_requirements in pathauto.install that will show a message on the status report page.
   

   /**
    * Implementation of hook_requirements().
    */
   function pathauto_requirements($phase) {
     $requirements = array();
     $t = get_t();
   
     if (variable_get('pathauto_update_action', 2) == 2 && !module_exists('path_redirect')) {
       $requirements['pathauto_redirects'] = array(
         'title' => $t('Path alias update redirection'),
         'value' => 'Automatic redirection not enabled',
         'description' => $t('Pathauto strongly recommends installing and enabling the <a href="@path-redirect">Path redirect module</a> to automatically create redirects when node aliases are changed.', array('@path-redirect' => url('http://drupal.org/project/path_redirect'))),
         'severity' => REQUIREMENT_WARNING,
       );
     }
   
     return $requirements;
   }
   

2. Integrate the two settings "Create new alias, delete old alias" and "Create new alias, delete old alias, add redirection from old alias to new alias" so that more functionality happens if path_redirect is enabled. Currently if path_redirect is not enabled, pathauto will default to 'Create & delete'. If the path_redirect module does get enabled afterwards, the users has to manually change the option to 'Create, delete & redirect'. Why not show a message on the option that the user will get added functionality if they only download the path_redirect module:
   

     $form['general']['pathauto_update_action'] = array(
       '#type' => 'radios',
       '#title' => t('Update action'),
       '#default_value' => variable_get('pathauto_update_action', 2),
       '#options' => array(
         0 => t('Do nothing. Leave the old alias intact.'),
         1 => t('Create a new alias. Leave the existing alias functioning.'),
         2 => t('Create a new alias. Delete the old alias.') .' '. (module_exists('path_redirect') ? t('Automatically redirect the old alias to the new alias using the Path redirect module (<strong>recommended</strong>).') : t('To automatically redirect the old alias to the new alias, download and install the <a href="@path-redirect">Path redirect module</a> (<strong>strongly recommended</strong>).', array('@path-redirect' => url('http://drupal.org/project/path_redirect')))),
       ),
       '#description' => t('What should pathauto do when updating an existing content item which already has an alias?'),
     );
   

   So if path_redirect is enabled, the option now reads:
   "Create a new alias. Delete the old alias. Automatically redirect the old alias to the new alias using the Path redirect module (recommended)."

   And if path_redirect is not enabled, the option now reads:
   "Create a new alias. Delete the old alias. To automatically redirect the old alias to the new alias, download and install the Path redirect module (strongly recommended)."

   So now the code in _pathauto_set_alias in pathauto.inc:

       if (module_exists('path_redirect') && variable_get('pathauto_update_action', 2) == 2) {
         if (isset($old_alias)) {
           $redirect = array(
             'path' => $old_alias,
             'redirect' => $src,
           );
           path_redirect_save($redirect);
         }
       }
   

   And of course we'd need an upgrade path for users that have this variable set to 3 already:

   /**
    * Merge the create alias redirects option with the create new alias and
    * delete old alias option.
    */
   function pathauto_update_6000() {
     if (variable_get('pathauto_update_action', 2) == 3) {
       variable_set('pathauto_update_action', 2);
     }
     return array();
   }
   

Our end result will be that the default, out of the box settings for pathauto will work whenever path_redirect is enabled.

That's awesome input, and even includes sample code. Excellent. Now we just need it as a patch... =)

I have one critique though, "Create new, delete own" essentially is to create the new alias and make the old one stop working. This is semantically different from "create new, make old one redirect" as this will still have the old path work. So if we want to do it this way, it would make more sense to couple it with 1, "create new, leave old" which says "create new alias, but let the old one still work". But perhaps it would simply make more sense to put a note in the hook_requirements() when path_redirect exists and the update action isn't set to use it, like so:
if (variable_get('pathauto_update_action', 2) > 0 && !module_exists('path_redirect')) {
.. and then (perhaps) note somewhere that there's a new update action available. (I'm a bit busy, but I'll try and think more on this and get back. Just thought I'd get my immediate thoughts out. :))

The problem is that the first two options leave the existing url alias intact. In those two cases, performing redirects is useless because the path.module intercepts and loads the correct node/x in $_GET['q']. The only way for redirects to work is if the old alias is deleted, which is only in option 2.

@ Dave Reid: That's because you're thinking about this "programmatically" (ie., what happens behind the scenes) instead of "semantically" (ie., what the end user experiences). In this case, the first two options allows the content to still be accessed at the old URI/(perceived) location, while the third one makes the content completely unavailable at the old URI/(perceived) location. Looking at it from this angle, it doesn't make sense to have the URI still work, if that's not the intention.

Could it be handled the other way, could there be a hook for other modules (i.e. path_redirect) to jump in and handle the old URL?

Ok, just ignore me, I guess my glasses were dirty or something, there are *lots* of references to path_redirect in pathauto.inc.

Patch attached for HEAD/6.x-2.x that will always expose the redirect option, but disable it if path_redirect is not enabled. Also attached screenshots of the pathauto settings when path_redirect is disabled before and after the patch.

Revised patch and summary:
1. Always shows the redirect alias update option, but disables it if path_redirect is not enabled. This will get users to notice that the option is available instead of hiding it.
2. When users install pathauto and path_redirect is already enabled, then it will set the default action to redirect aliases instead of delete the old alias.
3. Will show a message at admin/reports/status if path_redirect is not enabled and the delete old alias update action is selected.
4. Changes the suggests[] = path_redirect in pathauto.info to recommends[] = path_redirect for a stronger relation.

Bumping to 7.x-1.x/6.x-2.x since it would change strings.

This is being superceded by #971552: Integration with Redirect Module Not Working (or not present) now.