Right now, the pathauto "Bulk update" action has one mode of operation - it applies the current pattern(s) to all existing nodes which have no aliases. With some experience with the module, and the new node-specific pattern support, I'd like to reapply the bulk update to nodes that already have aliases. It's simple enough just to add a new action to do that, but how should it handle existing aliases for a node?
1. Remove any old aliases for the node. The problem with this is it will break any links (user bookmarks, search engines) pointing to the old alias.
2. Just add the new alias in addition to the old one. The problem here is that you end up with two (or more) aliases to the same node. You can't control which alias appears in listings or the node edit form. Also, search engines may punish you for multiple links to the same content, and having different external pages linking to different aliases for the same node may hurt your ranking (you want all your eggs in one basket).
3. Add the new alias, and (somehow) cause the old alias to do a 301 (Moved Permanently) redirect to the new alias. I think this is ideal, but I'm not sure if it can be done efficiently without support from core (or at least from path.module).
Thoughts from pathauto users? It's easy enough to give you the option of doing #1 or #2, but I have to think some about how to implement #3 (and I'm open to suggestions)...
Comments
Comment #1
moshe weitzman commentedi think you could implement 2) using conf_url_rewrite(). see the help for path.module
Comment #2
njvack commentedI'd say that, ultimately, 3 is the Right Choice. Unless I'm very mistaken, it'll require core support; I don't know that modules can send headers.
My take on operation:
* Paths should know they were automatically generated, so you can do something by hand and pathauto won't hurt it by magic
* When you bulk update, the old auto-generated paths' targets should become the new auto-generated path, and should have some flag for 'send 301 header'.
Short-term, I'd say that 2 is a good option.
Comment #3
media girl commentedI would be happy with 1 or 2, knowing the limitations. (What if it were an admin option?) I think related to this, another update feature would be the abillity to do bulk deletion of existing aliases. I'm glad to see this at the top of the list.
The improvements from the 4.5.2 version I had before are wonderful! This module should be in core, if you ask me.
Comment #4
dfg commentedFor 1, 2 and 3 it would require to
(a) add a new table. I suggest 'pathauto'. or
(b) enhance the 'url_alias' table, e.g. by the columns 'weight' and 'flag'.
My suggestion now: Seperate pathauto clearly from the url_alias table.
(1) I will make this table:
Summary: (pid, internal, alias, weight, flags)
Example rows:
(1, 'node/1', 'math', 0, 0)
(2, 'node/1', 'mathematics', 1, PATHAUTO_REDIRECT)
where
define('PATHAUTO_REDIRECT', 1)
(2) Flags
Therefore 'mathematics' would be redirected to 'math'. But because there are several redirect values, we should define a flag for all of them. A flag is a power of 2, including 2^0 = 1.
If it were (2, 'node/1', 'mathematics', 1, 0), 'node/1' would be displayed under 'mathematics' (no flags -> no redirect).
It is also possible to redirect 'node/1' to 'math'. Just setting the appropriate flag in (1, 'node/1', 'math', 0, flag). I think, this is really new in Drupal?
(3) The function pathauto_get_path_alias($path)
- will return alias where internal = '$path' and weight = 0
- as you can see here, 0 shall be the weight of the primary alias
(4) The function pathauto_get_internal_path($path)
- will return internal where alias = '$path'
- alias is unique in the table (as in url_alias)
(5) The redirection is done in hook_init()
(6) The rewriting in done with conf_rewrite()
- There, the above mentioned functions will be executed
- conf_rewrite($path) will return $path if no alias is found
- pathauto_get_path_alias($path) and pathauto_get_internal_path($path) could either return $path if no alias is found, or FALSE. We only need to define the behaviour.
- the aliases in url_alias always have precedence over conf_rewrite()
(7) I could code that in 3 days, but before that, please say your opinions and say your wishes.
Comment #5
mikeryanDFG, let me introduce myself - I'm the author and maintainer of the pathauto module. While your enthusiasm for helping is admirable, it is rather presumptuous to unilaterally assign issues belonging to other authors to yourself, without even an attempt to contact the author.
In this case, if you had contacted me I could have told you:
1. A patch I submitted for adding a weight column to url_alias is in cvs and will appear in Drupal 4.7.
2. I do have my own plans for the future evolution of pathauto - I've been busy with other projects lately, but hope to move forward this fall.
In the future, please do not take it upon yourself to modify the status of other people's modules - post what you'd like to do, and if you'd like to take ownership of an issue ask permission from the module's maintainer first.
I am restoring the priority to normal and assignment to myself.
Thank you.
Comment #6
dfg commentedAs you command.
I now read the two discussions (i did not read before) about this topic, and I think the changes to the url_alias table suffice to elaborate all three points.
I only would use the 'status' column as a column for many flags, as I write here: http://drupal.org/node/24321
But I don't know, in how far the BIT functions in MySQL differ from PgSQL...
Comment #7
gregglesI believe this has been fixed in a variety of ways in the 4.7 and now in 5.x-2.0.
Option 3 from above (Mike's preferred one) is now available if people use Pathauto and the using the Path Redirect module thanks to some work by jjeff.
Options 1 and 2 got implemented (though not as fully as Mike originally proposed).
Comment #8
gregglesI believe this has been fixed in a variety of ways in the 4.7 and now in 5.x-2.0.
Option 3 from above (Mike's preferred one) is now available if people use Pathauto and the using the Path Redirect module thanks to some work by jjeff.
Options 1 and 2 got implemented I think (though not as fully as Mike originally proposed).
Work on the whole weights system is now in http://drupal.org/node/147143