Posted by WiseTeck on September 4, 2008 at 5:00pm
| Project: | Global Redirect |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | nicholasThompson |
| Status: | needs review |
Issue Summary
the fix for Admodule http://drupal.org/node/278199 introduce a new bug. This solution will not work if drupal is installed in subdirectory (eg: htdocs/subfolder/drupal/ ).
In this case the value for $_SERVER['SCRIPT_NAME'] is not 'index.php', but /subfolder/drupal/index.php.
This small patch will fix it.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| globalredirect-subdirectory.patch | 631 bytes | Ignored | None | None |
Comments
#1
This is a good point...
My concern here is if someone (stupidly) calls their nested bootstrap index.php, then this patch will cause issues too.
So, lets take a look at the opions... Drupal could be installed in:
Based on these two scenarios, the modules could then have a bootstrap in...
Your patch solves these issues, but what if a developer releases a module with a bootstrap as...
So essentially - for a given Drupal Install, what's the difference between these two paths?
The latter could (POSSIBLY) be an install of drupal which happens to be nested 6 levels down.
This problem is unlikely and very edge case but I cant help but think there must be a very elegant solution for this!
#2
Yeah, got your point. The ambiguity between
could be solved by using base_path()
If /subfolder/sites/all/modules/mymodule/index.php would be a nested 6 level drupal setup then the base_path would be '/subfolder/sites/all/modules/mymodule/'
so the test should be
if ($_SERVER['SCRIPT_NAME'] != base_path().'index.php') return false;#3
WiseTeck... Not quite... base_path() simply represents the path that the script was called in. It could be root or it could be a module.
I believe the way the Ad module gets around this is to, upon install, store in a variable the location of module itself. This allows it to compare the current URL to the "known" module location.
I'm wondering if this could be a feature of the new globalredirect admin I've added to 5.x-dev... By default the ONLY URL which should have redirects is
base_path() . 'index.php'and this is decided upon module install/update. In the admin area, the site admin can control the paths which ARE allowed to be redirected upon...#4
what about storing the base_path() during installation of the module?
like this:
variable_set('globalredirect_base_path', base_path());
and then in the hook:
$base_path = variable_get('globalredirect_base_path', base_path());
if ($_SERVER['SCRIPT_NAME'] != $base_path.'index.php') return false;
anyone see any problems with this?
#5
gielfeldt: Seems like a sensible solution...
#6
#278615: Global Redirect fails if Drupal is installed inside a subdirectory marked as duplicate.
#7
this patch works well in the most cases,
but how about the issue,
any good solution for this?
I installed my drupal in a subfolder, and I used the .htaccess to redirect to this subfolder, so it looks like in the root folder.
like this:
/.htaccess (redirect to subfolder)
/subfolder/index.php
but the url still looks in root folder, such as my domain, http://www.joke4me.com/, not in www.joke4me.com/drupal,
but actually, I installed the drupal in /drupal, so the global redirect didn't work for me.
Finally, I used the hard code on the line
if ($_SERVER['SCRIPT_NAME'] != $GLOBALS['base_path'] .'index.php') return FALSE;
to
if ($_SERVER['SCRIPT_NAME'] != '/drupal/index.php') return FALSE;
now, works well.
anybody have a good solution?
#8
I have a patch which is an update to the module that solves this problem (I believe) in an effective manner.
The basic problem appears to be that there is no deterministic method to determine the directory in which Drupal is installed. This seems hard for me to believe, but I have not found any method. The current module implementation uses base_path() -- this will fail if Drupal is installed in a subdirectory and the document root directory has an .htaccess rule that directs Drupal requests to the drupal install directory.
The proposed solutions above use $_SERVER['SCRIPT_NAME'], and this will work in almost all cases, since in the Drupal context it will be index.php ... but not quite always, as noted in comments above. So my proposed alternative gets around this problem as follows:
Far from rocket science, but for those of us who have (or had) valid reasons to install Drupal somewhere other than the document root, this solution works, is lightweight and should work in the more usual case where Drupal is installed in docroot. (Disclaimer: I have not tested this in the normal case, beyond a code inspection to verify that the case is covered properly).
#9
I too have Drupal installed in a subdirectory with a .htaccess redirecting to it from the root and found the GR was not doing anything at all.
I confirm that code (based on #8) works with 6.x-1.2 for my use case - see attached patch file.
#10
[edited]
Upon trying the patch in #8 above a second time, I got it working.
Even though in the new Global Redirect configuration settings under Drupal Base Path it looks like the proper path is in there by default, one must click "Save configuration" in order to make it work.
#11
The patch worked for me as well. Thanks.
#12
#13
sub
#14
subscribing
#15
I have also tested the fixed detailed in #8 for a Drupal install in htdocs\example.com\drupal with example.com used as the way to access the website. I also did a test with example.com/drupal to access the website. Both worked.
The key thing to do as instructed in #10 and save the configuration of Global Redirect module, before trying the new feature.
Looking forward to thing coming out in a new patch. :)
#16
I should also add that, ideally this new variable should be eventually moved into the Drupal core, probably in the settings.php file. Surely there must be other modules which need to know this information.
#17
Sorry for the successive postings regarding this issue. However I like to test things offline or even do large changes to a website using a local copy and then push it to the active website. With this new variable, it is now slightly install specific. While the explicit install directory is not listed, if one does not have exactly the same setup on a local version of the website to that of the live site, there are problems when using a backup of one on the other. Note that this problem can be worked around with the local version of the website made to look similar to the live one, but there can be limitations.
So back to my previous comment, this new variable should really get moved to the settings.php. It seems to be the local and correct place for it.
#18
when settings.php is being processed, are there cases where $_SERVER['SCRIPT_NAME'] would either be undefined or not be the desired Drupal root index.php file? or where the directory component of SCRIPT_NAME would not be a correct value for globalredirect_base_path?
i get the reasoning behind the path (i think) and it looks right to me, but as others above have said, i move copies of my site around quite a bit, and try to keep literal file paths out of the config files. but it seems that it would work to put
$conf['globalredirect_base_path'] = dirname($_SERVER['SCRIPT_NAME']);into settings.php.i am not sure how to test the case where a module contains an index.php file, though.
#19
Subscribing.
#20
I believe the way some modules get around this is, if the script is called index.php, they look for an "includes/bootstrap.inc" file relative to the current file. If that fails, they traverse up the path looking for a folder containing index.php AND a relative subfolder containing bootstrap.inc.
This shouldn't be too "heavy" to add as a variable. Maybe one which gets refreshed on a cache rebuild? (in which case, it could be a cached variable in the {cache} table?)
#21
the patche from #9 seemed to work but not for the alpha version. Any chance we can get a re-roll? Extended Path Aliases needs the alpha version of GR to work.
#22
subscribing/bookmarking
#23
sub
#24
sub
#25
+1
#26
sub
#27
sub+