In the first article of this series, we covered some fundamental PHP application development concepts. Directory structure, file naming, and basic coding conventions were discussed. If you missed that article, you can find it here (http://www.devshed.com/c/a/PHP/PHP-Application-Development-Part-One/). In this article, we continue with the basics of PHP applications by discussing application configuration, data storage, logging and error handling. We will cover some of the basic considerations when approaching these issues and evaluate our options in regard to implementation, efficiency and maintainability.

With any application, there is a need to centralize certain information. Things like database credentials, file paths, constants, and initialization variables and options should be isolated from working code and managed in as centralized a way as possible. This allows you to alter these values in a centralized location rather than across any number of files.

Centralizing Your Configuration 

The need for centralized configuration is critical in any application, and is quite possibly the single strongest contributing factor to code maintainability. There are a number of approaches to this issue; it presents a particular problem when evaluating flexibility versus efficiency. The most typical methods for storing configuration files are with standard PHP files, XML files and INI files. Examples of a configuration file that contains only database credentials would look like the following.

 PHP
 <?php
 $settings[‘db’][‘user’] = ‘root’;
 $settings[‘db’][‘pass’] = ‘’;
 $settings[‘db’][‘host’] = ‘localhost’;
 $settings[‘db’][‘name’] = ‘test’;
 ?>

 INI
 ; settings
 [db]
 user = root
 pass =
 host = localhost
 name = test

 XML
 <settings>
  <db>
   <user>root</user>
   <pass></pass>
   <host>localhost</host>
   <name>test</name>
  </db>
 </settings>

These files are fairly straightforward, each containing a username, password, hostname and default database. Implementing the PHP file is simple enough – simply include it with the “require_once” function and no further processing is required, the “$settings” array is ready to use. The PHP version is also the least maintainable, in that it looks just like any other code and is not especially easy to read.

Using the INI file is not quite as simple, but requires only using the “parse_ini” function to retrieve the values from the file into an array. The INI file is much easier to read than the PHP version, but it could still be better. The XML version is by far the slowest, requiring at least some string matching and at most parsing the entire file. The tradeoff is evident in the semantic, easy to read nature of XML. XML files are also easily managed by a large number of programs, require the least explanation for other developers to implement, and offer the greatest portability to other modern scripting languages. This means that configuration could be shared by Java, Python, .NET, or Perl applications, for example, with ease.

Realistically, the processing time between each of these files is almost entirely negligible. However, as configuration files grow to store other information, that changes. For the most scalability and raw speed, using a PHP configuration file is the best bet, but I personally advocate the use of XML. The tradeoff for maintainability is worth it so long as you minimize the amount of XML parsed on every script page.

This is simply my opinion, and any of these options will do. In addition to using a variable to hold system settings, you have the option of storing settings in constants. Deciding what data should be stored as a constant and what data should be stored in a system variable is mostly a matter of preference, though I prefer to store system configuration in a settings array or object, and system messages and frequently used values (such as the number of seconds in a day or the maximum dimensions of uploaded images) in constants. The following list contains some common information to store in configuration files.

1. Database credentials
   
2. File paths
   
3. System strings and error messages
   
4. Constants for frequently used system values

Centralizing important system information is critical to the maintainability of any application and is invaluable when handing off a project to a new developer, because understanding how system data is managed is one of the first steps in understanding an unfamiliar application.