A Dramatic Week Here at Perishable Press..

..And we’re back. After an insane week spent shopping for a new host, dealing with some Bad Behavior, and transferring Perishable Press to its new home on a virtual private server (VPS), everything is slowly falling back into place. Along the way, there have been some interesting challenges and many lessons learned. Here are a few of the highlights..

The tide may be turning for A Small Orange

I am certainly not alone when I say that shopping for a new hosting provider and transferring websites is one of my least favorite aspects of web development. In my experience, switching hosts requires waay too much time and rarely unfolds without significant problems. Nonetheless, when service and/or support turns sour, upgrading to a better host is well worth the effort. In my case, A Small Orange just wasn’t working out.

Everything was going fine for the first several months — excellent service, fantastic support, and consistent, reliable server uptime. However, during the last several months, server uptime frequently dipped below the 98% level, an unacceptable amount of downtime, especially since it generally happened during critical times: peak hours or while I was trying to work on the site. When I finally submitted a support ticket addressing the “unacceptable levels of downtime,” ASO support staff put my mind at ease by moving my site to a “a more stable server.”

This would have been the ideal solution, however, the new ASO server was just as instable as the first. Even worse, the new server was slower, did not support file compression (neither mod_gzip nor mod_deflate), and eventually had “persistent connections” to MySQL (a potential performance enhancement) disabled. Overall, although ASO service remains superb, their servers are slow, inconsistent, and poorly configured (in my humble experience) and just can’t seem to keep up with the growing client load. And, to top it off, my monthly bandwidth was approaching its limit, not to mention that I was quickly running out of disk space. Needless to say, I finally decided to find a better hosting solution.

First stop: Media Temple

After deciding to switch hosts, it was time to go shopping. Given my specific hosting needs (e.g., root access, full control, plenty space/bandwidth, stability, performance), I found myself looking at various virtual private hosting solutions. After researching and pricing several popular hosting companies, I set my sights on the uber-sheik Media Temple. Their dedicated virtual (dv) plans were priced at around $50/month and provided all of the features for which I was looking. Plus, we all know how ridiculously “cool” MT seems to be — and I definitely didn’t mind that ;) Throw in a 30-day money-back guarantee, and I was all in..

After plopping down the digits, I waited for the confirmation email so I could get started. After waiting almost 24 hours, still no email. After calling customer support, they snapped that they had sent the email within “10 minutes” of payment, however, for some reason it never arrived. Using an alternate email address, I eventually received the login information and jumped into the mix.

The dedicated virtual servers at Media Temple deploy the Plesk user-interface, which I found far too convoluted for my tastes. Everything was buried within subsection after subsection, arbitrarily organized via inconveniently associated preference panels and configuration options. Nonetheless, I was willing to put in the extra time to learn the new software, and eventually learned enough to take my new dv server for a test drive.

Unfortunately, I was not impressed. After setting up a temporary copy of my test site, I was disappointed to experience speeds slower than those provided by my shared server at A Small Orange. Then, after trying to tweak Apache to improve performance, I kept getting error messages. For example, I could not get mod_expires or mod_deflate to work at all. Further, the dv servers are running PHP 4 and MySQL 4. Unfortunately, documentation is sparse, support is scarce, and the handful of available upgrade workarounds are dreadfully laborious. To make a long story short, after spending countless hours beating my head against the wall trying to hammer server configuration into acceptable shape, I finally gave up and decided to pursue alternate hosting options.

Final stop: WiredTree

After closing my Media Temple account, I continued my search. Fortunately, I remember reading a trusted review about managed virtual private servers at WiredTree. After checking out their website, doing a little research, and a engaiging in a friendly, informative pre-sales chat, I was sold. WiredTree provides everything I was looking for, plus a whole lot more:

• Intel Dual Xeon Clovertown (8 CPUS)
• 256MB Guaranteed RAM
• 1024MB Burstable RAM
• 300GB Bandwidth
• 30GB RAID-10 Disk Space
• Fully Managed!
• ServerShield Server Hardening
• 24/7/365 Phone and Help Desk Support
• Proactive Updates and Monitoring
• 4 IP Addresses
• Virtuozzo Power Panel
• Nightly Backups

Plus, they run the server and administrative software with which I am already very familiar: WHM, cPanel, and even Fantastico. In my opinion, this deal trumps that offered by Media Temple, and for the same price. Throw in current versions of PHP (5) and MySQL (5), mod_gzip, and the ability to run PHP 4 via CGI, and I was sold.

Since signing up with WiredTree, I have been completely satisfied. The server is extremely fast, highly configurable, and — so far — very stable. Along the way, the support team has been remarkably helpful, answering my questions and resolving every issue in a timely fashion. Needless to say, I am most pleased with WiredTree and look forward to working with my new server ;)

In other news: notes on DNS, PHP, server configuration and performance

Wow, what a long post this is turning out to be.. and I’m still not finished! Here are a few miscellaneous notes related to the entire host-switching process.

Domain Propagation

This round of server switching has reinforced several useful pearls of wisdom related to switching servers and DNS propagation:

• Backup everything (files and databases) three times
• Compare software versions of both old and new servers
• Create an exact duplicate for each of your transferred sites
• Change the nameservers for a minor site to check ISP cache time
• Plan for 24-48 hours for your domains to propagate
• Don’t be surprised if your ISP reverts to your old IP after propagation
• Use free proxy servers to check on propagation status
• Use a free DNS lookup service to check official DNS status

Using your own nameservers

One of the benefits of a virtual private server is that you may create and use your own nameservers. After creating your nameservers, simply register them at your domain registrar and then point your domains at them. For example, if you have site1.com, site2.com, and site3.com, and plan on using your own nameservers at ns1.site1.com and ns2.site1.com, you only need to register your nameservers with one of the three domains in order for them to work for all three domains. Thus, after you register your own nameservers for your site1.com domain, simply point each domain at your own nameservers. In other words, you don’t have to register/create your custom nameservers for each and every domain, — you only need to create them for the original domain. Many thanks to Mark at Register 4 Less for taking the time answer my questions and share his useful resources ;)

WordPress, PHP, and plugin mayhem

After uploading Perishable Press to the new server, I got nothing but the white screen of death. I could not even login to the WP Admin to disable plugins. So, I immediately executed the following (nearly routine) WordPress-white-screen-of-death troubleshooting strategy:

• Check and double-check file transfer fidelity (i.e., exact copy)
• Check and double-check database username and password
• Ensure that your new server is equipped with the required software (PHP, MySQL, et al)
• Check the htaccess file and try removing suspect/all directives
• Check all error logs for clues (Apache, PHP, et al)
• Check and double-check username and password in wp-config
• Delete the WordPress cache and/or any other cache-related assets
• Sequentially disable and/or delete all plugins, scripts, et al
• If still nothing, install a new WordPress and verify that it works
• One by one, begin replacing your site’s database tables with those from the new installation
• If it is a database conflict, the white screen will vanish when you have replaced the offending table
• Scour the offending table for the source of the conflict or, if possible, just use the new one

Hopefully, at some point during the preceding routine, some progress will have been made and the white screen of death will have evolved into something more useful — anything is more useful than nothing ;) In my situation, during this most recent server migration, I managed to transcend the blank screen after cleaning up a problematic wp_options table. Apparently, while experimenting with a plugin by Dagon Design called “Latest from Each Category”, the plugin somehow managed to create over 10,000 (read: ten-thousand — waay too many) empty entries in the WordPress wp_options table.

Well, apparently, the new server didn’t appreciate that too well, and refused to serve anything at all. After deleting the 10,000 blank entries, I finally got WordPress running on the new server.

Dialing in teh PHP

With WordPress running, it was time to restore the plugins that I had removed during the troubleshooting process. Some worked great, but others, no go. After a gruesome round of plugin enabling and disabling, I discovered that nearly half of my plugins were triggering their own blank white screens.

It took a few minutes before it occurred to me that my new server was running PHP 5, while my old server was running PHP 4. And, as many of you probably know, there is a big difference between the two versions. A little research revealed that, in fact, many of the plugins that I happened to be using required PHP 4 in order to work. The solution? WiredTree to the rescue! Their virtual private servers are well equipped to run both versions of PHP on the same account.

Thus, with the generous help of the support team, I configured Apache to run PHP 5 by default, and then setup PHP 4 to run via CGI on a per-site basis. Now, I enjoy the luxury of PHP 5, while retaining the ability to run PHP 4 on any domain or in any subdirectory by adding the following directives to the associated httpd.conf or htaccess file:

# enable php4 via cgi
Action application/x-httpd-php4 /cgi-sys/php4
AddType application/x-httpd-php4 .php

With that in place, my plugin nightmare was over, and I was able finally to restore Perishable Press to its original, fully functional state. A huge shout-out to Adam at WiredTree for his outstanding help with this ;)

Wrap up..

Having said all of that (probably too much, I know), I am back in business with a fully functional website empire running smoothly at its new home on a fully managed, virtual private server. Although there are many things that I simply don’t have time to share with you all, rest assured that I am busy soaking in new material and knowledge that will hopefully manifest itself through future articles and comments. In the meantime, there is still plenty of work for me to dig through, as well as many goals that I am still determined to realize. So I press on, embracing the mind-melting pace of change unfolding deep within these digital realms. As much as I would like to stay on top of every detail and enjoy a comfortable routine, I am just having waay too much fun letting go — going with the flow and surfing the wave..

About the Author

Jeff Starr = Designer. Developer. Producer. Writer. Editor. Etc.