A Tour of PHP.INI

By Callum Hopkins

Working with PHP 7.1? Download our FREE PHP 7.1 Cheat Sheet!

Anyone who has a server using PHP has undoubtedly heard of php.ini – it’s the configuration file used to control and customize PHP’s run-time behavior. It provides a simple way to configure settings for such things as:

  • Upload Directories
  • Log Errors
  • Maximum Script execution time
  • File Upload limit

… and so much more.

php.ini is the first file PHP looks for when starting up because of the importance of the configuration directives it sets. However if you make changes to your php.ini, it will requires a server reboot before the changes take effect.

A pre-made php.ini file with recommended settings ships with PHP. Many hosting providers who support PHP allow you some way of customizing php.ini directives so you can tweak PHP’s behavior just the way you like it. In these instances, PHP only uses the values for the directives which you have specified in your custom php.ini file; any settings you don’t declare in your file are assigned their respective values from the original php.ini and PHP’s built-in defaults.

In this article I’ll give an overview of some important settings I believe you should be concerned with when tweaking your own php.ini file. This is just a personal selection of course, and everyone will develop their own preferences over time, so I recommend you do some solid research into the myriad of configuration directives available in php.ini.

The location of php.ini depends on the server and how PHP was installed. For the purposes of this article I’ll assume it’s at /usr/local/lib/php/php.ini. Your path may be different. To find where your php.ini file is located, you can use the phpinfo() function.

So let’s begin our tour of the php.ini file, the first stop: the engine directive.

PHP Engine

engine = On

The first configuration setting is the engine directive, which basically controls whether the PHP engine is turned on or off. This directive is responsible for determining whether PHP is available to your scripts, and setting it to Off will prevent you from using PHP at all.

You may be wondering why I have included this, since it’s obvious you should leave this enabled if you plan on using PHP. The simple answer is having this in a custom php.ini file allows you have take full control of the PHP server within your custom configuration. You will be setting all your custom rules for PHP in the file, and I believe it’s inefficient to have the master switch hidden in another file rather than present in the file in which you will be visiting most often.

The next stop is to a directive which I regard as being the most important when it comes to writing portable code: short_open_tag.

Short Tags

short_open_tag = On

The short_open_tag directive allows developers to use short tags, which in a nutshell are when a developer would write <? instead of <?php. An example using short tags is:

<? echo "Hello World"; ?>

compared to using full tags:

<?php echo "Hello World"; ?>

With short_open_tag enabled, you can use both <? and <?php. However, there a very big downside to using short-tags, especially when your are developing anything that is intended to be used on various PHP servers. Short tags are enabled by default but can cause some parsing problems so some people turn the option off. If your code depends on short tags then it would not run on their server. It is highly recommended that you turn off short-tags in your php.ini when developing portable code to prevent yourself from using them.

Next, I’ll highlight an option which everyone, at any level of development ability, will have dealt with without even knowing it: output buffering.

Output Buffering

output_buffering = Off

You have probably seen a derivative of the following message on a few occasions: Cannot add header information headers already sent. This warning comes about when a scripts attempts to set an HTTP header (an element not seen by the user but processed by the web browser none the less) after it has already started sending output back to the user’s browser. Enabling output_buffering causes PHP to delay sending the headers, and instead send them and the output from your script at the same time once the script has finished processing. This allows you to change header values at any point during your script’s execution.

It’s generally considered that output_buffering is a directive that can be left turned on without causing any major complications, so it can be useful to leave it turned on in case its functionality is ever needed. Personally, I prefer to leave it off because if you develop a WordPress plugin for example that will be run on many different servers, you’ll need to watch that your code don’t rely on automatic output buffering to be turned on.

Moving on, let’s have a look at two options which can be of great benefit if you’re creating a website which the visual templates share common header and footer files: auto_prepend_file and auto_append_file.

Automatic Headers and Footers

auto_prepend_file = "header.php"
auto_append_file = "footer.php"

The auto_prepend_file and auto_append_file directives let you to tell PHP to append a file to your script’s output and append a file at the end. This is reminiscent of the get_header() and get_footer() functions in WordPress, and can be very useful if you are using common header and footer files. Be aware however that the files specified with these directives will used for every PHP file, which may not be be exactly what you want.

An alternative use for auto_prepend_file and auto_append_file is to set up a simple execution timer which can be used to benchmark the time it takes to generate a page. For example, the file loaded by auto_prepend_file might contain:

$t1 = microtime(true);

… and the file for auto_append_file would contain:

$t2 = microtime(true); 
$elapsed = $t2 - $t1;
$logFile = "/tmp/timing.txt";
file_put_contents($logFile, $elapsed . " " . $_SERVER["REQUEST_URI"] . "n", FILE_APPEND);

The next stop on our tour is PHP’s error handling directives.

Handling Errors

error_reporting = E_ALL|E_STRICT
display_errors = Off
log_errors = On
error_log = "/var/log/php_errors.log" 

The settings I’ve shown above is the recommended configuration for PHP’s error reporting behavior in a production environment. An error in your script can either be non-fatal (such as a notice or warning), or fatal which stops your script from executing. Regardless of whether the error is fatal or non-fatal, this configuration will instruct PHP not to display the error message in its output and instead save it to an error log file.

Turning on display_errors will output details of the error to your browser, which is handy for development purposes. But once your site is deployed, error messages could prove distracting to your users and even provide malicious users with insight on how to attack your site. It’s better to send error messages to a log file to which only you and other administrators will have access to. This can be done by setting the error_log directive. The error messages that would normally be displayed in the browser will then be logged to the specified file instead.

For more information on error handling, check out Sneha Heda’s article, Error Handling in PHP.

The final stop on our tour is to have a quick look at time zones in PHP.

Time Zones

date.timezone = "US/Central"

This setting is not set by default in php.ini and when E_STRICT reporting is enabled, PHP will issue warnings any time you use a date or time function in your script. This can be easily resolved by setting the date.timezone directive in your configuration file.

This option is often over looked by developers, but it is one that if configured correctly, can reduce the chance of a huge amount of complications accruing in your PHP script somewhere down the road. A full list of supported time zones is available in the online documentation.


It is highly recommenced that all web developers take a look through their server’s php.ini file and familiarize themselves with its contents, and personalize some of the directives as appropriate. The configuration directives in this article should give you a good place to start. If you’re using a shared host, the configuration set up by the hosting company may not always be the best and may not compliment your coding style. Check with your provider to learn what options are available to you to customize your environment.

Image via Laborant / Shutterstock

  • imtiaz

    Thanks good tutorial
    Were I can find book about PHP configration or more tutorials like above

  • Nice introduction to php.ini. Thanks a lot.

  • rush it

    I had never even given php.ini a thought. Thanks for pointing out how important it is. (Article would have benefited from some proof-reading.)

  • Jan

    Thanks for the quick introduction. Haven’t really use the PHP.ini file in a big way. Didn’t really need to tweak it that much. However I notice one of my hosting has both PHP.ini and fastphp.ini, any difference with these?

  • Thanks Mr Callum
    nice article. One question, are you sure that if you use a custom php.ini that anything you leave is undeclared remains as set in the server php.ini? My understanding from my server techs in a Cpanel environment is that you have to recreate the whole php.ini file or else the local settings revert to the PHP defaults. So th ened result in a shared hosting environment is that custom ini files are to be avoided if possible as they aren’t then easy to keep the non customised settings in sync with any global server changes. Any clarification much appreciated
    Regards Nick Sibbing

  • As an addition to the timezone information; it is generally a good idea to set the timezone to something universal, such as “Etc/UTC”. Doing this will likely result in less subtle bugs due to timezone difference issue. Timezone handling is hard enough without adding in extra complexity of having to do extra unnecessary conversions. Using “Etc/UTC”, you simply render dates in your user’s desired timezone (based on their persisted setting) on the fly — the “Etc/UTC” time is the only one ever stored in the database.

  • Very informative article. As the author mentioned everyone must have a look at their php.ini file.

  • The nice thing about php.ini is that if you put a (modified) copy of it in another directory, then this modified copy will override the original php.ini settings.

  • Great info about php.ini. Hope you will describe more options in future. Thanks!

  • Hello, I would have liked to sign up for your PHP Master Newsletter, but your input box says my email is invalid, actually both of my email addresses seem to be invalid. What’s up?

  • Organicit

    You mention server reboot for php.ini changes to take effect. Did you mean web server?

  • Good article. Think line every web designer should know a basic php and how to configure it. I was thinking like I’ll never use it but there was time when i had deadline for my university in london where I was doing my web designer papers, and I had to create some cool things with php, php.ini was my problem that day. So … Take a couple min guys and read it step by step . Thanks once again.

  • The server does not need a reboot after changing php.ini, it is only the webserver that must be restarted.

Get the latest in PHP, once a week, for free.