Simon Holywell has a new post talking about cookie security in PHP, focusing on some of the PHP configuration settings that can help.

The security of session handling in PHP can easily be enhanced through the use of a few configuration settings and the addition of an SSL certificate. Whilst this topic has been covered numerous times before it still bears mentioning with a large number of PHP sites and servers having not implemented these features.

He talks about the httponly flag when setting the cookie/in the configuration, the "use only cookies" for sessions and forcing them to be "secure only".

Chris Jones has a new post to his Oracle blog today talking about the new "opcode" opcode caching that's going to be built into future PHP versions This is the implementation of the Zend Optimizer+ opcode caching in a native language interface. The latest PHP 5.5 snapshots have it included.

The new "opcache" can be seen as substitute for the venerable APC cache, the maintenance of which had become an issue. Note: although opcache is now readily available, there is currently nothing preventing you from using any available (working!) opcode cache in PHP 5.5.

He gives you a quick guide to getting this new opcode caching enabled and compiled into a shiny new download of the PHP 5.5.x branch. You'll need a special command line flag on the compile and to update your php.ini to load the needed shares module. You can also use it if you're on PHP 5.2 or higher either by compiling this source or using this PECL extension.

On PHPMaster.com there's a continuance of a previous article about security in PHP applications talking about a few more considerations when trying to make things secure.

In a previous article, I talked about some common security vulnerabilities that can affect your PHP web application. But there are other things besides those ten (okay, seven) attacks to think about when you're developing. And so, this article offers a compendium of miscellaneous things that are security related; things you should do, things you shouldn't do, things that other people might try to do, whatever it takes to make an article long enough for my editor to be satisfied with it.

He talks some about the settings that you might need to tweak in your "php.ini" server-side configuration file, some hints on filtering data (like using filter_input) and what to watch out for with error reporting. He also mentions session fixation and the protection of user data and passwords to keep them out of the hands of would-be attackers.

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

If you're relatively new to the PHP world, you may be wondering why there has been so much emphasis put on "magic quotes" in the language's past. If you're not entirely sure what they are (and why to avoid them) take a look at this quick overview from XpertDeveloper.com.

First of let me say that Magic Quotes is deprected from the PHP 5.3 and will be removed completely from the PHP 6. But as a developer you might face a situation when you have to work on application which runs on older version of PHP with some older functionality like rely on Magic Quotes.

They introduce the simple concept behind the magic quotes idea and, thankfully, the settings and code you can use to turn it off. It's been deprecated in PHP 5.3 but some older versions came with it enabled. If you're currently running with it on, it's highly recommended to turn it off and refactor your code accordingly.

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.

Brian Swan has a new post today looking at how you can update some PHP settings in your Windows Azure instance - an alternative to redeploying your every time your php.ini file might need an update.

I came across this question on Twitter last week: "How can I turn display_errors on for an application that is running in Windows Azure?" I have to admit that I was stumped. The only thing I could think of was to re-deploy the application with an updated php.ini file. But, I happened to mention this question to Ben Lobaugh who suggested a very simple idea: Store your PHP settings in some durable store external to your application as key-value pairs, then loop through the settings and update them with the ini_set function when a page loads.

He puts a big disclaimer on his suggestion, noting that it's "a hack and only a hack" and can be useful for someone still learning how to work with Azure and deployment. He shows how to use a Table storage to save the values and make them easier for the application to grab at runtime. Using the tools from their SDK, fetching and setting those values is a simple process. An idea like this, while convenient, could potentially cause performance issues down the line, do be careful with this recommendation (and be sure to load test).

Giorgio Sironi has a new post to the DZone.com Web Builder Zone today giving a high-level guide to some of the PHP errors you could encounter in your development time.

While pure object-oriented languages produces mainly exceptions to signal an error, PHP started out as procedural and so it has a wide range of errors that can be raised along with exceptions.

He talks about a few of the most common error related issues:

• Exceptions
• Errors
• Error Types (E_NOTICE, E_PARSE, etc.)
• php.ini directives
• PHP functions for setting error handlers

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 the latest post to her blog Lorna Mitchell talks about some of the issues she had when upgrading to the latest version of SugarCRM (6.0.0).

I noticed that SugarCRM have just released their new version 6.0.0, and since my sugarcrm installation is madly out of date and I'm about to start using it again, I thought I'd just throw the old one away and install from scratch. I had no problems until I reached the final installation stage, when clicking the "install" button would return a 404.

After running through things a few times more, she finally corrected the cause of some of the errors of this final step - increasing the memory_limit setting, upload_file_size as well as installing cURL support for PHP. With these changes, the install worked perfectly.