Jump to:
| Project: | Path redirect |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
When I enter a redirect from a non-existing URL to one that does exist, I get a 404, not the desired target page.
Given [source] and [target], where [source] is the local path I want to redirect from (references a page that doesn't exist) and [target] is known to be a good URL, if I click the test link the page redirects to [target]?q=[source], where the page is shown as a system 404 page, not as the actual page.
There's what sounds like a related problem entered against the 6.x version that may be related to wrong settings on the database table, so before puzzling over this further should the first column in the table be 'rid' or 'nid'? (My table has 'rid' as first column.) However, editing the table settings in the database as shown here does not seem to fix the problem. (I deleted the existing redirects before re-creating and testing.)
Server is Apache/2.0.46. Global Redirect is installed, and I am redirecting to target pages that have URL aliases. (I've disabled Global Redirect and it doesn't seem to make a difference.)
I also get the same results if I make the target the node address for the same node, instead of the URL alias.
Comments
#1
Additional information: Problem may only occur if [source] ends with the string "index.html". (Can't say for sure without more exhaustive testing than I have time for right now.)
Does not occur with extension ".htm" or ".htmm", so I'm guessing this is maybe a regexp issue or something?
#2
Update again: After more testing, "index.html" is not required. In most cases, simply using the extensin ".html" in the source is sufficient. (Though not in all cases.)
Unfortunately, I need to use ".html" in the source, since that's how the pages I'm replacing are named.
#3
Also, having two underscores in the source path seems to cause problems. Tested with one, two, three and four, and only had a failure when there were two.
#4
I'm seeing something similar. Any URL with a forward slash (or multiple slashes), such as:
some/deep/page
is URL-encoded before being inserted into the DB. The slashes become %2F's, and the re-direct doesn't work. I believe the culprit is line 285:
$form_values['path'] = urlencode(preg_replace('/\?.*/', '', $form_values['path'])) . (strstr($form_values['path'], '?') ? preg_replace('/.*(\?)/', '$1', $form_values['path']) : '');I'd offer a patch, but I'm not 100% sure of what's going on here. (It seems like url encoding the string could be overkill.) If the sole intention of this line is to allow spaces in the FROM field, then maybe do just a:
$form_values['path'] = trim($form_values['path']); // in case there are spaces at either end of string$form_values['path'] = str_replace (' ', '%20', $form_values['path']);
Or am I completely missing something?
#5
P.s. -- escoles, can you look at the values in the {path_redirect} table in your database? If so, do the values look correct?
Do any of your FROM paths have non-alphanumeric characters?
#6
Re. non-alpha characters: The only non-alpha characters were underscores, slashes and hyphens.
Re. database: I'll look at it and get back. I apologize for not doing more to isolate this issue -- I had to move straight from site launch into other pressing issues, and just haven't had the time. I will do a test install on another site and see if it holds there, as well. (While it could be a configuration issue, this does seem to me to be clearly server-independent at this point.)
#7
I'm getting this behavior with the latest 5.x-1.x-dev.
If I edit a URL with a forward slash it saves in the DB as %2F. I can edit the DB back to "/" and it sticks. Editing it again throws the %2F back in.
Any suggestions?
#8
Please test using the latest 5.x-1.x-dev.
#9
For some reason adding a redirect from a non-existing path to an existing path doesn't actually redirect. Both paths now appear valid.
#10
This shouldn't be a problem with the 6.x-1.x branch. This was about the URLs being improperly encoded when being saved to the database. If this is not the same exact issue you are encountering, please open a new issue.
#11
I found another alias in my alias table. Deleted that and now I get the 404 described above.
#12
http://drupal.org/node/632566 Opened a new issue for the 6.x version of this problem.
#13
I discovered this problem as well as soon as I upgraded a site from 5.x to 6.x
#14
D5 is no longer supported.