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.
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
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
So let’s begin our tour of the
php.ini file, the first stop: the
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 = On
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"; ?>
short_open_tag enabled, you can use both
<?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 = 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:
Automatic Headers and Footers
auto_prepend_file = "header.php" auto_append_file = "footer.php"
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_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_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:
<?php $t1 = microtime(true);
… and the file for
auto_append_file would contain:
<?php $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.
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.
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.
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
Callum Hopkins is a designer and front-end developer with over 6 years web experience and a Bachelors degree in Design for Digital Media. With knowledge in both design and development, he is able to influence both sides of the web building process. Callum has a love for complex coding functions and beautiful design. He runs his own personal blog at where he writes thought-provoking articles.