Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.When deleting a site (and probably a server and platform) aliases are deleted too. If for some reason you create a new site with the same name, an alias equal to the old one will be created, which means the old node will not be accessible cause the aliases will point to the new one.
To avoid this instead of deleting the alias, it could be renamed to "siteName-deleted" (and then siteName-deleted-1 if you do it again).
Comments
Comment #1
jm.federico CreditAttribution: jm.federico commentedComment #2
Steven Jones CreditAttribution: Steven Jones commentedHmmm...we're not stopping the node from being accessible, just that you have to get to it in a slightly different way right? So I'm not convinced that we need to keep an alias really, as it's not much use.
Going to mark as 'works as designed' but feel free to re-open with a compelling reason to implement this feature request.
Comment #3
jm.federico CreditAttribution: jm.federico commentedHello Steven
The problems presents itself when you are at the "Content" page with all the nodes listed, and you try to go to the "old one", the one form the deleted site. You will see that it will take you to the new one. This is because for some reason it still points to the Alias it once had. So to access it you have to go to edit and then to view. That way it will take you to node/##. But that to me seems like is not the expected behavior.
So, if an alias will not be in place, the links to it from admin areas (and form everywhere, I guess) should not point to the alias, but to the "node/##" path directly.
Might it be that the alias is not being deleted, and both nodes have the same one?
Marking as active again.
Comment #4
Steven Jones CreditAttribution: Steven Jones commentedThanks for outlining the issue, I'll look into it.
Comment #5
joestewart CreditAttribution: joestewart commentedA little recap may help?
#908314: Deleted sites cause node alias to 404 on refresh was marked as an aegirWTF. To keep the ajax from reloading an alias that didn't exist anymore, we stopped deleting the alias.
I guess there a few ways to go here:
1. do nothing
2 modify the ajax etc and not use the alias
3. somehow delete the alias after the reload
4. delete or update existing aliases rather than node creation blindly inserting new ones.
In usage I haven't had a problem with the current way even though for some dev sites I probably do have some alias cruft.
So that makes me curious about this use case. These are probably good for an IRC conversation so if you are there, feel free to ping me.
Why are you going to admin/content/node? I don't use it for Aegir admin.
If you've deleted a site and recreated another one, why are you going back to the deleted one?
Like I said, just curious. :)
Comment #6
jm.federico CreditAttribution: jm.federico commentedHello
Well, not really sure what happened before I had to go to "admin/content/node" but what I do remember is that I was looking for a site I couldn't find, and there it was.
I'm taking a week to go around UK after the DrupalCon, so I'll be out of IRC and work for at least a week. As soon as I'm back to business will look for you.
Chers
Comment #7
Steven Jones CreditAttribution: Steven Jones commentedRight, so the solution found in #908314: Deleted sites cause node alias to 404 on refresh means that we leave the old aliases lying around, whereas we could have sent a different refresh parameter quite easily I think. Some work needed here.
Comment #8
Steven Jones CreditAttribution: Steven Jones commentedSome work on this in the dev-1256508-delete-context-aliases branch. This fixes the javascript, so the only thing lacking is an upgrade path for removing aliases that we've left lying around so far.
Comment #9
Steven Jones CreditAttribution: Steven Jones commentedUpgrade path added to the branch, it's a bit nasty because there's no easy, performant, join between the url_alias and hosting_context tables, so it has to do a lot of the work manually. I've tested it on a site with 500,000 orphaned aliases and they were removed just fine, and I don't think any Aegir install out there will have anything like that number.
This should be safe to run on any Aegir site, and the only thing that is lost is the URL alias, so it's not a major issue is some get deleted when they shouldn't (and I really don't think they will).
Comment #10
Steven Jones CreditAttribution: Steven Jones commentedSo I guess this will still result in the 404 if you refresh manually...Maybe we need to handle the 404 better. urgh!
Comment #11
Steven Jones CreditAttribution: Steven Jones commentedComment #12
Steven Jones CreditAttribution: Steven Jones commentedtagging
Comment #13
ergonlogicSo, is this the reason for all the false positive failures if we re-run the test suite on the same Aegir install?
Comment #14
anarcat CreditAttribution: anarcat commentedURL aliases is confusing, as it may mean the URL of the site on the web, not on the aegir site. Clarifying to path alias.
Comment #15
ergonlogicI prefer this fix to keeping the old aliases. I've tested it and it works fine, and does indeed fix the false positives when re-running the test suite.
Comment #16
anarcat CreditAttribution: anarcat commentedAlright thanks. I have merged (with quite a lot of conflicts, actually) this onto the 2.x branch for now.