Kevin Schroeder has posted the results of some research he did around using the "AllowOverride" setting in Apache. He found some interesting differences when it was set to "all".

Commonly known as .htaccess, AllowOverride is a neat little feature that allows you to tweak the server's behavior without modifying the configuration file or restarting the server. [...] Beyond the obvious security problems of allowing configuration modifications in a public document root there is also a performance impact. What happens with AllowOverride is that Apache will do an open() call on each parent directory from the requested file onward.

He includes the output from a strace call in the post - first showing the function calls with it set to "none" then the same request with the setting on "all". More "open" calls are being made in the second run, increasing the execution time by a decent amount.

Kevin Schroeder has a new post to his site today wondering about the "max_input_time" setting for PHP and why some recommend it being a large number despite the (usually) fast time PHP has accepting input.

I asked a question on Twitter on why some of the recommend max_input_time settings seem to be ridiculously large. Some of the defaults I've seen have been upwards of 60 seconds. However, after thinking about it I was a little confused as to why a C program (i.e. PHP) would take so long to process string input. The reason I was thinking about this was because I was thinking about ways to protect PHP from denial of service attacks.

So he ran some tests to see just how effective changes in this setting could be and how much time a typical PHP request would need to take in input. Using a Zend Framework 2 HTTP client, he simulated POSTS and tracked the start and end times for a file upload. He includes the timing results in the post based on both this setup and a change to only post regular text-based form data.

Rob Allen has a new post to his site sharing some examples of the configuration possibilities for the ZendServiceManager module of the Zend Framework 2.

ZendServiceManager is usually configured in two places: an array in a config file or a method within your Module class. In either case, you provide a nested array of configuration information. [...] Within the service_manager array, there are a set of nested arrays which are generally used to configure how you want a given class to be instantiated. the names of these sub-arrays are hardcoded, so you just need to learn their names and the difference between them.

He lists out each of the options and includes a brief example and description for each. Values include "invokables", "aliases" and "initializers". He also touches on controllers, view helpers and controller plugins and how they hook into the ServiceManager.

On the ServerGrove blog, there's a quick post with a handy tip for the Symfony2 + Assetic users out there - how to get it to recognize the "less" module.

Unfortunately the Symfony documentation does not provide any details on how to configure Assetic to use LESS. There is a blog post by Dustin Dobervich that gives some pointers, but after following the instructions, Assetic issued the following error: Cannot find module 'less'. We searched around without much success. After several tries, we nailed the configuration.

It's an easy two-step process: first you be sure you have "npm" (the package manager) installed on your system, then you modify your Symfony app.yml file to point to the Node modules path.

On PHPMaster.com today Callum Hopkins has written up an introduction to the php.ini, the heart and soul of any PHP installation. With configuration options for just about everything, it can be confusing. This tutorial hits some of the highs and most commonly updated settings.

Anyone who has a server using PHP has undoubtedly heard of php.ini - it's the configuration file used to control and customize PHP's run-time behavior. It provides a simple way to configure settings. [...] In this article I'll give an overview of some important settings I believe you should be concerned with when tweaking your own php.ini file.

The tutorial's broken up into a few different topics:

• the PHP engine
• Short tags
• Output buffering
• Automatic headers and footers
• Handling errors
• Time zones

In a new post to his blog Robert Basic takes a brief look at importing Symfony2 security settings from a bundle he's been creating back into the main configuration.

I started to work on/figuring out the security part in Symfony2 and one part where the docs fail so far is to explain how to import security settings from a bundle. Once I put some thinking into it, it's pretty easy actually. Simply import the needed security file in your main config file.

His trick is to use the "imports" key in his YAML config file to define the resource to pull from in his config.xml. More information on the format of the security file can be found here in the Symfony documentation. It helps you define authentication mechanisms, authorization models and working with access control and roles.

In this new post to his blog Kevin Schroeder suggests that there's something even better than doing the typical caching inline (request, write to cache) - pre-caching.

I just had an epiphany. I've talked about pre-caching content before and the benefits thereof before. But this is the first time I realized not only that there are benefits, but that doing it is BETTER than caching inline. Let me sum up... no, there is to much. Let me explain.

He gives an example of how a typical application might cache - when it finds a "miss" for the data it's trying to pull. A simple cache is easy, but what happens if it uses a configuration value that could change (like the username/password in his second example). Pre-caching would eliminate the risk since the setting would be known to be valid when the cache is generated.

Brian Swan has a new post to his blog about how you can change the database settings in your SQL Server database (with a connection using the PDO_SQLSRV driver) through a SQL query.

The short story is this: If you are using the PDO_SQLSRV driver and you want to execute a query that changes a database setting (e.g. SET NOCOUNT ON), use the PDO::query method with the PDO::SQLSRV_ATTR_DIRECT_QUERY attribute. If you use PDO::query without that attribute, the database setting you expected to change may not be applied to subsequent queries. The longer story has to do with why this is the case, which is what I'll explain in this post.

The problem is that, when changes to settings are made, they don't seem to stick. Future queries act like they were never even updated. The solution to the problem is to use that PDO::SQLSRV_ATTR_DIRECT_QUERY attribute on the connection (set to true). You can see the difference in execution from this to this.

On the SitePoint PHP blog today Craig Buckler talks about uploading large files in your PHP application. He points to two other resources - this manual page and this introductory tutorial about handling file uploads to get the ball rolling.

One of the most popular uses is image uploads. Your users can submit photographs from a form without resorting to FTP or other convoluted methods. HTML5 and Flash also permit drag and drop, so the operation is likely to become easier as browsers evolve. This is where the problems can begin.

He points out the large size of the images most modern cameras work with and how PHP, with its basic settings, can't handle a lot of the resulting images. He mentions the upload_max_filesize and post_max_size settings you can set in either your php.ini or via an .htaccess (or even in your script). There's also a few helpful comments with more tips on large file handling.

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.