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.

In this recent post to his blog Joe Topjian takes a look at something that has been known to confuse Zend Framework users when trying to set up access control for their application - using the Zend_Acl component.

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.

New from the Make Me Pulse blog is this quick tutorial about bending the URL rewriting that the Zend Framework does to match whatever your needs might be.

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.

Kevin Waterson has posted a new tutorial today looking at a key part of any web application - the configuration settings and how they can be stored.

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.