path aliases for deleted sites are not deleted

Hmmm...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.

Thanks for outlining the issue, I'll look into it.

A 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. :)

Right, 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.

Some 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.

Upgrade 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).

So I guess this will still result in the 404 if you refresh manually...Maybe we need to handle the 404 better. urgh!

tagging

So, is this the reason for all the false positive failures if we re-run the test suite on the same Aegir install?

WD path: The alias 'hosting/c/platform_drupal6' for path 'node/353' (language '') was not created, because the path 'node/90' already has   [error]
the same alias.

URL aliases is confusing, as it may mean the URL of the site on the web, not on the aegir site. Clarifying to path alias.

I 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.

Alright thanks. I have merged (with quite a lot of conflicts, actually) this onto the 2.x branch for now.