Undefined index on line 208/210. Caused by Drupal 7 handling Clean URL's differently to Drupal 6.

Thanks - I'll take a look into this.
http://drupalcode.org/viewvc/drupal/contributions/modules/globalredirect...

Looks like this would probably only ever happen on the frontpage, when there is no "q"...?

My first time in Drupal, I'm trying to bring my blog from Squarespace, Drupal 7 all is working well until today trying to install Global Redirect, this message appears.

Notice: Undefined index: q in globalredirect_init() (line 208 of /home/xxxxxx/xxxxxx_html/sites/all/modules/globalredirect/globalredirect.module

I have no idea how to solve this, anyone know if it resolved soon, I think this module is required to bring my content.

Thank you.

@tsvenson: That's interesting. I'll have to take a look at that. You using 7.0-ALPHA6?

Interestingly, I cannot replicate this on my Lighttpd devbox...

Do you have E_NOTICE errors enabled in error_reporting?

It's not an error reporting issue...

If I add:

dpm($_REQUEST);

above line 208, my Lighttpd devbox (Lighttpd 1.4.26 and PHP 5.3) shows that $_REQUST['q'] exists and mimcks the "alias" (or raw) path, wheras $_GET['q'] is the source.

On my other devbox, running Apache 2.2 and PHP 5.2, $_REQUEST contains an entirely different set of values...

I am still investigating as to why this is happening...

NOTE: You must return; just after doing the dpm() otherwise you'll never see it ;)

Drupal 7 handles Clean URL's differently.

In Drupal 6, the RewriteRule pushes the request uri into index.php?q=$1. This is why $_GET['q'] and $_REQUEST['q'] are both set.

In Drupal 7, the RewriteRule simply sets all URL's to go to index.php. drupal_environment_initialize then handles the URL via request_path.

This difference in behaviour means there is no $_REQUEST['q'].

In addition, my Lighttpd box only works because my Lua Script for Clean URL's mimicks Drupal 6's htaccess. I guess it's a miracle Drupal 7 works on my devbox at all! ;-)

Thanks for that Thomas.

The issue is nothing to do with any other module - it is simple a failure to comply with a complete change in how URL's are handles in Drupal 7. My fault :-)

Well that didn't go well - first test run after "fixing" it... 56 passes, 54 fails and 2 exceptions!

EDIT: Of course... it would help if I gave the test bot the devbox password ;-)

I've committed several major fixes to the Drupal 7 branch - care to test?

hi

this bug is presented in the 7.13 tested on a drupal alpha 6

# Notice: Undefined index: q in globalredirect_init() (line 208 of ./modules/globalredirect/globalredirect.module).
# Notice: Undefined index: q in globalredirect_init() (line 210 of ./modules/globalredirect/globalredirect.module).

drupal crashs total and i cant join any site.

del and install the new dev works fine

thanks for the work

getting the same notices.
site becomes unnavigatable after enabling the module.

Global Redirect 1.3-alpha1
Drupal 7 alpha6

then if i replace the 7-x-1.3-alpha1 version with the 7-x-1.x-dev, it starts working again and i get no more notices

Global Redirect 1.x-dev
July 17, 2010 - 01:07
Drupal 7 alpha6

looks like its fixed

Marked the following issue as duplicates of this issue:
#905808: Unable to access administration after activation
#938126: unable to access site after module enabling
#886070: endless redirect loop on most pages

I am also having this problem and a workaround the error message is changing

<?php
  if ($_REQUEST['q'] != $prefix . $alias) {
    // If it's not just a slash or user has deslash on, redirect
    if (str_replace($prefix . $alias, '', $_REQUEST['q']) != '/' || $settings['deslash']) {
      drupal_goto($alias, $options, 301);
    }
  }
?>

to

<?php
  if (isset($_REQUEST['q']) && $_REQUEST['q'] != $prefix . $alias) {
    // If it's not just a slash or user has deslash on, redirect
    if (str_replace($prefix . $alias, '', $_REQUEST['q']) != '/' || $settings['deslash']) {
      drupal_goto($alias, $options, 301);
    }
  }
?>

for the file: globalredirect/globalredirect.module at line 208.

For some reason q is not defined in _REQUEST, this may be related to how the dashboard javascript is handling the url changes.

#9 seems to explain this.

So the question is, is it correct to use a isset() here as a solution or is the bug elsewere?

Just to confirm I had the same scenario / solution as #18 above.

I'm also getting this on d7-rc2. If I enable clean URLs and install Global Redirect the site becomes unusable.

I'm also getting this on d7-rc3.

Same thing on d7-rc4

subscribe

I'm also getting this on Drupal 7 final version. Please, fix it, it blocks me from using Drupal 7.

Marking this as Active (instead of "Needs Review"), as the patches committed at #15 were a long time ago and it appears people are still finding this issue even with those changes.

Actually, my previous post (#27) was wrong. The fixes committed at #15 did repair the problem - I've just tested against the 7.x-1.x-dev, and the problem is gone. (My mistake for assuming that an alpha from last July could not have been the most recent release).

Now that D7 is live, please could we have a formal release (beta if necessary) for this module, so that people downloading D7 don't install the 7.x-1.3-Alpha1 version of this module by mistake and lose access to their site as a result?

Im just confirming the simpletest runs and I'll push out a 1.3 release so it's inline with 6.x.

I have pushed out a 1.3 release which is based on the dev branch as of today.

http://drupal.org/node/1015896

:-)