PHP

A Tour of PHP.INI

    Callum Hopkins
    Share

    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:

    <?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.

    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.

    Summary

    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