In function front_page_init() there is a test that checks that the currently running script is /index.php :
if (!empty($_SERVER['SCRIPT_FILENAME']) && DRUPAL_ROOT .'/index.php' != $_SERVER['SCRIPT_FILENAME']) {
The problem is DRUPAL_ROOT is set with the value returned by the getcwd() PHP function, which value is a canonicalized path.
On the other hand, $_SERVER['SCRIPT_FILENAME'] is not necessarily using a canonicalized path (it depends on the web server configuration one is using).
The following test fixes the issue:
if (!empty($_SERVER['SCRIPT_FILENAME']) && DRUPAL_ROOT .'/index.php' != realpath(dirname($_SERVER['SCRIPT_FILENAME'])) . '/' . basename($_SERVER['SCRIPT_FILENAME'])) {
Comment | File | Size | Author |
---|---|---|---|
#12 | front-1917440-12.patch | 497 bytes | Stevel |
#6 | front-1917440-6.patch | 487 bytes | Stevel |
#5 | front-1917440.patch | 486 bytes | Stevel |
#3 | front-fix_non_index_calls-1917440-3.patch | 478 bytes | DuaelFr |
Comments
Comment #1
mduvergey CreditAttribution: mduvergey commentedActually, I think my proposed fix needs a review :-)
Comment #2
Simon Georges CreditAttribution: Simon Georges commentedThanks for the report. I think that's gonna take someone better than me with PHP / server configuration... But I'm willing to commit a fix as soon as everybody agrees on the solution.
Comment #3
DuaelFrHere is a patch assuming that if the SCRIPT_FILENAME contains index.php this is the Drupal core's one.
(Find me a case where it could be an other one)
Did I mention that this patch is part of the #1day1patch initiative ? :)
Comment #4
Simon Georges CreditAttribution: Simon Georges commented@mduvergey, could you test the patch provided by Duaelfr, and see if it works for you?
Comment #5
Stevel CreditAttribution: Stevel commented#3: There might be an index.php in some test case, in another module...
mduvergey: is there a reason you don't use realpath on the entire SCRIPT_FILENAME? That should give the same result and is simpler.
Comment #6
Stevel CreditAttribution: Stevel commentedAdded a small code style fix in the same line as well.
Comment #7
DuaelFrEven if it were an index.php file in a module, it would not be intended to be accessed via direct URL (hook_menu exists to define real Drupal URLs) so I think we do not have to manage this (mis)use case.
Moreover, if Simon judges your approach better than mine, you should at least use base_path() to handle the case of Drupal subdirectory installation.
Comment #8
Stevel CreditAttribution: Stevel commentedbase_path() gives the URL part while DRUPAL_ROOT gives the filesystem path on the server, which is not the same thing (See http://api.drupal.org/api/drupal/includes!common.inc/function/base_path/7), so I believe it is used correctly here.
An example where index.php is used, is in the civicrm installer: It expects the user to run the civicrm-provided index.php (which does a BOOSTRAP_FULL thus loading all modules)
edit: I'll leave it to you to mark as needs review / rtbc again if the explanation above is satisfying, or reply otherwise.
Comment #9
Simon Georges CreditAttribution: Simon Georges commentedJust a thought, but what about the behaviour in Windows systems? Isn't
DRUPAL_ROOT.'/index.php'
always different of realpath() because of the slashes and backslashes? Could someone eventually test?Comment #10
DuaelFrYou're welcome.
Comment #11
mduvergey CreditAttribution: mduvergey commentedI must say I didn't think about behavior on Windows systems but it seems my solution would work in that case.
Comment #12
Stevel CreditAttribution: Stevel commentedLet's realpath both sides of the equation then. That should solve the windows vs linux problem. It would also make it more robust in case DRUPAL_ROOT is not the real path for some reason.
Another way would be to use the DIRECTORY_SEPARATOR constant.
Comment #13
Simon Georges CreditAttribution: Simon Georges commented@mduvergey, does it work for you?
Comment #14
eode CreditAttribution: eode commentedI applied:
http://drupal.org/files/front-1917440-6.patch
..and can confirm that it solved my issue.
Comment #15
eode CreditAttribution: eode commented..I think that's worth an update to the release version, since the fix didn't make it into the 2.2 release. ..it'll save a lot of time for people who are installing it for the first time.
Comment #16
javier.drupal.2012 CreditAttribution: javier.drupal.2012 commentedHI all, I have applied the #14 patch and my front page is still not working. I have just installed the last release and my front page configuration has stopped working.
I have configured the paths for two roles I have in my application. Front page is not redirecting to new configured ones.
Any help? Thanks
Comment #17
Simon Georges CreditAttribution: Simon Georges commented@javier.drupal.2012, is the patch in #12 better?
Comment #18
Simon Georges CreditAttribution: Simon Georges commentedSince the module is currently broken, I've decided to commit #12 (since it couldn't be worse than it is).
I'll release 2.3 as well.
Comment #19
Simon Georges CreditAttribution: Simon Georges commentedThanks to everybody for your feedbacks, reviews and suggestions.
Comment #20
javier.drupal.2012 CreditAttribution: javier.drupal.2012 commentedHi Simon, I will check it tomorrow
Thanks!
Comment #21
javier.drupal.2012 CreditAttribution: javier.drupal.2012 commentedSimon, to me it is working, thanks heaps!
Comment #22
eode CreditAttribution: eode commentedSimon, I haven't been in here in about a week, but I wanted to say thanks for the work you've done. :-)