Old content aliases should be preserved by default

I've started looking at this and here are my initial thoughts/notes...

* Probably shouldn't hide a form element with css. We can use the form API #access = FALSE where we need to.
* We can set the checkbox 'generate automatic url alias' #access to false to avoid having to click the checkbox.
* Update the configuration to: "Create a new alias. Leave the existing alias functioning."
* On form submit (or validate?) check if a value was supplied in the field where it shows "" and based on that having a value or not, programmatically check the "generate automatic url alias" checkbox.

I think that last bullet point is probably key to allowing pathauto to work properly.

Hmm... it does look like a form submit handler is doing that last bullet. I'll try to dig deeper and see why pathauto doesn't like that.

Update the configuration to: "Create a new alias. Leave the existing alias functioning."

I'm beginning to question this one. After looking at it more, I think this is more the job for the Redirect module. That way we have one alias per node and the Redirect module handles generating the redirect for the deleted aliases. Otherwise you can get into some interesting scenarios where the system doesn't know which alias to use.

See if the patch over here solves the issues you're seeing.
#2283531: Path alias isn't preserved if the user doesn't have "create url alias" permission

Note... it doesn't change the pathauto setting to keep old aliases. For SEO purposes that is bad. What you want is the Redirect module to create redirects from the old aliases to the new alias.

Here's a patch that adds the Redirect module to handle old aliases. That coupled with #2283531: Path alias isn't preserved if the user doesn't have "create url alias" permission should hopefully solve this issue.

Update the configuration to: "Create a new alias. Leave the existing alias functioning."

I'm beginning to question this one. After looking at it more, I think this is more the job for the Redirect module. That way we have one alias per node and the Redirect module handles generating the redirect for the deleted aliases. Otherwise you can get into some interesting scenarios where the system doesn't know which alias to use.

Personally, I usually solve this problem not by using the Redirect module, but instead the Global Redirect which will redirect all extra aliases to a single "primary alias". That's compatible with using the "Create a new alias. Leave the existing alias functioning." option.

Anyway, rather than adding a new module to Panopoly, it'd be really cool if we could have a solution that works using just what we already have and then put Redirect (or whatever) into the panopoly_seo module? See:

https://www.drupal.org/project/panopoly_seo

Yeah, I used to use globalredirect as well, but the Redirect module is merging in the functionality from globalredirect (and one or two others) to have a single module for all redirect features.

So are we saying here that we want to make "Create a new alias. Leave the existing alias functioning." as the defaultconfig option for this particular issue? Or do we leave it as is and let the site admin make that change?

So are we saying here that we want to make "Create a new alias. Leave the existing alias functioning." as the defaultconfig option for this particular issue?

Good question! I think it makes sense to have that as the default: we don't want users to break URLs accidentally - that should be something they do explicitly OR configure for themselves beyond the defaults. Although, if it'll mess up using Redirect (if that's the currently popular way to go), I'd like to avoid that! It'd be super sweet to have a patch to panopoly_seo that would just automagically make our aliases SEO friendly. :-)

Attached is a new patch that exports pathauto_update_action as a defaultconfig item. It is set to retain old aliases. The redirect module is no longer included.

I'm not sure how retaining old aliases will work with Redirect. I believe it will be ok. From an SEO and performance perspective filling up the aliases table will eventually cause issues for larger sites. I'm guessing that panopoly_seo can simply change this variable if enabled. Not sure on how to clean up old aliases though.

Ok, I did some testing with the Redirect module. When "Create a new alias. Leave the existing alias functioning." is enabled, it will prevent Redirect from automatically adding redirects. The panopoly_seo module works around this, by actually using both Redirect and Global Redirect.

So, with panopoly_seo, the behaviour is pretty much the same regardless of whether "Create a new alias. Leave the existing alias functioning." is enabled or not, it just changes which module is responsible for doing the redirecting.

A couple last things before we can merge this:

• We should consider a hook_update_N() to set our default on old sites. I'm still debating this with myself: I don't want to break sites that are already dependent on Redirect, but I also want to fix up old sites without a plan for this. Maybe we could detect 'redirect' and not update unless 'globalredirect' is also enabled?
• We need to add tests for this (or update old tests if this'll break them)

Updated issue summary to reflect the current scope. Also, assigned to myself, because I'm going to try to finish out the patch!

Adding related issue: #2283531: Path alias isn't preserved if the user doesn't have "create url alias" permission

Attached are some new patches to add the hook_update_N() and test this new behavior in the tests. I'll commit it soon so we can get the full Behat test run!

Thanks, @carsonblack for reporting and @caschbre for doing most of the work on fixing this! Committed.