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'])) {

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mduvergey’s picture

Status: Active » Needs review

Actually, I think my proposed fix needs a review :-)

Simon Georges’s picture

Thanks 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.

DuaelFr’s picture

Here 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 ? :)

Simon Georges’s picture

@mduvergey, could you test the patch provided by Duaelfr, and see if it works for you?

Stevel’s picture

FileSize
486 bytes

#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.

Stevel’s picture

Version: 7.x-2.2 » 7.x-2.x-dev
FileSize
487 bytes

Added a small code style fix in the same line as well.

DuaelFr’s picture

Status: Needs review » Needs work

Even 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.

Stevel’s picture

base_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.

Simon Georges’s picture

Just 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?

DuaelFr’s picture

define('DRUPAL_ROOT', getcwd());

echo DRUPAL_ROOT .'/index.php';
// C:\wamp\www/index.php

echo realpath(DRUPAL_ROOT .'/index.php');
// C:\wamp\www\index.php

You're welcome.

mduvergey’s picture

I must say I didn't think about behavior on Windows systems but it seems my solution would work in that case.

Stevel’s picture

Status: Needs work » Needs review
FileSize
497 bytes

Let'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.

Simon Georges’s picture

@mduvergey, does it work for you?

eode’s picture

I applied:
http://drupal.org/files/front-1917440-6.patch
..and can confirm that it solved my issue.

eode’s picture

..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.

javier.drupal.2012’s picture

HI 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

Simon Georges’s picture

@javier.drupal.2012, is the patch in #12 better?

Simon Georges’s picture

Status: Needs review » Fixed

Since 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.

Simon Georges’s picture

Thanks to everybody for your feedbacks, reviews and suggestions.

javier.drupal.2012’s picture

Hi Simon, I will check it tomorrow
Thanks!

javier.drupal.2012’s picture

Simon, to me it is working, thanks heaps!

eode’s picture

Simon, I haven't been in here in about a week, but I wanted to say thanks for the work you've done. :-)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.