Cal Evans has posted the first part of his look at DTAP - development, testing, acceptance and production - and how it applies to PHP development.

There are four primary systems that need to be set up and isolated. And they are described by the acronym DTAP-Development, Testing, Acceptance, and Production. One thing that has changed recently, though, is that these systems no longer have to mean separate hardware.

He gives an overview of each, setting out definitions to be used for the rest of the series with the next part discussing some of the "smaller moving pieces" of the process.

Christopher Jones has noted that the latest version of the OCI8 drivers for PHP (in the PECL extension) have been pushed to the current stable package.

HP's OCI8 1.3.3 has support for Oracle's DRCP connection pooling and Fast Application Notification technologies giving it improved scalability and high availability. Overall, the re-architecture of the connection code is more stable. It fixes some obscure edge case issues and lets it handle re-started DB's better. Basic functionality is unchanged.

You can find out more about the package and download this latest edition from its PECL page or check out the whitepaper they recent;y wrote up about PHP and Oracle scalability.

In a response to this post on the PHP 10.0 Blog, Richard Heyes offers a method for what Stas was wanting:

OK, then what we do if something weird happens in production and we want to see the errors, but we don't want others to see them? [...] Maybe PHP could have some setting like display_errors=local which would enable display_errors for requests originating from developer machine but would disable it when outsider accesses it?

Richard's solution checks the HTTP_HOST value of the current request and, based on whether it's marked as "live" or "dev", uses a ini_set to change the display_errors setting to true/false.

Since he didn't come across any issues or bug reports, Richard Heyes has officially released his SMTP class for PHP5 as "out of public beta" and ready for production use.

I've not added any new features to the class; I've simply updated it to be, well, better. Plus it uses PHP5's object model better. It's really just an update, ie if you're using the old version and it works, then you have no real reason to update it.

You can check out the source here and an example of it in action here.

The MT-Soft blog has posted a (basic but full of great info) new guide on ensuring that your PHP installation is a very secure place for your application to live.

This article shows the basic steps in securing PHP, one of the most popular scripting languages used to create dynamic web pages. In order to avoid repeating information covered in the previous article, only the main differences related to the process of securing Apache will be described.

They've broken it up into a few different sections:

• System they'll be using (operating system, functionality assumed, security assumptions)
• Preparing the software
• Installing PHP
• Chrooting the server
• Configuring PHP
• Protecting against CSS and SQL injection attacks

Check out the full tutorial to fill in the blanks of this outline.

Dave Dash has shared his tips on moving things smoothly from your development to production environments when using symfony and the Apache mod_rewrite module.

I think a common problem for some symfony developers that aren't too familiar with Apache's Mod Rewrite is when they move from a development environment that uses an explicit controller (e.g. frontend_dev.php is requested from the server explicitly) to their production app which implicitly calls index.php (e.g. '/' or some other route is passed to index.php) things stop working.

To combat the situation is easy - it's a simple update to the .htaccess file default to symfony to add a LoadModule line to start up mod_rewrite.

In an effort to get some thought going about ways to encourage security in PHP applications, Stas has posted an idea about a simplified php.ini setting - production=On.

His idea is that, with this setting on, the PHP installation would:

• disable display errors
• disable phpinfo()
• turn expose_php off
• make max_execution_time/memory_limit reasonable
• and possibly a few others that some developers forget to set correctly

PHP 5 has been presented as a revolution, a lot of new features have been added and a lot of projects have been made. But only a small group of hosters seem interested in supporting PHP 5 on their web servers. It is not so useful to have a beautiful programming language to use if we can't apply it to production environments.

We MUST use PHP 5 to help it growing until it become the standard...

PHP5 has seen a pretty slow adoption rate so far, but according to some statistics, its usage has been picking up lately - even among hosting providers.