Here's a patch to implement 2/3 of my previous suggestions.
1. A status column is added to the url_alias table. A 0 (zero) value indicates an alias explicitly created by a user or administrator; a 1 (one) value indicates an alias created by an automated process. No core code support is required here - aliases created by core methods (the node form or url aliases settings) will default to 0. The pathauto module (or any other module that wishes to automatically generate aliases) will create them with a status of 1, and when updating aliases will only delete/modify aliases with a status of 1, so that aliases created explicitly by users are not blown away.
2. A weight column is added to the url_alias table. As path aliasing exists now, multiple aliases may be created for a given path but there is no control over which one is generated in the outgoing direction (as in listings). This patch adds the support for editing weights for aliases to the url aliases settings (and both status and weight become optional arguments to path_set_alias()), and drupal_lookup_path() is modified to pick the lowest weighted alias in response to an 'alias' call (if there's a tie for lowest weight, it's the same result as before, which is most likely lowest pid === first created).
I really wanted to implement a method for having aliases that produce a 301 (Move Permanently) response, particularly if you want to change the alias for a page without abandoning any bookmarks/search engine links that are already out there - but I started on it and realized it will require more thought to integrate cleanly... It might just be easier to do that using conf_url_rewrite()...
Thanks for your consideration...
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | path_0.patch | 8.13 KB | mikeryan |
| alias_0.patch | 6.63 KB | mikeryan |
Comments
Comment #1
venkat-rk commentedCan I apply this to pathauto-4.5?
Thanks.
Comment #2
mikeryanThis is a proposed patch to core - if accepted, I wouldn't expect it to be available before Drupal 4.7. It's unlikely this patch would apply to Drupal 4.5 (although the path.module patch may very well work, and the small change to bootstrap.inc could easily be done manually).
I will release a version of pathauto taking advantage of these changes only after they're accepted and committed to cvs.
Comment #3
moshe weitzman commentedlooks like a small, useful patch to me.
Comment #4
venkat-rk commentedThanks for anwering my question.
Ramdak
Comment #5
mikeryanAny chance this patch will make 4.7? Is there a plan for 4.7 (I've searched around and couldn't find any...).
Thanks.
Comment #6
mikeryanThis patch appears to have been committed to cvs... Thanks!
Comment #7
dfg commentedWhy don't you use the 'status' column as as column for flags? Actually you can only combine 7 flags (2^0 to 2^6) because you use int(2).
For pathauto, this may suffice. But maybe other modules want to set flags too.
I would rename 'status' to 'flags' and use the int(10) unsigned type. This is a 32bit type and can very fast be scanned for a combinations of flags.
define('PATH_USER_ALIAS', 1)
define('PATH_MOVED_PERMANANTLY', 2)
define('PATH_MOVED_TEMPORARILY', 4)
.
.
.
What do you think about that?
Comment #8
mikeryanLet's take it one step at a time, particularly with code freeze for 4.7 approaching. I took a look a little while ago at Move Permanently support, and it was a little hairier than it would seem at first glance - plus, I have various other thoughts on Drupal's path handling (as do others, related to issues like external links and i18n), and would rather take the time to make a clean integrated proposal for 5.0 than keep hacking away at the current code.
Comment #9
(not verified) commentedComment #10
(not verified) commentedComment #11
(not verified) commentedComment #12
mikeryanI could've sworn this patch had been committed, but I don't see it in the current HEAD. I'll create a new patch for it...
Comment #13
mikeryanHere's a patch against the current HEAD.
Comment #14
Crell commentedPatch no longer applies.
Comment #15
Jaza commentedPatch is still relevant, and still needed IMO. Moving to 6.x-dev queue.
Comment #16
moshe weitzman commentedyes, this still seems needed. anyone willing to revive this?
Comment #17
catchWe need this, but http://drupal.org/node/147143 deals with it nicely and in depth, so although this is the older issue, marking as duplicate.