| Project: | Persistent URL |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
I'm using the Auto Assign Role module to set up a custom registration path at the url /somesite/join. I have set up a PURL prefix of /somesite. I'm using the Sites module (which integrates with PURL) to set up a subsite based on the PURL path prefix of /somesite.
Accessing /somesite/join results in a 404.
Accessing /somesite/somesite/join also results in a 404
Accessing /join also results in a 404!
If I change the URL of the page created by Auto Assign Role to something else that doesn't contain the PURL prefix 'somesite' (/join for example) it works fine.
In summary, if a system path contains the PURL prefix within it's URL, it seems to be impossible to access!
I've tried using the patch at #608916: Allow global purl disable by url or context (or other factors possibly) to disable PURL at the URL /somesite/join, but it makes no difference.
Any ideas?!
Comments
#1
I should have also noted that attempting to access /somesite/somesite/join results in a redirect to /somesite/join - but that still gives the 404.
#2
Sounds similar to #1016474: Conflict between aliases and purl, though this is unrelated to pathauto and the patch in that issue doesn't help.
#3
Attached patch *seems* to resolve the issue. It means that system defined paths do not needlessly have the path prefix removed. So, I can now create a View with the url /purlprefix/myview, and access it at /purlprefix/myview without getting a 404. It also works for all the examples I outlined in the original post. Other paths get rewritten as normal.
I suspect that I may have severely crippled PURL by doing this, but right now everything seems to function ok and I can still access those system paths that contain the PURL prefix in their path.