From #759844: Overlay does not work with prefixed URL paths [catch]:
There are various issues with hook_url_outbound_alter() and hook_url_inbound_alter() - notably the inability to tell what's happened to paths without running the hooks again in most cases too.
I was looking at the D7 port of globalredirect recently, and that's pretty much broken if anything implements hook_url_inbound_alter() too
One of the main consequences of this is that we are unable to know which is the current URL prefix without calling url() and thus running all the hook_url_outbound_alter() implementations.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | drupal.url-alter-backup.8.patch | 756 bytes | sun |
Comments
Comment #1
sunSounds quite hypothetical to me, although it also scratches the surface of possible issues, of course. But still, to deserve a critical priority, we need an actual problem here.
Comment #2
plachIMO there is nothing hypothetical in being unable to tell which is the current path prefix, if any.
Comment #3
sunSure thing, I completely understand. However, I'm also aware of this problem since Drupal 5, err, ever?
We can certainly backup the original request path/parameters somewhere in $_REQUEST or $GLOBALS, prior to invoking hook implementations, but that's not the end of the world...
Comment #4
catchI think Sun's right, it's not a new problem (global_redirect module also re-invokes the Drupal 6 equivalents, it's just worse in D7), so I'm downgrading to normal - it's a (lot of if you run into it) annoyance rather than complete breakage. I think backing up the path is a good plan.
Comment #5
plachMajor?
Comment #7
plachComment #8
sunI'm not sure whether I fully understand this issue, but here's a patch for starters.
It's relatively tough to find a safe + valid place to backup the original value. Also, not sure whether $_REQUEST['q'] still contains the original, unaltered path?
Comment #10
sunwhuzzup? Did we reveal some code that's not safe against raw $_GET values here?
Comment #11
sun.core commentedSince we changed D7 to no longer have $_GET['q'], this clearly sounds like a regression to me.
Perhaps, instead of that fake __q GET parameter, we should restore sanity and put it into $_REQUEST['q']? That would actually restore full backwards-compatibility with D6 and below.
Comment #12
sunActually, what about http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/reques... ?
Comment #13
plachYes, I was thinking to something about it too. We can compare the original request and the current system path and compute at least the current URL path prefix.
Comment #14
chx commentedI have verified that
request_path()contains the original request path: it's called before settings.php is loaded and the path is static cached unresetable so it will always contain the original path. Take it from here.Comment #15
joelstein commentedSubscribing.
Comment #16
thebuckst0p commentedSubscribe
Comment #17
wmostrey commentedI'm looking into this, along with #774950: Incompatible with hook_url_inbound_alter().
Comment #18
wizonesolutionswmostrey: Any findings?