$_SERVER['DOCUMENT_ROOT'] is very useful, but it is not available with all web servers. Apache has it; IIS doesn't.

I use the following to make my PHP applications work in more situations:<?phpif (!defined("BASE_PATH")) define('BASE_PATH', isset($_SERVER['DOCUMENT_ROOT']) ? $_SERVER['DOCUMENT_ROOT'] : substr($_SERVER['PATH_TRANSLATED'],0, -1*strlen($_SERVER['SCRIPT_NAME'])));?>

...but even that gets tripped up by symlinks to different mount points, etc. You could substitute realpath($_SERVER['PATH_TRANSLATED']), but that function has been reported not to work on some (Windows) servers. One could use the PATH_TRANSLATED for both servers, but I figure if Apache is going to tell me exactly what I want to know, I should listen.

When using symbolic links with PHP, specify a dotslash './page.php' path to ensure that PHP is looking in the right directory with nested requires:

E.g. when the required actual page1.php contains other require statements to, say page2.php, PHP will search the path that the symbolic link points to, instead of the path where the symbolic link lives. To let PHP find the other page2.php in the path of the symbolic link, a require('./page2.php'); statement will solve the puzzle.

This is because require executes the code "as if" it was code written inside of the function, inheriting everything including the scope. But here there is something even more interesting:

<requiredfile.php>:<?php

$this->a.=" is visible also under a require\n";$b="While the variable b is a local variable of the function\n";function FunctionUnderRequire() { echo "But the functions declared inside of a require called from a class function, just as when defined from inside any other function, are always global\n";}?>

If you are experiencing a bug related to using relative paths with include or require, it may be related to a grandparent directory that is executable but not readable. It will cause __FILE__ to return a relative path instead of the full path which it is supposed to show. This manifests itself in interesting ways that can be seemingly unrelated. For instance, I discovered it using the Smarty {debug} command which failed to find its template due to this issue. Please see the following for more details:

This will sound elementary, but for C++ native programmers, be sure NOT to put a '#' in front of your include statements! The parser will not give you an error, but also will not include the file, making for a tedious debugging process.

I love php. But when file can't be included, 'require' or 'require_once' throw fatal error and halt the script, which is almost never desirable on a mission-critical production server. I think it may be better to use something like the following.

Note when calling any require or include function, that the call will block if the script given as the parameter is excecuting.Because of this one should be careful when using blocking functions like sleep() in a script which is included by another.

I have learnt to manipulate this code into an effecitve and easy to use form. I use it with require_once, but it could be used for require.

require_once($_SERVER['DOCUMENT_ROOT'].'/includes/top.php');

This mainly jumps back to the servers document root and then begins to enter the directories defined until it finds the file. In this case it would go back to the root of the server, or whatever your document root is, and then enter includes. there it would search for the top.php file. Simple to use, yet effective...espcially for people like me who re-use code or move files to different directories. I don't have to fix the includes, because they all work the same way.

If you use relativ paths in a php script (file A) that can be required by another php script (file B), be aware that the relativ paths in file A will be relativ to the directory, where file B is stored. You can use the following syntax in file A, to be sure that the paths are relativ to the directory of file A:

Thanks a lot for this information Brian! This drove me nuts for many hours! This is the first information I found in the web that a white page can be caused by a require -> your script will die if the file is not found!!!

Just for those who may wonder about receiving E_WARNING (in custom error handlers) - PHP generates an E_WARNING when require or require_once fails - and before control returns to your script, it generates an E_COMPILE_ERROR.

So when require() or require_once() fails - don't be surprised to see two messages in your logs (if you have your logging setup this way) - once for the E_WARNING caught by your custom error handler, and once for getting the error from error_get_last() in your shutdown function (which is the actual E_COMPILE_ERROR you were expecting)