I put together a set of test sites to test some patches for path_redirect on MySQL and PG. It's a checkout of the 5.3 tag plus the 1.1-beta1 of path_redirect. Lo and behold, the redirection doesn't work. I haven't entirely understood the problem yet, but I see that $query in path_redirect_init is node/1 instead of the path I see in the URL, foo/bar. So of course that doesn't match the intended row in the table, and the redirect fails.

I actually had the same problem when updating the module for D6. I had to change the beginning of path_redirect_init from this:

  if (isset($_GET['q'])) {
    $query = $_GET['q'];
  }

...to this:

  $query = '';
  if (isset($_SERVER['QUERY_STRING'])) {
    $query = preg_replace('/^q=/', '', $_SERVER['QUERY_STRING']);
  }

I can test the same change on path_redirect-5.x-1.1-beta1, but I think I may be missing the root of the problem. (Why is $_GET['q'] now giving me the destination path instead of the requested path?)

Comments

HorsePunchKid’s picture

HorsePunchKid commented
Priority: Critical » Normal
Status: Active » Needs review

Of course this only happens if you're redirecting from a path that actually exists (i.e. resolves to something in the {url_alias} table). So perhaps this is not so critical after all. Maybe related to hass's issue?

HorsePunchKid’s picture

HorsePunchKid commented
Priority: Normal » Critical

To complete the graph linking these issues, I think this may fix it.

HorsePunchKid’s picture

HorsePunchKid commented
Status: Needs review » Closed (duplicate)

I suppose this is a duplicate, when it comes down to it. The fix is to first store what the user types in for the path and redirect, rather than what they resolve to, and second to redirect based on the original path that was requested, rather than whatever $_GET['q'] gets translated into.