A Tour of PHP.INI

Share this article

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

Frequently Asked Questions (FAQs) about PHP.ini

What is the purpose of the PHP.ini file in PHP?

The PHP.ini file is a crucial component of any PHP installation. It is the primary configuration file for PHP, and it controls many aspects of PHP’s behavior. Variables such as error logging, file timeouts, resource limits, and upload sizes can all be controlled through the PHP.ini file. This file is read each time PHP is initialized, i.e., for each request in a web server setup.

How can I locate my PHP.ini file?

The location of the PHP.ini file can vary depending on your operating system and the specific configuration of your server. However, you can find the location by creating a PHP file with the phpinfo() function, which will display a large amount of information about your PHP installation, including the location of the PHP.ini file.

How can I modify the PHP.ini file?

To modify the PHP.ini file, you will need to have access to the server’s file system. Once you’ve located the file, you can open it in a text editor, make your changes, and then save the file. After saving, you’ll need to restart your web server for the changes to take effect.

What are some common settings that might be adjusted in the PHP.ini file?

Some common settings that you might adjust in the PHP.ini file include the maximum file upload size (upload_max_filesize), the maximum amount of memory a script may consume (memory_limit), and the maximum execution time for each script (max_execution_time).

Can I have multiple PHP.ini files?

Yes, PHP allows for multiple PHP.ini files. You can have one main PHP.ini file and then override or extend those settings with additional .ini files in specific directories. This can be useful for managing settings on a per-project basis.

What is the syntax for setting values in the PHP.ini file?

The syntax for setting values in the PHP.ini file is straightforward. Each setting is on a new line, with the setting name followed by an equals sign and then the value. Comments can be added with a semicolon at the start of the line.

How can I check if my changes to the PHP.ini file have taken effect?

After making changes to the PHP.ini file and restarting your web server, you can use the phpinfo() function again to check the current settings. If your changes have taken effect, they should be reflected in the output from phpinfo().

What should I do if I get an error when trying to modify the PHP.ini file?

If you get an error when trying to modify the PHP.ini file, it’s likely that you don’t have the necessary permissions. You may need to contact your hosting provider or system administrator to get the necessary permissions.

Can I change the PHP.ini settings at runtime?

Yes, PHP provides the ini_set() function, which allows you to change certain PHP.ini settings at runtime. However, not all settings can be changed this way, and any changes made with ini_set() only last for the duration of the script.

What happens if there is an error in my PHP.ini file?

If there is an error in your PHP.ini file, PHP may fail to start, or it may start with incorrect settings. If you’re having trouble with PHP and suspect an issue with your PHP.ini file, you can check the PHP error log for any related messages.

Callum HopkinsCallum Hopkins
View Author

Callum Hopkins is a designer and front-end developer with over 6 years web experience and has 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, and has a love for complex coding functions and beautiful design. Callum works as a developer for Deer Digital LTD and runs his own personal blog at callumeuanhopkins.co.uk where he writes thought provoking articles.

Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week
Loading form