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.

Until recently, accepting credit cards on a website was expensive and complicated. But that was before Stripe: a radically different and insanely awesome credit card processing company. Today, I'll show you how to start accepting cards in 30 minutes or less - without spending a dime.

They step you through the whole process you'll need to get the full flow set up:

• Install an SSL Certificate (on your server)
• Create an Account
• Create Your Payment Form
• Collect The Form Values
• Request a Token
• Create a Server-Side Script

Screenshots of the Stripe interface, HTML, Javascript and PHP code are all included - everything you need to make the simple card handling work. One of the keys to how Stripe deals with credit cards is that you provide it the card info, it gives you a token. Your app uses this to work with the card instead of storing the card information in your database (also making it more secure).

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.

New web development frameworks, promising rapid development and easy deployment, are sprouting out at a more rapid pace than you can keep up. In the last article, we looked at the various factors you'd have to consider when deciding on a framework. Today, we are going to look at the various frameworks available for each facet of web development.

PHP tools that made the list include CakePHP, the Zend Framework, Kohana and Symfony. Frameworks from some of the other languages include ASP.NET, Ruby on Rails, jQuery and Blueprint.

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.