In a new post to his site Pascal Martin shares some thoughts about why INI directives are evil, mostly in how they could be used to enable/disable major pieces of functionality in the PHP language.

A few times, while evolutions were discussed for PHP 7, someone suggested a new feature could be optional, depending on an INI configuration directive — the idea being each user could then enable it or not.

Still, the idea of directives that could change, sometimes deeply, the behavior of a programming language… It scares me!

He goes back in time a bit to talk about a feature like this that was once a part of the language (happily removed now): "magic quotes". He points out that, while the intent was to provide security to submitted data, the results were disastrous if it was moved to another server without the setting enabled. He also points out some of the steps that have to be taken when a new directive controlling a major feature is introduced - even worse if you're creating a product to run on other peoples' servers.

In any case, before suggesting "but they could allow us to enable or not this feature with a simple INI directive" for ideas as critical as a weak or strict typing mechanism, ask yourself: do you really want two languages with very distinct behaviors, and applications and libraries that work only on some combinations of configuration values?

Edd Mann (of the Three Devs & A Maybe podcast) has shared a method of session storage he worked up to help increase performance in his application. He shows how to store sessions in memory with the help of TMPFS.

Yesterday I was looking through some application logs and noticed a significant bottleneck with I/O reads in the implemented file cache. [...] This was when I found 'tmpfs', saving me from all sorts of issues relating to adding yet another application to the production stack. 'tmpfs' appears as a mounted partition on your system, however, under the hood it allocates and uses a section of physical memory (non-persistent through reboots). [...] his results in the desired speed boosts, without tampering with the application logic itself. Even better, if the mount is unsuccessful for some reason, it will safety fall-back to using the persistent hard-disk solution.

Since PHP sessions make it easy to change the "save_path" location for the data in an ini value, setup is easy. He includes the needed configuration change and the commands you'll need to mount the tmpfs partition on your local file system.

On PHPBuilder.com today they have a new post showing different configuration patterns for getting localized settings into your applications. They show the use of INI files, PHP scripts, text files, XML data and a database call.

PHP is a cross platform language. It is a server based application so we must think about the configuration settings of the PHP software. There are various ways of creating configurable PHP applications. The configuration flexibility comes as a built in feature in PHP. But we must understand the requirement clearly before making an application configurable. This article explores different PHP configuration patterns and their implementation.

For each of the options mentioned, there's a brief description of what the method is, some of the common uses and a code example showing a basic implementation. The database pattern is the only one without a code example as the database interface varies widely from application to application.

In his latest post Joshua Thjissen looks at the creation of a custom configuration loader for a Symfony2 application. This kind of thing is mostly useful for parsing configurations that Symfony2 doesn't already know how to parse.

It happens more and more: large projects where your symfony2 site is just a small part in the big picture. Lots of additional components might even play a bigger part, especially when you are dealing with asynchronous components which are connected through message queues for instance. [...] Our first idea is obvious: symfony2 uses by default a parameters.yml file, which gets imported by your configuration (config.yml) [...] So nothing new here and this setup works perfectly, provided that your symfony2 project is the ONLY thing that needs to be configured. As soon as you add multiple other components (like gearman or activemq workers that need to connect to solr too), they need to share this configuration.

His solution involves falling back to the INI-file format that's known as useful for several different languages and tools. Because of how Symfony2 reads these files though (only looking for "parameters") he's had to create a "ConfFileLoader" instance of the "FileLoader" that uses the parse_ini_file method to parse the data and return it back to the main container as parameters. He also includes the code/config you'll need to implement this custom loader into your application.

In this recent post to his blog, Konr Ness has benchmarked the components that the Zend Framework uses to read in different types of configuration files - JSON, native PHP arrays, INI, XML and YAML files.

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.

Jason Gilmore gets "back to basics" in a new tutorial with a look at managing configuration in your ini file to tune it to just what you need.

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.

In a new post today Rob Allen shows a method you can drop into your Zend Framework application to allow Zend_Config_Ini to take in a string instead of being restricted to loading a file.

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.

Gonzalo Ayuso has a new post to his blog today looking at how he uses PHP classes to store configuration information for easier retrieval.

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.

In a new post to his blog Brian Moon looks at a handy piece of functionality that comes with the default PHP installations (and is used by several major frameworks like this one) - using INI files to store settings for an application.

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.

In this new post to his blog today Brandon Savage looks at configuration options for PHP apps and gives some examples to help you get the thought process started for your development.

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.