I have seen this:
include( dirname(__FILE__) . DIRECTORY_SEPARATOR . 'my_file.php');
include( 'my_file.php' );
Files are included based on the file path given or, if none is given, the include_path specified. If the file isn't found in the include_path, include() will finally check in the calling script's own directory and the current working directory before failing. The include() construct will emit a warning if it cannot find a file; this is different behavior from require(), which will emit a fatal error.
Let's say I have a (fake) directory structure like:
.../root/ /app bootstrap.php /scripts something/ somescript.php /public index.php
Now assume that
bootstrap.php has some code included for setting up database connections or some other kind of boostrapping stuff.
Assume you want to include a file in
boostrap.php's folder called
init.php. Now, to avoid scanning the entire include path with
include 'init.php', you could use
There's a problem though. That
./ will be relative to the script that included
bootstrap.php. (Technically speaking, it will be relative to the working directory.)
dirname(__FILE__) allows you to get an absolute path (and thus avoid an include path search) without relying on the working directory being the directory in which
(Note: since PHP 5.3, you can use
__DIR__ in place of
Now, why not just use include
As odd as it is at first though,
. is not guaranteed to be in the include path. Sometimes to avoid useless
stat()'s people remove it from the include path when they are rarely include files in the same directory (why search the current directory when you know includes are never going to be there?).
Note: About half of this answer is address in a rather old post: What's better of require(dirname(__FILE__).'/'.'myParent.php') than just require('myParent.php')?