Developer caveat

Last year, a friend of mine hired a new office worker whose brother is a WordPress developer. Between the two of them, the brothers convinced my buddy to convert his massive site from Movable Type to WordPress. Part of the pitch was that the developer brother was going to update the look of the site to something more modern and eye-catching. Here’s what happened.

First, they extracted a contract from my friend for a lot more money than he wanted to spend, but he was getting a whole new site with a whole new look, right? Even so, I cautioned my friend that there was no way the developer was going to be able to convert the entire site — which contained hundreds of static pages in addition to 20,000+ pages under the control of Movable Type — for that amount: There was simply too much work involved.

Second, the developer promised that even though most WordPress sites do load any given page more slowly than Movable Type, he was going to optimize the site so that the load times would be comparable.

Then the work began. It was supposed to be finished in three weeks (I told my buddy there was absolutely no way that was going to happen, but it doesn’t help to be correct in cases such as this), and it wound up taking close to nine months — for the portion of the work that did get done.

During this time, the developer announced that 1,400 of the static pages were too much trouble to convert to WordPress, so he was going to discard them.

I had very little contact with the developer during these months, but one exchange we did have concerned the choice of a media player. The old Movable Type site was HTML 4, and templates for the new version of WordPress generate HTML5, so we had the opportunity to convert from nested object and embed code to HTML5 video. Once we settled on which WordPress plug-in we were going to use, I set about converting the dozens of video files from FLV to MPEG.

When the developer finally delivered the site, it was beautiful. However, it took roughly 2.5 times longer for the front page to load, the pages used XHTML 4.01, only a handful of the static pages had been converted to WordPress, there was no documentation accompanying his work, and the developer had based his design on one of the offerings from Woo Themes.

We’ll get back to the load time in a moment, and for now let’s ignore the hundreds of unconverted pages that still had the look of the old version of the site (but without the ads or any navigation), the failure to use HTML5 so that all my work converting video was an utter waste of time, and the complete lack of documentation. It turns out, the real problem is the Woo Themes foundation.

Now, it may be that Woo Themes does some excellent work in WordPress themes. Not being a Woo Themes developer, I can’t speak to that. The rub is that my friend’s developer has no interest in maintaining the site, and if he did, he would charge a small fortune to do so. However, he is my friend’s only point of contact with Woo Themes. So when WordPress issues an update — as it recently did from version 3.3 to 3.4 — and something breaks in the Woo Theme he’s using, he’s out of luck. With no access to updates from Woo Themes or, for that matter, to the Woo Themes developer fora, he’s locked into going back to the developer for help. As you might imagine, his relationship with this developer is barely cordial at this point due to the chafing occasioned by the late delivery of the defective site. He is essentially locked in to a contentious relationship with the developer over the health of a website that has become the driving force for his business.

As for optimizing the site, this seems to have amounted to little more than called the Google AJAX library to load jQuery and jQuery UI, rather than using the versions that ship with WordPress. Not only did the developer fail to install any type of caching plug-in, he managed in the PHP code for the front page to make duplicate calls to load the HTML, adding two seconds to the load time right off the bat.

Along with the switch in CMS engines came a switch in hosting companies. Because the site is so inefficient, my friend has had to upgrade from a $20-a-month plan to a $50-a-month plan to a $100-a-month plan to gain enough server capabilities to overcome the software deficiencies, and it’s entirely possible he’ll have to upgrade yet again.

In some ways, this is just a variation on an old story, so the moral hasn’t changed: Know what you’re buying when you hire a developer, get documentation, and make certain that you get ownership of what you’re paying for — or be prepared to spend a lot more money in the future.