I finally installed a caching plugin for this site, because I know that I’m so awesome that any day now, millions of beautiful women will be clamoring to visit my website at the same time.  Some things you are just sure of.

While I wait for that day, it makes sense to have a caching plugin anyway.  Let’s count the reasons:

1. It’s super easy, so time investment costs almost nothing,
2. I’m on shared hosting, so every saved bit counts,
3. Caching makes everything faster even when traffic is low, and
4. I never know when I may actually write something useful, and thousands of denziens from the across the Internet will come and bring my poor little Dreamhost server to its knees.

So what is caching anyway?

The Problem

Most websites are data-driven.  That’s a good thing, because without data, you don’t have content, and without content, you don’t have a very good website.  On a web server, your content can be stored basically in one of three places:

1. A Database
2. The Hard-drive
3. The RAM

The thing is, getting data from a database is much slower and requires a ton more resources than getting it from the hard drive.  Likewise, getting data from the hard drive is super slow compared to getting it from the RAM.  Here’s a handy diagram for you visually-oriented folks:

You can’t save your content in the RAM, because it’s not permanent storage.  You could use flat-files, but then you would lose all of the security, multi-access, and other benefits that database systems provide.  So, most sites store their data in slow, but reliable and robust databases.

This means, every time a user wants to view a blog post or other content on your site, the web server has to connect to the database, find the content, retrieve it, and process a bunch of code to turn it into HTML and make it look pretty.  Slow.  If there are 800 raving fans accessing that blog post at the same time, the server has to perform this process 800 times — simultaneously!  And… then the site goes down.

What Caching Does

So: Database = Slow, Robust, Reliable.  RAM = Fast, Volatile, Not permanent.

Can we have the good things without the bad?  Yes we can!  Caching flies in like a superhero on crack to deliver a solution that will work.

Basically, a cache library takes the content in your database and copies it into a flat-file or the RAM.  Then, it instructs your website to load the data from the RAM or file rather than the database when users visit your site.  This way, your server uses fewer resources for each request, but you still get to manage the data using the database, with all of its super-cool features.

The caveat is, if you update the data in your database, the server needs to know to also copy the data in the cache.  Fortunately, most caching systems handle these kinds details automatically.  Sometimes however, you have to manually delete and recopy the cached versions, depending on your cache system and how it is configured.

In most cases, the cached versions are set to expire after a certain amount of time has passed, and then regenerate with the latest fresh data in the database.  You can configure this amount of time to be 30 seconds, five minutes, eight days, or whatever.  If your users can live without up-to-the-second data, then this method of doing things won’t be a problem.

RAM Caching vs Hard Drive Caching

Memory caching is faster, but the cache will have to be regenerated if the server is restarted (not a big deal, IMHO).  File caching is a slower, but will remain in-tact if the server is restarted.

Memory caching requires that you or your systems administrator installs extra software on the server.  Ususally memcache (free).  File caching requires that your webserver software can write files to the hard drives.  Usually involves setting file permissions in Linux.

How to do it in WordPress, Drupal, Etc.

The cool thing about being a web developer in 2010 is that, if you can think of something cool, like caching your WordPress or Mediawiki installation, somebody has probably already created a tool for it and published it as open source.

Prerequisites

Before you start using these cool tools, however, you need to make sure your server can handle caching.  If you’re like 58.07% of websites on the Internet, you use Apache to serve up web pages.  So, the following tools would be good to have already setup.

If you’re on shared hosting, you’ll need to make sure that your server supports these (most good ones do).  If you manage your own server, you can install them yourself.  I’ve included the Ubuntu server commands below for those of you in the latter category:

• Memcache (sudo apt-get install memcached php5-memcache) — This is a piece of software that runs in the background on your server and allows you to store data in the RAM.
• PHP APC (sudo apt-get install php-apc) — This is a cache tool built specifically for PHP.  It does a lot of cool speedy-uppy things for PHP that other, more general cache tools cannot.
• mod_expires (sudo a2enmod expires) — A module for Apache that allows your website to instruct browsers to cache pages and other site resources for a certain length of time before downloading them again from the server.
• mod_headers (sudo a2enmod headers) — A module for Aapche that allows your website to modify headers before they are sent to the client.
• mod_setenvif (sudo a2enmod setenvif) — A module for Apache that allows you to change the way the webserver behaves based on different criteria, such as what browser the visitor is using.
• mod_deflate (sudo a2enmod deflate) — A module for Apache that allows the webserver content to be compressed before sending it over the network; not exactly like caching, but also a performance booster.  Many caching libraries use this.
• mod_rewrite (sudo a2enmod rewrite) – A module for Apache that allows the server to rewrite requests as they come in from the client.  Useful for redirecting clients to cached versions of files without having to invoke PHP, which saves even more time.

Not sure if you have these?  Don’t worry too much — most good caching libraries will let you know.

Popular Caching Libraries

There are a ton of good ones; here’s a sampling:

• WordPress SuperCache — So far as I can tell, this cache system uses files, and it helps guide you through the process of setting up your cache.  There’s even an easy mode with a simple “On/Off” switch, so it couldn’t be simpler:  Install the plugin and turn it on.
• WordPress Total Cache — A more powerful cache tool that lets you cache to memory or files (your choice) depending on what server software you have setup.  There are a ton of settings to manipulate.
• MediaWiki — File caching is built-in and well-documented.
• Drupal – Also has caching built-in, and Lullabot does a better job than I would explaining it.  Also, there are modules for Memcached, and APC.
• Frameworks — There are zillions of PHP frameworks, and most of the good ones have caching baked right in.  If you’re using a framework, you’ll want to refer to your documentation.

The End

Well, there’s your two-cent tour.  If you’re interested in learning more about speeding up websites, I recommend this book as a good starting place.

So, yesterday, I spent a few hours trying to create a robust command-line interface for one of my CodeIgniter applications.  I learned a lot about PHP-CLI.  I also came to remember why it’s a bad idea to try and fit a round peg in a square hole.

The thing is, CodeIgniter is a great little web framework.  See the key word in that sentence?  Yes, you can hack some CLI functionality in, but if you want to start doing fancy stuff like adding multiple levels of interactive menus and such, then its time to rethink what you’re doing.

On the other hand, there are many reasons to create a simple CLI-interface to your web application.  The main use would be for running of maintenance tasks and automated CRON scripts.  For this kind of task, it’s very easy to create a CLI entry-point for your app.

How to Do It.

I started off by grabbing some advice from NetTuts and downloading Phil Sturgeon’s excellent CLI library.

In the same folder as the main index.php file, I created another file named entry.php to serve as my CLI entry to the application.  That file looks like:

Notice that I am accepting command-line arguments.  The above code will halt execution and exit if any unknown command-line arguments are given.  It assumes the first non-switch command line argument is the action the user wants to run.  It automatically prepends the “utils” controller to the route, thereby sandboxing CLI access to a single controller. The controller can do whatever you want. Here’s a small example wherein I present a main menu if no route was specified when the user runs the CLI interface:

Notice the main menu!  The design goal for the Controller was for the main menu index method to be interactive, but every other method to be able to run unattended if parameters are sent, otherwise to display prompts.

I also made some heavy modifications and additions to the CLI.php library, adding the ability to run any form_validation validation function against command-line inputs (w00t), adding the ability to display view files easily, and adding a few other helper method here and there.

The code is too long to display in this post, but here’s a link to the file source on Bitbucket.

Wrap-Up

It’s definitely not a good idea to attempt a full, robust, multi-level CLI interface for your CodeIgniter application, but this framework will help you setup a simple, even slightly-interactive CLI interface to make running maintenance tasks and providing basic tools easier for your CLI users.

The repository with all of the code is available on my Bitbucket page.

A subject that has intrigued me lately is this topic of asynchronous PHP processing.  The idea is you have a web application that includes a task which takes a long time, like, say processing video files or sending mass emails.  Your users should be able to click a button, get a notification that their job is waiting to be processed, and then go about their business.

I’ve run across all sorts of really cool queuing technologies, all of which have PHP libraries. So creating and managing job queues was no problem for me. My confusion was how to setup a worker script to process those queues.

There is absolutely no way to get around the fact that you will need at-least two distinct, simultaneous processes running on your server in order to make this happen.  The process that initiates the queue jobs is presumably Apache (or whatever webserver you like).  The second process runs in the background, and it just sits and waits for jobs and processes them as they come in.

Of course, the only way to have a process continually listening for jobs on a Linux server is for it to be a daemon.  And, of course, unless you are a system administrator with root privileges, setting up a reliable daemon is not really an option.  So, if you are using a shared hosting provider, you are kind of out-of-luck.

Or, are you?

I’ve been toying with one way to make it happen using CRON, MySQL, and PHP-CLI, all of which good shared hosting providers allow you to use.  The idea is this: Every minute, a cron-task spawns a PHP-CLI script.  The script is smart enough to see if prior instance of itself is still running, and if not, it processes the job queue.  The queue can be a simple MySQL database table, or something fancier like a Beanstalkd queue or some implementation of Zend_queue.

Here’s how the script would run:

And, below is really rough example of how I might begin to implement this in PHP, with logging thrown in. I’m sure there are ways to tweak this, or there may already be libraries out there that do the same thing better; anybody care to chime in?

#!/usr/bin/php -q
<?php
 
/*
 * CRON Command-Line Processor for job queues...
 *
 * Requirements:
 *  1. *nix-based system
 *  2. Cron
 *  3. Shell access
 *  4. MySQL
 */
// Implement by setting permissions on this script to exeuctable, and adding
// by adding the following to your crontab: */ 
// */1 * * * * /path/to/this/script.php >/dev/null 2 >& 1
 
 
define('CRON_PROCESS_LOGFILE', '/path/to/logfile.log');
define('CRON_PROCESS_LOCK_FILE', '/path/to/lockfile.lock');
 
//------------------------------------------------------
 
class Cron_process
{
	public static function run()
	{
		//Log that we're getting started.
		Cron_process::log('Attempting to start cron_process of job queue...');
 
		//Check to see if a prior instance of the process is already running..
		if ($my_special_database_connector_class->query("SELECT `status` FROM `cron_process_status`;")->row() == 'in-process'
				OR file_exists(CRON_PROCESS_LOCK_FILE))
		{
			Cron_process::log('Aborted processing.. Prior job already running');
			return FALSE;
		}
 
 
		//Create a lockfile and indicate in the database that the process is started..
		$my_special_database_connector_class->query("UPDATE `cron_process_status` SET `status` = 'in-progress';");
 
		if ( ! file_exists(CRON_PROCESS_LOCK_FILE))
			touch(CRON_PROCESS_LOCK_FILE);
		$fp = fopen(CRON_PROCESS_LOCK_FILE);
		flock($fp, LOCK_EX);
		fputs($fp, 'cron_process_began_' . time());
		fflush($fp);
 
		//Process the jobs using whatever queue technology you want.
		while($my_special_queue_adapter_class->get_number_of_pending_jobs() > 0)
		{
			// *****************
			// HERE is where the magic happens!!
			//  All the code for processing the job goes
			//  right in here..
			// *****************
		}
 
		//Clear the lockfile and mark the job complete in MySQL
		$my_special_database_connector_class->query("UPDATE `cron_process_status` SET `status` = 'idle';");
 
		flock($fp, LOCK_UN);
		fclose($fp);
		unlink(CRON_PROCESS_LOCK_FILE);
 
		//Log that we're done
		Cron_process::log('Succesfully ran the cron_process. Exiting...');
 
		//All done!
		return TRUE;
	}
 
	//------------------------------------------------------
 
	public static function init_logfile()
	{
		if ( ! is_writable(dirname(CRON_PROCESS_LOGFILE)))
			return "Cannot write cron process logfile.  Directory " . dirname(CRON_PROCESS_LOGFILE) . " is not writable.  Check permissions";
 
		if ( ! touch(CRON_PROCESS_LOGFILE))
			return "Cannot write to cron process logfile.  Check permissions.";
 
		return TRUE;
	}
 
	//------------------------------------------------------
 
	public static function log($msg, $level = 'info')
	{
		$str = date('Y-M-d H:m:s') . " - $level - $msg\n";
 
		return file_put_contents(CRON_PROCESS_LOGFILE, $str, FILE_APPEND, LOCK_EX);
	}
}
 
//------------------------------------------------------
// Processing starts here..
 
//Initial Checks
if (php_sapi_name() != 'cli' OR ! empty($_SERVER['REMOTE_ADDR']))
	exit('This script can be run only from the command line!');
 
//Check to ensure we can write to a logfile.
$init_result = Cron_process::init_logfile();
if ($init_result !== TRUE)
	exit($init_result);
 
//Include any boostrap files
require('/path/to/any/bootstapfiles/my_special_db_class_and_others.php');
 
Cron_process::run();
exit(0);
 
 
 
/* EOF: cron_async.php */

As a Christmas Holiday present to those of you that are using my CodeIgniter tools, CI-UserTracking and GeSHi for CI, I did something very philanthropic: I updated them and tested them on the latest version of CodeIgniter.

Oh, and I also fixed the links…

..and I put them in their very own Google Code pages, so you can peruse the source code, download from Google servers, and leave comments and tickets for yours truly.

AND.. as your Hanukkah/New Years/Participation gift, I also have added a brand new CodeIgniter project that I’m working on called CI Headstart with all kinds of helpers, libraries, and other goodies to help speed up development even more.  Roll on over to the Code page to check it all out.

Now that Christmas break is upon us, and I since I work for a University that gives employees like a bazillion days off each December, I hope to clean these up even more and provide some quality documentation.

Happy Holidays from me to you,

PS >> If anybody is interested in contributing code to these projects, let me know.

Like most development n00bs, after I started using version control, I never looked back.  And neither should you.

It required me to change the whole way that my office operated, though.  See, the way that we were doing things before seemed so simple; we just edited files and shouted at each other if we collided in our editing.  As it turns out, this was a bad thing, and there have been better alternatives around way longer than I’ve even been in this business.

But like most crotchety, over-egotistical developer-types it took a while for me to come around.  Here’s a brief history of my flirtations and eventual commitment to version control.

Our Blissful, Youthful Ignorance

This wasn’t really that long ago…

1..2..3... Easy Peasy Japanesey.. and stupid.

We would all work directly on the files directly on our development server.  We would sit down, SSH into the server using our favorite editor and code away, never thinking of change management, reverting back to old versions, or who would be responsible for what.  Conflict resolution seemed easy… if I was editing a file named welcome.php, I would simply shout across the room, “Hey Mike–don’t work on welcome.php right now, or I’ll have to beat you!”.

Our revision control system consisted of me creating and storing weekly backups of the entire database and file system.  If we made a change that killed the system, we’d simply either lose that week’s work or spend hours debugging it.  It was all gloriously simple.

Version Control Puberty — The Angsty Years

One day, I decided to implement Subversion, mainly because other developers were sneering at me and telling me I was a dummy.  And while I didn’t want to be a dummy, the whole thing seemed overly complicated.  Why would I want to increase complication when everything was working so simple?  I also had some fundamental issues with this new version control idea:

• First off, everybody has to have to get their own copy of the entire file set.  Bad!  Doom! Insecure! I have to trust my developers with the codebase? ::Gasp::
• Secondly, what do you mean that developers can’t see their changes on the server immediately upon commit without some hacked hook system?  This means they’ll have to run LAMP on their local boxes, too!  Geez.. now we have to have local dev environment setup procedures, too..
• Finally, SVN requires management of its own.  You know.. backing up, securing access, and generally managing.  More overhead and more complication!

Grudgingly, in order to remove the “dummy” label from my operations, I implemented Subversion.  It was difficult at first to understand how it would fit easily into our procedures, but with some very helpful free online material, we started using it.

And sure, I did have to write procedures for setting up local dev environments AND install a subversion clients AND manage a repository server, but you know what?

All of that stuff was way worth it.

All Grown-up Now

Let me repeat that: whatever frustrations version control causes, they are all worth it.

After being SVN disciples for a while now, our development procedures have matured.  Here’s how we do things:

The way we do things now.. Much better!

I’ve since tried other VCS systems like Mercurial, Git, and Bazaar, but have not found any compelling reason to switch.   Either way, using version control has saved our sorry butts on more than one occasion and has made life easier in about 1,001 ways.

As a bonus, it has also forced us to use better procedures and generate better development documentation, which is amazing, because we’re pretty lazy.  Now if only we could find a tool to better force us to behave when it comes to unit testing…

Well, that’s my story.  If I’ve inspired you to use VCS, hooray!  Here’s a helpful place to get started.  If not, you’re a dummy.

The problem, succinctly stated, is: How do you best organize 14 weeks of study to teach PHP to a group of motivated College students?

I know they must be pretty motivated, because they’re signing up for the class despite the fact that it starts at 8 am.

This Fall, I will  be teaching a course in Web Application Development at FSU.  The topic will be server-side scripting, and the focus will be PHP.  Since I’ve taught this course before, developing the curriculum won’t take months, but I am nevertheless spending a fair amount of time updating and tweaking for the next go-around.

A quick Google Search for “Teaching PHP” brings up only a few relevant links, mostly message board discussions.  “Server Side Scripting Curriculum” doesn’t return much either.  Likewise, WaSP have not yet published their recommended server-side scripting course recommendations.

So, I’ve had to come up with a lot of the course unilaterally.  The learning objectives are as follows:

By the end of the course, students will understand:

• Basic programming skills
• Web application development principles
• How to find and use PHP resources on the Internet
• How to manage tasks, bugs, and revision control mechanisms for web projects

By the completion of this course, students will be able to:

• Program and deploy simple scripts in PHP
• Process web-based input and output in PHP
• Build multi-file PHP applications
• Connect PHP applications to a database
• Design a simple dynamic website using PHP, MySQL, HTML, and CSS

After a few iterations of course development, here are the topics I have planned to discuss, in order, thus far:

• The current “State of the Internet”
• How the technology works – Web servers and clients
• Eclipse setup and good  practices for personal workflow
• PHP basics – Syntax, variables, arrays, functions, iterators, etc.
• Form processing (GET/POST)
• Database integration
• Multi-file application organization
• Classes and objects
• MVC frameworks
• Revision control and associated workflow
• Basic management: Ticket and bug tracking
• Web Services – SOAP and RPC
• XML integration
• Comprehensive application organization

That’s a lot of information.  Fortunately the students will have object-oriented experience AND database experience.  So, we should be able to leap off the cliff quickly and into the world of iterators, encapsulation, and inheritance.

I’ll post the week-by-week calendar when I finalize it, which necessity dictates will be very soon.  Feel free to grab it and use it for your own courses, or tell me what I can improve on.

UPDATE: The course calendar and other details are live online at http://lis4368.cci.fsu.edu

In my last post, I discussed do’s and don’ts for making a PHP application portable. This week, I will show you how to create a preflight checker in the CodeIgniter PHP framework to ensure that an environment will support your application.

Note: This article assumes that you already have a working CodeIgniter application setup.  If you are interested in getting started with CodeIgniter, there are some really great tutorials on the web.  If you’re not using CodeIgniter, skip to the “What to Check” section below for a general idea of how to apply this to PHP apps in general.

Setting up the Hook

The best way to setup a preflight checker is to create a hook.  Make sure that you enable hooks in your main configuration file before getting started.  We’ll be setting up a pre-system hook, so add the following code to your application/config/hooks.php file:

/*Preflight Check Hook*/
$hook['pre_system'] = array('class' => '',
'function' => 'preflight_check',
'filename' => 'preflight_check_hook.php',
'filepath' => 'hooks');

This will tell CodeIgniter to run this hook every time the system starts.  As you can infer from the above code, we’ll now have to create a file in the application/hooks/ folder (if it doesn’t exist, create it) named preflight_check_hook.php and add a function to that file named preflight_check():

/**
 * Preflight Check checks all of the prerequistes before the first
 * pageview for each session.
 *
 * If a problem is found, the program halts execution.
 */
function preflight_check()
{
  //all your checks go here
}

Now we’re ready to add checks so we can test the server environment.

What to Check

Technically, you can check whatever you want here, but I tend to check the things that are likely to be different from one server environment to the next.  Some of the more important ones are:

• Whether the version of PHP or CodeIgniter is new enough to support your application.  You can check this by using the phpversion() function
• Necessary PHP Extensions installed?  You can check this by using the function_exists() function.
• PHP.INI variables set correctly?  You can check this by using the ini_get() function.
• Whether certain folders are really writable on the server or not
• Whether files exist or not.

Of course, you can check for most anything you want to in the preflight check, and even try to tweak the environment a little using ini_set().  What you can’t do is access most of the functionality in CodeIgniter, since this hook will run before most of your libraries are loaded.  There are a few useful CodeIgniter variables and functions that you will have access to, though:

• show_error() — For printing out errors (non CodeIgniter users should use the die() function)
• is_really_writable() — For testing if a file is writable or not (non CodeIgniter users should use the is_readable() function)
• $application_folder and $system_folder

Rather than bore you with lengthy explanations of each type of check, it will be easier to simply show you an example of how I typically do it.  Below is an example preflight check hook that I ripped almost verbatim from one of my applications:

function preflight_check()
{
	global $application_folder;
	global $system_folder;
 
	//Ensure proper version of PHP
	if (phpversion() < '5.1')
	  show_error("This application requires at least PHP 5.1 to run properly!");
 
	//Ensure SQLITE extension is installed
	if ( ! function_exists('mysql_connect'))
	  show_error("The sqlite PHP extension is required to run this application!  Refer to <a href="http://us.php.net/manual/en/book.sqlite.php">the PHP documentation for this extension</a> for more information.");
 
	//Ensure GD2 is is installed
	if ( ! function_exists("gd_info"))
		show_error("The PHP GD2 image library is required to run this software.  Check with your server administrator or hosting provider, or <a title="Installation Instructions for GD2&gt;refer to the PHP documentation for installation instructions&lt;/a&gt;.&quot;); 	//Check if the system cache directory is writable 	if ( ! is_really_writable($system_folder . " href="http://us2.php.net/manual/en/intro.image.php"></a><a title="JSON extension installation instructions" href="http://us3.php.net/manual/en/book.json.php">manually install it</a>.)");
 
	//Check memory limit and attempt to set it to what this application needs
	if (get_bytes(ini_get('php_value memory_limit')) &lt; 33554432)
	{
		if( ! ini_set('php_value_memory_limit', '32m')
			show_error("The memory limit in your PHP.INI file must be set to at least 32 megabytes (32m).");
	}
}

You can copy this code into your application/hooks/preflight_check_hook.php and try it out.  Basically, it will halt execution (via the show_error() function) and show an error on the screen that alerts the user to something not being setup correctly if any one of these checks fails.

What’s the Advantage over just letting the program fail on its own?

Technically, nothing; your preflight checker will check things that would normally cause your application to fail at some point in the execution anyway.  This is simply a way for you to alert your admins/developers/users that they need to fix their environment right off the bat.  Plus it’s more graceful and clean than PHP error messages.

Practically, however, this may save a lot of headaches, especially if you distribute the application or expect people to download a copy onto their own desktops for development.  Oh, and if your users/developers/admins have PHP error reporting turned off on their system, then a carefully coded preflight checker will save them from getting a mysterious blank screen when the environment doesn’t match the requirements.

Keeping this thing from running for every page view

You probably won’t want this script to run every time a  page is loaded on your site, especially if the script includes file operations, lest your server take a performance hit.  Typically, you will want to run this preflight checker only once per session.  By adding a few lines of code to the top and bottom of this function, you can make it run only once per session (unless it fails).

function preflight_check()
{
	//See if this has already been run during the current session
	session_start();
	if (isset($_SESSION['preflight_check_pass']) && $_SESSION['preflight_check_pass'] == 'pass')
		return TRUE;
 
	global $application_folder;
	global $system_folder;
 
	//Ensure proper version of PHP
	if (phpversion() < '5.1')
	  show_error("This application requires at least PHP 5.1 to run properly!");
 
	// All of the
	// rest of your checks
	// go in here...
 
	// ...
 
	//Woo hoo.. the check passed!
	$_SESSION['preflight_check_pass'] = 'pass';
}

You’ll notice that this example uses PHP’s built-in session system rather than CodeIgniter’s session library.  This is because CodeIgniter’s will not have been loaded yet when this hook runs, and because we’re not storing any particularly sensitive information in this session, so we don’t have to take advantage of CI’s advanced session security features.

Well, that’s about it for now.  If you have any comments or see any issues with the examples in today’s post, feel free to share by leaving a comment.

“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