If you application relies on parsing one or several config files each time it is bootstrapped it is important that you select a file format that is fast to parse. But you also want to select a config file format that is easy for a human to read and edit. In a recent application I am building I also had the need to write modifications to config files, so I also benchmarked the Zend_Config_Writer components.

He includes both the sample configuration INI file and the benchmarking script he used to measure the results (all configurations were read from external files, even the native PHP option). His results were pretty predictable (with the exception of YAML reading) with the standard INI file coming in second to the native PHP arrays, but having the advantage of being more readable.

While PHP's configuration capabilities are indeed powerful, the sheer breadth and different ways in which these configuration directives can be set are often confusing and downright intimidating to newcomers. So in this article it worth meandering from the typically intermediate-level discussion and instead offer some insight into PHP's configuration-specific infrastructure.

He starts by mentioning the phpinfo function that generates the complete list of current settings for your installation. With that in hand and an idea of what settings are out there, he starts going through some of the basics of working with ini settings - updating the php.ini, setting values via a .htaccess file and chancing them directly in the executing script.

With PHP 5.3 however there is is a new function called parse_ini_string() which will allow us to load arbitrary ini string into Zend_Config objects. This can't go into Zend Framework 1 though due to our PHP 5.2.4 minimum version requirement. As I needed this for a project, I extended Zend_Config_Ini to support this feature, which means simply overloading a single method.

He includes the code for the method - the App_Config_Ini class that includes a _parseIniFile method that checks to see if the last four characters of the input value are ".ini". If so, it loads like normal. If not, it assumes it's a configuration string and parses it with the new parse_ini_string method.

In my last projects I'm using something I think is useful and it's not a common practice in our PHP projects. That's is the usage of a plain PHP's class for the application's configuration. Let me explain it. Normally we use ini file for configuration. [...] There are many standard options. Why I prefer a different one then? I like plain PHP classes because the IDE helps me with autocompletion. The usage is quite simple.

His example uses a standard class to store the configuration values, one that can be loaded into a project and lets you call the configuration values statically. He gives two examples of how this is helpful in a standard IDE with autocompletion.

One of the challenges of this [three tier server setup] is where and how to store the connection information for all these services. We have done several things in the past. The most common thing is to store this information in a PHP file. [...] We have taken [it] one step further using some PHP ini trickeration. We use ini files that are loaded at PHP's startup and therefore the information is kept in PHP's memory at all times.

They use the get_cfg_var function and the "--with-config-file-scan-dir" option to tell PHP to automatically load in the ini files it finds in the named directory. He gives an example of both a simple configuration and a more complex situation where a MySQL instance can read from the ini file containing the username/password/host information.

One of the decisions that has to be made each time an application is written for distribution is how best to set up the configuration files. There are a number of different approaches taken to this: some opt to use the define() function and define constants, while others use large arrays.

He points out a few "overlooked options" that some developers might no consider when working with configuration files like class constants and ini files (which PHP can parse natively). A few code snippets are included to show examples of them in use.

It seems everyone, myself included, has a bit of a hard time first grasping Zend_Acl. For the time being, I've settled on a simple solution. It's party based on the solution given in the Zend Framework in Action book. I hope you get some use out of it.

His example uses the Zend_Config component to configure his roles and a more centralized approach to validating access for the users - more rules in the INI config file and a custom MyACL class/AclHelper tat are called from the bootstrap file to evaluate where the user can and cant go for each request.

Today for a good website's referencement in Google, it's necessary to have an URL rewriting. [...] If your application is based on ZF, we have a htaccess base file which will redirect all php files to the boostrap (what is the bootstrap ?), and ZF classes will manage all redirection rules. How to implement the URL rewriting with ZF classes ?

He sets up a config file (an ini file) with the routing instructions the framework will need to adhere to and shows how to get the application to include it and match against it for routing rules. His example sets a default route and several regular expression-based routes to remap requests right where they need to go.

PHP applications come in many shapes and sizes. Some used locally from command line, and more commonly, for web based applications. More often than not, regardless of size or type, some form of configuration variables will be stored for global access. [...] Each options has its pros and cons. Here each of these options is explored to see which method is right for your application.

He looks at four different options:

• an ini file that can be parsed/modified directly by PHP
• an XML file slightly more complex, but still simple for PHP to use
• a PHP file with things like PHP arrays defining settings
• and a database with one or more configuration tables

Each type comes with some example code and format to give you an idea of how they'd work.

The previous update (0.9.26) updated the utility with an improved randomness fixing a few issues with an ini setting and the uploadprogress extension as well as adding in a few new settings and updates to the randomizing functions that come included in PHP.

The 0.9.27 update (the most current) updates the patch with a lazy loading change that allows it to work correctly on systems that have it disabled by default (causing the previous patch to not work).

You can grab this latest release, 0.9.27, from the suhosin website.