Path redirect integration forwards front page to new location

My guess is that it's got something to do with the PathAuto integration. Perhaps a user changed their username, which changed their user path or something weird like that. You can avoid the problem by changing the PathAuto setting for what to do with old aliases (don't set them to redirect).

I'm actually kind of inclined to think that this might be a bug in PathAuto where it's creating an alias to nothing and then quickly replacing it with an alias to the user's userpage. This would trigger Path Redirect to create a redirect from the old alias (nothing a.k.a. the home page) to the new path..

Just a theory, but that's where I'd start.

It happened when a new user joined. As far as I can tell, he didn't change his username. He did write a post that got (falsly) flagged as spam and unpublished, which then emailed me and I came to check it out and found the front page was wrong.

I deleted the bad record and re-enabled path redirect. If it happens again, maybe I can get more info.

Thanks,

Michelle

I agree with Jeff that pathauto may well be the culprit. Should path_redirect do validation in path_redirect_save to prevent these sorts of problems? I was actually removing some of the existing validation in my checkout in order to simplify the function, since that's all covered by path_redirect_edit_validate, but maybe that's not so wise. (Maybe the former could simply call the latter?)

Alternatively, or in addition, maybe there needs to be some sanity checking in path_redirect_init in order to prevent these sorts of things. It could be as simple as throwing a warning when a redirect from the empty string is done.

Moving this to pathauto

Michelle

michelle and I discussed in IRC and I asked her to move it - now that I read the full description I have seen this before, though not consistently.

@horsepunchkid - I think that any validation from path_redirect_edit_validate should be refactored into its own set of functions and then called from both that function and path_redirect_save. What do you think?

In the mean time, I'll try to pin down the scenario where this happens. I hit it when editing a node, michelle hit it on user register. There doesn't seem to be a consistent pattern just yet...it oculd be that it was only a problem in the -dev and not any more.

A while ago I switched to "isset($old_alias)" instead of $old_alias since that occasionally threw php notices. I think that sometimes the $old_alias was set even though it was a zero length string. Bummer.

So, this new patch checks if it is set AND has an actual length to it. Ideally this would be fixed via path_redirect as well but in the mean time here is a solution for Pathauto's integration with path_redirect.

I got bit by this again this morning and it is a doozy to have your homepage redirected...so I upgraded the priority and have committed it.

Thanks for the report and discussion that helped find this, folks!

Thanks, Greg.

Michelle

Does this happen in the 5.x-2.0 release? If so, any chance of a 5.x-2.1 release soon?

I don't think this happens in the 2.0 release but it might.

And yes, I hope to make a 2.1 release within the next week. The 2.x-dev is pretty close to what will be released for 2.1.

Great, thank you!

Automatically closed -- issue fixed for two weeks with no activity.