Incompatible with Global Redirect

I'm also having that issue, "The page isn't redirecting properly" for any page but home. I'm xdebugging currently, hopefully will find something

globalredirect for me, and as pointed out in #1074446: Should PURL weight be higher or lower than other path-related modules? if I modify purl's system weight, it seems to fix... but I'll investigate more

Same problem for me. Disabling Global Redirect fixes the problem. I haven't tried altering the weights.

Same issue here, disabling Global Redirect allowed me to access the site

Same here, and tried it with current dev releases of purl and globalredirect. Unfortunately: (1) purl is one of the dependencies for mobile_tools 2.x and 3.x branches (which one wants to test) AND (2) globalredirect is too valuable to disable. Any progress on making these two play nice together?

I got the same conflict with globalredirect.

The problem is that if $_REQUEST['q'] is defined, globalredirect uses $_REQUEST['q'] to get the request path; if the variable is not defined, it uses something else.

However, purl_init() does

// Initialize a few things so that we can use them without warnings.
...
if (!isset($_REQUEST['q'])) {
 $_REQUEST['q'] = '';
}

so globalredirect thinks we are on the front page.

This code is there for historical reasons and is not used anymore. Even if it was still useful, it could be replaced by explicit checks before using $_REQUEST['q'].

Here is a patch that fixes this and a similar pattern for $_GET['q'].

Thanks for the patch. I'm wary of making all these changes just in case something may be relying on the $_GET part, but I've created and committed a patch that removes the $_REQUEST initialization as it appears that part indeed is not used anymore. This should fix the immediate issue with globalredirect.

Has this patch been added to the dev version? If not, this defect (PURL in conjunction with Global Redirect causes redirect loop) still exists.

It looks like there hasn't been a new rollout of a recommended release since 2011... so @escoles, if you tried the 7.x-1.0-beta1 like I did, it wont work. I can confirm that this bug is fixed in the latest dev release, but man there really needs to be a new recommended release.

i grabbed latest -dev (7.x-1.0-beta1+11-dev (2013-May-24)) and i verified that the patch from #8 is included there; but this does not fix the problem. once i disabled global redirect; issue is gone.

i'll try patch from #7

manually applied patch from #7 to latest -dev and this also does not fix the redirect issue.

added usefull info.

changing title.

as i mentioned above; i just tried the latest -dev (no patches) and site is broken with Global Redirect enabled. with it disabled the site works.

i can see the that the -dev i am trying has the patch from #8 included - this doesn't help.

i manually applied the patch from #7 - this seems to fix things - but will report back after more testing

nope, my bad.. hadn't actually enabled Global Redirect - even with patch from #7 (which includes the one from #8) this still does not work.

I was able to fix a redirect loop caused by enabling globalredirect when I already had a custom provider defined by PURL.

The provider I had was defined like so:

 /**
   * Implements hook_purl_modifiers().
   */
  function MY_MODULE_purl_modifiers() {
    return array(
      'MY_MODULE_purl_provider' => array(
        array(
          'value' => 'prefix',
           'id' => 1
         ),
      ),
    );
  }

Global Redirect redefines the alias from 'prefix/this-page' to '/this-page'. This is then passed to PURL which re-adds the prefix, in the $options array of hook_url_outbound_alter, which then causes a redirect in Global Redirect and an infinite loop occurs as the $options array with the prefix keeps getting fired.

The attached patch checks if Global Redirect is enabled and re-adds the prefix to the $path instead of the $options array which keeps Global Redirect from redirecting from 'this-page' to 'prefix/this-page' and also keeps PURL from adding the unnecessary prefix to the $options array.