However, PHP as a platform is far from homogenous. With many different versions installed and the vast configurability of php.ini, there can be a great deal of variation from PHP installation to PHP installation. PHP developers often ask what should I target? The question is the same if you want to write the next WordPress, or if you want to make sure your code is reusable for the next client that knocks on your door.

Nexen has been publishing PHP version adoption statistics for some time. Damien Seguy has really gone the extra step now by collecting and publishing configuration statistics. These are generated from scanning publicly available phpinfo() output.

The stats range from useful to blog candy.

One thing to keep in mind is sample bias. Damien compared the php version number of the sample against the version data collected from expose php and found they correlate well. But, perhaps there is a bias toward certain configuration settings (or versions) among those who have public phpinfo() data and those who do not. (The stats do have suitable disclaimers.)

Its hard to look at stats like this and decide what they represent. According to the Zend blog, 81% of their customers are using PHP 5, while the nexen monthly numbers report 11%. I think its fair to say that all of Zend’s customers use PHP, while many servers that expose_php are domain parking or serving static pages. What is the adoption rate for php 5? Who knows.

It would be interesting to see the correlation between those installations with expose_php off and the monthly version data, collected from the broader set of servers with expose_php on. I think it would also be interesting to see what functions are being disabled with disable_functions. Which extensions are being loaded? How many servers are running an opcode cache?

Which version of PHP to use? PHP 5 versus PHP 4? Unless you are constrained by legacy PHP 4, the answer is definitely PHP 5. Targeting PHP 4 isn’t going to make you the next WordPress. Its just going to put you as far behind the version adoption curve as they are.

PHP 5 is vastly easier to develop in than PHP 4. Development is expensive. Hosting is cheap. Don’t let the tail wag your dog. If your host doesn’t support 5, change hosts. PHP 5 hosting is not rocket science.

I know the decision is that not simple, but the excuses for remaining with PHP 4 are dwindling.

Which configuration options to target? There was some talk recently on the PHP internals list about creating a recommended .ini profile for development environments and one for production environments. I think this is a great idea. Hopefully, then folks installing PHP can choose a profile instead of setting individual .ini options. Perhaps this would help reign in some variability and reduce some Paradox of choice style unhappiness.

“The bottom line is that security has been set back nearly six years in the past 18 months,” Alan Paller, director of research for the SANS Institute, wrote in an E-mail. “Six years ago, attackers targeted operating systems and the operating system vendors didn’t do automated patching. In the intervening years, automated patching protected everyone from government to grandma. Now the attackers are targeting popular applications, and the vendors of those applications do not do automated patching.”

I’ve advocated better web application installation for a while, but as a usability issue. Increasingly, it is also a security issue. Just another example of why I think the PEAR installer is important. (and why I hope Zend PHP Framework is released on a PEAR channel.)

I didn’t find a “powered by PEAR” section on the PEAR website. Can anyone recommend some large, widely deployed end user oriented applications based on PEAR? I want to try going through the installation process in some challenging environments. I’m just trying to get a feel for best practices and potential problems with installing PEAR and applications that depend on PEAR.

I have to agree with the sentiment. I quit my last job (in 2000) to work in web development largely for this reason. I worked on a custom ERP package that was deployed in a few dozen manufacturing plants. Deployment for developed code was a nightmare. It wouldn’t surprise me if the effort involved with deploying a change was an order of magnitude greater than making it. Testing, writing installation scripts, testing the installation scripts, sending a person to the plant to perform the installation and train the users, repeating for every plant. Pray that there were no database changes.

The thing that attracted me to web development was that it felt much more ‘light weight,’ and frankly, just more fun.

1. Download.
2. Locate the application icon in your download directory and optionally move it to another location.
3. Double click on the application icon to run.

This is the essence of what apple calls Drag and Drop installation.

Unfortunately, installing web applications has not reached this level of ease of use refinement. An end user oriented web application might require that you:

1. Download to your local machine (Using browser)
2. Unpack (using 3rd party archive tool)
3. Locate and edit configuration files, potentially requiring a knowledge of file system paths on the server, database names, etc.
4. Upload (Using yet another tool, such as ftp)
5. Change file permissions to allow files to be written to some directories on the server
6. Install external components, such as pear modules
7. Compile PHP to include required modules
8. Edit .htaccess to setup include_path’s and mod_rewrite

Hardly “Drag and Drop.” It would be nice to have something like a drag and drop capability for end users. In this case, the applications could just be moved to the desired location in DOCUMENT_ROOT and run by pointing the browser to it.

Apple has several supporting technologies that facilitate drag and drop install:

Grouping

“Bundles provide an elegant solution to the problem of grouping related code and resources together.” PHP has the tarball or the zip file, but this requires an unpacking stage. If the user lacks shell access, then the unpacking stage must occur offline. Where is the PHP equivelent of the .JAR or the .WAR? How can the unpack stage be eliminated?

Hiding

One of the advantages of the bundle is the ability to hide internal resources from the end user. Web applications have the need to hide internal resources. Typically, this can be done with PHP by moving files outside of your DOCUMENT_ROOT (adding another installation stage), hiding resources with .htaccess, or giving them .php extensions when possible (typically for config files). Hardly end user friendly techniques.

Sharing

Frameworks are a special type of bundle designed for distributing shared code and resources.

Frameworks have a version capability that helps manage DLL Hell situations, where installing or upgrading one application breaks another via shared dependencies. A Framework bundle may contain multiple versions of the same code, and the OS will link to the correct one. Additionally, framework bundles can be embedded into Application Bundles, so that application will always have a usable version available. Embedding helps facilitate drag and drop install because an additional step is not needed to install shared resources.

I think embedding shared resources (libraries like adodb and wact) is the best way to go for application deployment.

Unfortunately, I think PEAR takes a shared commons attitude and resists embedding because of its desire to be in the include_path.

Preferences

User configuration in OS X is stored in preference files, which are independent files named by application. Well behaved OS X application operate even with their preferences files missing. deleting an applications preference file causes the application to recreate it with the default preferences. (Try deleting an application’s registry keys under windows and see how things go.)

Drag and Drop Web Applications
I think a drag and drop PHP web application should meet the following criteria:

• Make no requirements for PHP_INI_SYSTEM or PHP_INI_PERDIR configuration.
• Make no requirements for .htaccess configuration
• Work with default application level configuration
• Not require writable filesystem permissions
• Not require installing external software
• Not require unarchiving (a wish, i know)
• Not require obscure PHP modules

A wish list, i am sure.

What are best practices for deploying PHP web applications? What applications do this well?

more on PHP deployment.