Making PHP Applications Portable « Web Development

“Portable” means that your application is able to run on any PHP webserver with minimal fuss.

Ensuring portability is an absolute must for programs that are packaged and distributed for public consumption, like WordPress or MediaWiki.  But, you should aim for portability in all of your applications.  The ideal is a one or two-step installation process and only two or three system requirements:  1. Webserver (IIS/Apache/etc), 2. PHP v5.X+, 3. MySQL 4+.

Why Make it Portable?

For one, it keeps things simple.  The concept of portability meshes well with the KISS concept that I value so highly.

Secondly, it makes deploying your application to a new server simple if the need ever arises.

Thirdly, it enables you to easily distribute your package to the world if that is your intention.  I, for one, simply hate installing web applications on my server with long lists of prerequisites and a lengthy install process, especially if one of those steps is to install another set of libraries (e.g. from PEAR) before installing the application itself.

Finally, portability makes distributed development easier.  Many applications are developed on Windows but run on Linux.  Portable applications eliminate the headaches involved in trying to get the to two environments (development & production) to match.

How to Make Your Application Portable

A truly portable application will work out-of-the-box, and require minimal configuration.  It will also automatically check the environment for specific configuration or prerequisites that do happen to be required.  Below are five things to try and avoid, and one thing to try and do to ensure your application is portable:

1. Don’t rely on exotic PHP extensions

I’m talking about extensions that are not bundled with PHP or found pre-installed on most hosting providers.  If you do require a specific PHP extension that is not bundled with PHP, you should check for the existence of the extension at the beginning of the program’s execution.

For example, many of my applications require JSON libraries, which some versions of PHP5 do not include, so I check for the existence of the json_encode function when the application first runs.

2. Don’t rely on separate installation of PEAR Libraries

Don’t get me wrong; PEAR is great.  But, you shouldn’t predicate the successful execution of your application on your users installing external libraries.  Most PEAR libraries are dependent on other PEAR libraries, and require the user to figure out and install multiple packages.  Your application should not require this pre-setup, and it should run with all of the required libraries and classes included.

3. Don’t rely on command-line configuration

If you want your application to be truly portable, you have to cater to the crowd who has only FTP access to their servers.  Yes, these folks are few-and-far-between, but coding with them in mind ensures that your application setup procedure is as simple as possible.  This means that your installation instructions should be completely void of anything that says “login to the command line and run xyz command”.

Definitely don’t rely on the user to have administrative privileges on the server.  This means to try to avoide the necessity for external software or packages (although this is unavoidable sometimes).

4. Don’t rely on the program to be run on a specific operating system

This one is  a stretch for some people, but truly portable applications can run on Windows, Linux, or MAC servers without fuss.  I make all my applications portable enough to run on any OS simply because we use SVN for development, which requires my developers to download fully working copies of the project to their desktops.  Since my developers use Windows & Mac, and my servers run Linux, my applications have to be cross-platform compatible.

5. Don’t rely on PHP.INI customizations

A lot of PHP applications I have tried won’t work with magic quotes (or vice versa), or won’t work without the user increasing the amount of memory or upload file size for PHP.   Before making these nice-to-have’s required, ask yourself if you can find a different way to solve the problem.

For situations where it is unavoidable to ensure that a specific directive is set, your application should automatically attempt to override the default PHP.INI customization via ini_set() and then inform the user in plain English that the ini value needs to be changed.

6. Do include a mechanism in the application to test for required prerequisites at the very start of execution (or as part of the installation process)

Rather than have your application spit out a generic PHP error message when it comes across an environment setting that it doesn’t like, you should include a function that performs a “pre-flight checklist” at the beginning of runtime for each session, or at least the very first time your application is run.

Next week, I will show you how to do exactly this by creating a hook in CodeIgniter that thoroughly tests the environment, and informs the user how to remedy issues.

For Further Reading, I recommend:

• Writing Portable PHP Code from PHPwact.org
• Making Your PHP Code Portable from mtdev.com