usage of $_SERVER['DOCUMENT_ROOT'] wont work with cli php [#1780398]

When using cli php (like "drush rs /"), the variable $_SERVER['DOCUMENT_ROOT'] is not set. (pathologic.module, line 247)

According to this issue posted for drush earlier, it is rather suggested to use things like the DRUPAL_ROOT constant or the drupal_get_path method.

Pathologic is especially interesting to use when developing locally using "drush rs", which is now not possible.

Comments

Comment #1

Garrett Albright CreditAttribution: Garrett Albright commented 11 September 2012 at 11:17

The thing is that DRUPAL_ROOT and such work within the root directory of the Drupal installation, but what that particular piece of code is doing is finding if a file is within the web server's document root, but not within the Drupal root. See this issue for the issue which prompted this code.

That being said, either you or I have a special case going on here. When I run either php -a or drush php-eval on either OS X and Ubuntu Linux and then do a print_r($_SERVER);, $_SERVER['DOCUMENT_ROOT'] is always set, albeit to an empty string. I actually did check this before committing this code, and just re-confirmed it. Could you confirm or deny this on your machine (that is, using php -a and drush php-eval instead of drush rs)? What's your OS and PHP version?

Perhaps rs is unsetting $_SERVER['DOCUMENT_ROOT'] for some reason. I've actually never heard of this Drush command before today…

Comment #2

SeicherlBoB CreditAttribution: SeicherlBoB commented 11 September 2012 at 12:16

I don't know how to use drush php-eval to give me the same/equivalent output, but php -a with print_r($_SERVER); gives me some data, but DOCUMENT_ROOT is empty (it is there, but has no assigned value).

Obviously it has something to do with my php.ini. Or the guys from drush runserver need to explain why this is happening.

But still: is there anything that you could do about that? At least your code states " // @todo Can we always count on $_SERVER['DOCUMENT_ROOT'] being available?"
Obviously the answer is no ;)

I'll see what I can find and report back.

Thank you so far!

Comment #3

Garrett Albright CreditAttribution: Garrett Albright commented 15 September 2012 at 08:20

I don't know how to use drush php-eval to give me the same/equivalent output

drush php-eval 'print_r($_SERVER);'

but php -a with print_r($_SERVER); gives me some data, but DOCUMENT_ROOT is empty (it is there, but has no assigned value).

Well, it's set to an empty string, which is functionally equivalent to "./" in UNIXy terms. At any rate, I've added in some code which will use DRUPAL_ROOT if Drupal is running as a CLI script or if $_SERVER['DOCUMENT_ROOT'] isn't available. This may cause problems with incorrect paths being built and cached, but I'm not sure what else can be done. Since I can't replicate your problem, I'm hoping you can give the next release a try and re-open this issue if it's not fixed for you.

Comment #4

Garrett Albright CreditAttribution: Garrett Albright commented 15 September 2012 at 09:00

Status:

Active

» Fixed

Comment #5

cafuego CreditAttribution: cafuego commented 24 September 2012 at 23:23

Version:	7.x-2.2	» 7.x-2.x-dev
Status:	Fixed	» Needs work

I note that $_SERVER['DOCUMENT_ROOT'] is still used in the code.

That variable can contain data on apache with mod_vhost_alias enabled, but it will NOT point at the correct location.

Instead, you should use getcwd() which, after bootstrap, always returns the system path to the Drupal base directory.

Comment #6

Garrett Albright CreditAttribution: Garrett Albright commented 2 October 2012 at 06:49

Instead, you should use getcwd() which, after bootstrap, always returns the system path to the Drupal base directory.

But remember, in that piece of code, we're trying to find the path to the root web directory, not the path to the Drupal base directory; many times they will be the same, but not always.

That being said, in looking over that bit of code to remind myself what it was doing, I did spot a bug in it - we should be testing that $_SERVER['DOCUMENT_ROOT'] does not exist before using the alternative, instead of testing that it does exist. Perhaps seeing that in the code threw you off as to what it was trying to achieve. I'll get a fix for that in the next release.