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

Comments

Status:Active» Needs review

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

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.

StatusFileSize
new478 bytes

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

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

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

Version:7.x-2.2» 7.x-2.x-dev
StatusFileSize
new487 bytes

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

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.

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.

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?

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

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

Status:Needs work» Needs review
StatusFileSize
new497 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.

@mduvergey, does it work for you?

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

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

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

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

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.

Thanks to everybody for your feedbacks, reviews and suggestions.

Hi Simon, I will check it tomorrow
Thanks!

Simon, to me it is working, thanks heaps!

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.