I’ve had great personal experience with 1&1; maybe I can write more about them another day. But I was helping a client migrate from an unreliable host, so I was very concerned about customer support as well as reliability. I’ve read horrific reports of 1&1 customers trying to get help over the phone from someone in India, which is nowhere close to the actual data centers. In spite of my good experience with 1&1, critical reviews made me nervous.

So I started searching for Canadian hosts, and HostPapa seemed to come highly recommended. They’re a relatively new host but seem to have a very loyal and satisfied client base. Having run a successful business in the UK, they decided to open up a base in Ontario. Among other encouraging offerings, they promise 99.9% uptime, a state-of-the-art data center, and that they purchase “green energy” credits according to their energy consumption. Their technical support is also located in Ontario, which reassured me.

I was sold. I signed up for three years of service.

On day one I started transferring my client’s Web site to the new Web space. Before all of it was transferred, I got an error about exceeding available disk space. I phoned customer support and quickly discovered that, truly, the server was out of disk space. Apparently another user had decided to take them up on their offer of unlimited disk space and filled up the whole server. So I had to wait for a day for them to sort that out.

The next day I was able to get the Web site up.

I was designing a Web app for this client that would not be hosted at HostPapa, so I needed access to the DNS records to set up a subdomain for the external app. I soon realized that the admin interface used by HostPapa would not give me this degree of control, so I contacted support to see if they could add a DNS record for me.  I gave them the address of my other host and they said that they could.

At least four days later, the subdomain was still not working. I asked support about it, and they said they were still working on it. Later I received an email saying that my ticket had been resolved, only to see that support had created a subdomain for a folder in the public_html directory of my HostPapa account. Definitely not what I had asked for.

(As an aside, 1&1 allows you do this easily using their admin interface; the new subdomain and DNS entries are sometimes functional within minutes.)

So I decided to transfer the domain away from HostPapa to a DNS server that I could control. During this wait, I had created all of the employees email accounts by uploading a CSV file with email addresses and passwords. I then I transferred all the mail from the old host to the new accounts using imapsync.

Web site and email were transferred, up, and working better for my client than they had in months. For a day or so. Suddenly email was down because of some certificate inconsistency on HostPapa’s end. This problem persisted for most of a day, and I was becoming more and more nervous that this was a taste of the 99.9% uptime that I had signed my client up for.

To their credit, HostPapa’s technical support was always very easy to contact and transparent in addressing problems. After the first two weeks of madness, my client settled into a very reliable experience with the host…

… until last week, when there was some massive hardware failure on HostPapa servers. Mail was recovered, as well as Web files, but the MySQL database that stored not only the content of my client’s Web site but also all of the HTML and CSS templates was lost, leaving the home page a white screen with a database error message.

I’m trying to give an objective account of my experience with HostPapa. No host is perfect. Obviously I’ve had months of seamless service. However, migration and initial setup was brutal, and within one year of service, I’ve lost my database. There are tons of complaints online about big hosts like 1&1. I can say two things:

1. I’ve been with 1&1 for at least five times as long as HostPapa and have never lost any data due to their fault.
2. I’d rather have service that just works than great customer support to help me handle all the problems.

The trouble of course is that as you’re developing a new feature, you make changes or additions to the existing code of your application. But let’s say you can’t always write perfect code, and can’t predict the effects of your new code. If something breaks, any of the people using your system will see the wreck, all of a sudden. For the users, it would be like trying to drive a car while a service technician is working on the transmission: very difficult, and very annoying.

So, don’t do work on the live (production) site—only update it when you’re 99% certain that your updates are working properly.  A few technicalities arise:

1. If you can’t work in the Production environment, where do you work?  And how can your working environment (Development) be as similar as possible to Production?
2. How do you move code (and data, and other components) between Development and Production? How do you make sure that you’re working off of current Production data? How do you deploy an update to Production smoothly (without taking forever, without missing a file/update)?
3. How do you design your application so that it can be shoved around (from Production to Staging, to Development) without breaking paths, database connections.

The good news is that, with a little work and foresight, all these considerations can be easily managed.

Development and Staging

Your development tiers will depend on the size and complexity if your project.  For instance, if there is only one developer, you can get away with a single development environment where you do your work before updating.

As soon as there are multiple developers working on the same project, it becomes desirable for each person or team to have a “sandbox,” where one can mess around while building new functionality.  And once there are multiple components being built at a time, it becomes necessary to have another type of workspace (typically called a Staging environment) where all of the separate components can be tested together, before they are released to Production.

So how do you make a development environment?

Creating the Development Environment

Some people have the luxury of working with Virtual Servers, where it’s trivial to “clone” the Production server, giving you an exact copy to fool around with. In this case, there are fewer considerations in obtaining a development environment.

If you aren’t working with virtual servers, you might have to manually make a copy of Production.  In this case, it’s easier to ensure congruence between Development and Production if Development can run on the same server as Production.  This is likely not feasible for large projects, since Production will need all available resources to serve clients.

Transferring Code and Data

In any case, working without a virtual server requires some manual copying, so the key is automate.

Write a script that copies the production databases to a new test version.  With MySQL (if you have the right permissions), you can just copy the database folder in /var/lib/mysql (or wherever your database files are kept).

In my case, I check out code from a version control repository to start a fresh development environment, but the repository doesn’t track every single thing that the application needs to run. For all those extra things, add them to some kind of shell script so that you can get set up right away.

Speaking of version control, I’ve found this to be a huge help in managing code between Development and Production. I’m not sure if this is an accepted best practice, but it’s working for me. Using git, I keep Production managed under its own repository. When I want to start a fresh development server, I check out (clone) the Production code. As I work, I commit any changes to my development repository. Then, when I’m ready to release the new features to Production, I use git’s pull command to fetch updates from Development and apply them to Production. The big advantage I find here is that I don’t have to keep track of what I’ve changed; as long as I commit the changes, git knows what to update.

Note that even if you were sure that your code worked, you wouldn’t want to use pull to update Production unless you were certain that there wouldn’t be any conflicts when merging the new code with the old code. This isn’t usually a problem with a small number of developers, but with multiple branches of code, conflicts may arise that need to be manually sorted out.

Obviously proper testing standards fit into the updating process, but that’s another topic for another time.

Application Design

To make development server setup as quick as possible (and many other maintenance tasks), any global, server-specific variables or configuration should be specified in a separate configuration file: database connection information, server path, base URL for the Web site, debug settings. I keep these settings in a file that isn’t even tracked by version control. That way (if I’m really smart), I can write a script that will copy all the production code, data, etc., and create the configuration file with all the appropriate test database connection info and all the paths to wherever my development server is installed.

With all server-specific settings isolated, it’s easy to copy your code between servers, because you know it will be grabbing the right path and connection information from the respective configuration file.

With good design and a little work, starting a fresh, up-to-date development environment will be a command away at the shell prompt. Wow! Almost makes you want to write that next login screen!

The new Web site allows products and prices to be managed from a store back end, where products can be immediately added or removed, and special offers or product features can be applied. Customers can complete their transactions online at their convenience.

This site features a clean graphic design, and was built using the Django Python Web framework, using Satchmo for the store shell.

Visit site »

The new Web site and catalogue make it easy for customers to view the selection of urns and keepsakes while giving the business a confident online presence that matches their established identity.

I also provided the product photography service for this project.

Visit site »

You likely noticed that the title uses the term Snippets as opposed to Plugins. These could be put into plugin form, but they can also be added to a WordPress theme’s functions.php file. I’m not sure of the version compatibility of the code; it’s been tested with WordPress 2.7.

Post Thumbnail

This is a minimal-overhead thumbnail solution. It makes use of WordPress’s default thumbnail behaviour. I like this approach because it’s relatively foolproof if I’m asking non-technical clients to upload photos—they don’t have to know anything about the thumbnails, they just need to dump in the source file.

If you look under Settings > Media in the WordPress admin, you’ll see three image sizes that you can configure. When you add an image to the media library of a post, WordPress will upload the original and save three smaller versions (provided that the image you uploaded was bigger than these in the first place). So in the end you’ll have four image sizes: full (original), large, medium, and thumbnail.

If you plan your design carefully, this should be enough sizes to make you’re life pretty easy. For instance, I designed a site where various products were stored as posts. For each post, I added a product photo to the media library. I had 150 x 150 thumbnails in the catalogue, 200 x 133 thumbnails on the home page, and a 300 x 200 size on the single product page. The user could then click to view the full size.

I made all of this happen by adding the following code to the theme’s functions.php:

function get_image_url($parent_id, $size='thumbnail', $return=false) {
    $images =& get_children('post_parent=' . $parent_id .'&post_type=attachment&post_mime_type=image');
    if (is_array($images)) {
        foreach ($images as $attachment_id => $attachment) {
            $result = wp_get_attachment_image_src($attachment_id, $size);
            $result = $result[0];
            if ($return)
                return $result;
            else {
                echo $result;
                return;
            }
        }
    }
    else
        if ($return)
            return false;
}

Then, when I want the URL to the medium thumbnail for a post, I just use this in my template:

get_image_url($post->ID, 'medium');

Essentially, this will grab the first image in the media library of the given post.  Like I said, the size options are 'full', 'large', 'medium', and 'thumbnail'. The function echoes the URL by default.  If you want to store the URL for use later, set the $return parameter to true.

Category Thumbnail

In the same vein, I’ve needed a category thumbnail on a couple of occasions, when most of my posts are prominently associated with images.

Please note that the following snippet makes use of a modified version of Mike Stickel’s Random posts from random terms plugin. I just modified it for easier access to his useful utility functions.

The function grabs a random post from a specific category and gets its thumbnail (using the previous function):

function get_category_image_url($category_id, $size='thumbnail', $return=false) {
    $random_post = ms_random_post($category_id, 1, false);
    if (sizeof($random_post) > 0) {
        if ($return)
            return get_image_url($random_post[0]['id'], $size, true);
        else
            get_image_url($random_post[0]['id'], $size, false);
    }
    else
        if ($return)
            return false;
}

Now I can quickly get a relevant thumbnail for a category:

get_category_image_url($category_id);

As you can see from the function definitions, size defaults to thumbnail.

If these snippets don’t do exactly what you need them to do, they are hopefully simple enough that you can adapt them to your requirements.