The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.If you used Pathauto 1.x with the "Create index aliases" option then after upgrading to Pathauto 2.0 you will end up with many 404 errors, especially with the events module.
Since Pathauto 2.0 does not provide index aliases anymore during upgrade it should delete all the special aliases created by the previous version.
Here is the SQL code I used to clear aliases:
DELETE FROM `url_alias` WHERE src LIKE 'pathauto/%'
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | delete_index_aliases_192576.patch | 1.13 KB | greggles |
Comments
Comment #1
gregglesThanks for the issue report. I added a note about index aliases being deprecated and slow to the Pathauto homepage on March of 2007.
In the paths group on groups.drupal.org I wrote about this a few days ago in cleaning up the index aliases.
The upgrade guide lists this at the bottom including how to create equivalents using views. I've now linked that to the documentation on how to clean up the index aliases.
I don't like the idea of automatically deleting these so I changed this to a documentation problem which I feel has been solved.
Comment #2
mariuss commentedI was aware of some of the documentation you mention and I still think this is not a pure documentation issue.
If I understand correctly in pathauto 1.x there was code that handled aliases starting with /pathauto/*, and that handler is gone now. If you leave these old aliases on place then these /pathauto/* aliases will continue to create problems, and that cannot be addressed by views.
As an example, I had a content type "news" and all nodes of this type used to be aliased to /news/[yyyy]/[mm]/[title]. Among other index aliases pathauto 1 created one /news that maps to /pathauto/... After upgrading to 2.0 I did create a view for /news but I would still get a 404 because of that old alias pointing to /pathauto/...
And with the events module this gets even worse, basically every single event will generate a 404, and nothing short of deleting these old aliases can fix this.
Comment #3
gregglesChanging title to be a little more specific.
I've created a patch which adds this as an option on the Bulk delete page (admin/build/delete_bulk).
I understand that you feel it should be done automatically but I don't like the idea of automatically deleting anything. At a minimum it should involve this clicking the checkbox and the submit.
Your review of this patch would be appreciated.
Comment #4
mariuss commentedI will look at the patch over the weekend.
A quick question, is there any reason why you would leave those broken aliases in place and not delete them?
I do agree that in general automatically removing this is not good, but in this particular case feels appropriate. Why complicate the user interface by adding extra controls for something that needs to be done anyhow?
Comment #5
gregglesWell, I'm having a hard time coming up with examples of systems that automatically delete user created data during an upgrade. I can think of upgrade packages which will sometimes take the new configuration file, and install it to config.new instead of overwriting your old data. I remember various Drupal upgrades (4.6 to 4.7?) that would take your settings, watchdog what they were, and then overwrite them. So that you still have the old settings if you still want them.
So the pattern seems to be that any automatic deleting should have a way that it can be easily reverted. There is no current means to make the deleting that you propose easy to revert and I don't want to build that infrastructure. So, instead, I feel like one more checkbox is the best way to add this if we add it at all.
Can you think of software which automatically and completely deletes your data without human intervention?
Also, I believe you're the first person who has raised an issue about this problem so I'm still not entirely sure that we need to do anything about it in the code.
Comment #6
mariuss commentedAgain, in principle I agree with you, but this is a special case I think.
The user did not explicitly create this content (the index aliases), so you are not deleting user created data.
What the user did was to ask for all those intermediate URLs to show meaningful data. The code that did that was removed, so the damage is done (and I think it was a good decision to remove this). The aliases are just a front, and at this point not only useless but problematic.
What is the point of keeping the front end when the corresponding back end is gone?
Again, you get 404s not only if there is nothing to back these orphan aliases, you get them even if you create views to replace the old back end. That is really bad.
The fact the no one else reported this is strange indeed. I would agree that you should wait implementing a fix until someone else confirms the problem.
Comment #7
gregglesI don't understand that. They are only created if the user checks the box asks for index aliases. So, yes, the user created them.
I don't think it's a matter of whether or not the problem is real - the problem is real. I had it some of my own sites.
The question in my mind is "does the number of users affected justify adding this?"
Comment #8
mariuss commentedYes and no. The user did not create those aliases individually, the user requested that the pathauto module provide views for intermediary paths. Pathauto did this by creating a whole bunch of aliases that point to a controller, also provided by pathauto at "/pathauto/...".
Now pathauto does not provide that controller anymore, so there is absolutely no reason for those aliases to stay around.
If the problem is real then those aliases must be removed. Leaving them there will lead to sites with broken pages and confused users. Even though I knew that pathauto does not provide index aliases anymore I ended up with end users call me that links are broken on several sites. Did the upgrade, everything seemed ok, but it wasn't. And after I was notified about those broken links it still took a while until I figured what's wrong and then to find a solution (which was quite ugly).
Comment #9
gregglesSo far nobody else has mentioned this problem. I think that indicates that it's ok not to do anything about it.
I searched to see if maybe they had posted about it but just in the forums instead of here. The forum posts seem to be very old and about different problems.