pathauto overwrites admin created alias when "automatically alias" has been unchecked if followup edit is done by non-path-admin
greggles - December 17, 2007 - 12:05
| Project: | Pathauto |
| Version: | 5.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
Steps to repeat:
1. As admin create a new node and uncheck the automatically create alias box and create a manual alias
2. As a user who cannot admin paths but who can edit nodes of that type edit the node
Expected results:
Path stays as was specified in step 1
Actual results:
Path is changed to the pattern defined for the node.
#1
+1 Tracking
txcrew
#2
and here's a patch that works under the following scenarios:
// If the box is checked we should alias it
// If the box is not checked but it's already being managed by Pathauto we should alias it
// If the box is not checked, it's not being managed by Pathauto, but this is the submit, we should do it
#3
#4
Slight problem with this patch (or maybe it was another one) - since none of the aliases from before 5.x-2.1+ are in url_alias_extra, pathauto thinks that the admin manually created all of them...
I'm starting to wonder if this can work in this way without a patch to core...
#5
+1
This is a *major* annoyance at the moment.
#6
It doesn't need a +1 - it needs testing, reviews, and a few other patches.
See http://groups.drupal.org/node/8318 for the roadmap of what needs to be fixed to make this work properly.
Unassigning myself.
#7
I'm sure that's what it needs. That's what all issues need. I'm only showing that there's another person bugged by this. That's all :)
Thanks for those links. If I find the time, I'll work on it.
#8
interested party subscribing.
#9
This patch itself works fine. We just need work on the other two issues in http://groups.drupal.org/node/8318
Applied to both 5.x-2 and 6.x.
#10
Yay for the progress! Thanks greggles :)
#11
Has this been applied to 5.x-2.x-dev (just downloaded today)? Because it see to still do the same. Uncheck Automatic alias and change the alias url, then hit submit. It will say:
* The menu item Aliasname has been updated.
* The Page has been updated.
However the menu still goes to the old alias...and I can't get the alias to change. Typing in the new alias directly will give you the same page.
#12
This exact bug has been fixed (I believe) but in general this whole area of functionality doesn't work well and I plan to take it out. There's just no way to really make this work well outside of core. It's on my list of things to fix in core for Drupal7, though.
See http://groups.drupal.org/node/8318 and http://groups.drupal.org/node/8063 for more information on why this is broken and why I'm going to take it out.
#13
Right now, it seem like the way to get around this is just uncheck "automatic alias", change the path and hit save. It will sometimes give an error saying db is duplicated (but the new alias is still created), so that's not a problem.
Then go to Site building > URL aliases and delete the old alias (content/oldalias), and the new alias actually will take affect for the menu.
So the problem if you do not do the above seem to be that there are two alias going to the same system node (node/# was duplicated). The way to solve this in the coding "might" be that when there is an alias where the system node is duplicated, ask "do you want to replace this". Once you click yes, then it will delete the old one. This does not solve the problem of the "automatic alias" being checked still afterwards, but at least the new updated alias will work and I'm not bothered it being checked since you still can uncheck and redo the process...as long as the alias actually changes.
I'm not a coder, so I don't know if this is possible, but it seem like a workaround for this part of the bug...
#14
Automatically closed -- issue fixed for two weeks with no activity.