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.

Rob Allen has a quick tip for Zend Framework users looking to get to the configuration values in their application.ini file.

Zend_Application will read the data in your application.ini and make it available from your bootstrap's getOptions() method. It then sets the bootstrap as a parameter in the front controller. Note that the top level keys are all normalised to lowercase too. You can then retrieve the options in a number of ways.

He gives examples of pulling them into a controller, an object outside the controller and an interesting conflict that using the Zend_Config component could cause.

Brandon Savage has a new post to his blog today looking at some of the more essential settings to check out in your php.ini file when configuring your install.

When setting up a web server with PHP, there are a number of settings that are critical to consider. PHP 5.3 contains both a development INI file and a production INI file; however, users of older PHP releases (or those who don't have direct control over their INI files) will want to pay attention and make sure that certain settings are configured.

Settings in his list include:

• register_globals
• display_errors
• error_reporting
• short_open_tag

These are just a handful of the settings you can configure in your php.ini. Check out this list for many, many more.

On the PHPFreaks.com website a new tutorial (by Ben Smithers) looks at interfacing checkboxes in your application's form with a backend database.

The concept is actually pretty simple. It involves naming your checkbox as an array and the use of the IN mysql clause. This tutorial aims to give a simple example in the hope that, next time someone asks, I can point them to a tutorial rather than explaining all over again.

They include the database structure, insert statements and the code needed to pull and push the information for the checkboxes.