Recently, I had a prospect drop by to get an assessment. The prospect, let’s call her CC, had recently engaged a freelance web developer to build her company’s website. She showed me her website and it looked serviceable aside from some layout distortions on the various responsive viewports. CC revealed that she had hope to engage us to assist her with updating the content of her website.
It seemed like a perfectly reasonable request, but a quick check revealed that CC’s developer had built the site atop Wordpress. A well implemented Wordpress solution should be a joy to use. So, the question was just how did CC’s developer use Wordpress and if it was well implemented. An acid test is to see if the developer had relocated the default admin page to a different URL (He hadn’t). I asked CC to log into her site but she looked at me with wide eyes.
“I don’t know what’s the login!”
I pressed her for answers. She told her her developer never gave her any login details because it was difficult to. Initially, I thought the developer was just trying to force CC onto a retainer plan by making her go to him every time she needed to update her site content. However, after she managed to retrieve the details from developer, I logged into her site and…
Oh. My. God.
The clean, friendly Wordpress interface had mutated into an ugly, unwieldy monster. The menu was shredded and scored with countless options and custom tabs. Battle wounds left behind by the incessant installations of plugins and “code-free layout editors.” As I navigated from tab to tab, trying to make sense of the war zone I had wandered into, Wordpress gasped and shuddered as it loaded the offending layout editors. The glacial speed and epilepsy-inducing loading pattern of the millions of dialog boxes reminded me of that painful scene where Tucker drops his keys in Something About Mary.
“Can fix, right?” (Uh…)
“It will take some time, but it should be possible.” (Liar, liar pants on fire!)
“Oh great!” (Oh, shit)
CC left, blissfully unaware of my horror.
CC’s Wordpress abomination is a classic example of developers butcher Wordpress. While the user facing website usually appears somewhat serviceable, the CMS is freak show of patches and slapped on fixes, making the Wordpress CMS a complete nightmare to use for the client and the poor soul who had to take over the site’s maintenance. Arguably, if client needs that many plugins then the developer has no choice but to install them. Here, we assume the developer actually KNOWS what he’s doing.
But, it gets worse.
The advent of code free layout editors brought on a wave of pseudo developers; usually a designer with little to no knowledge of coding ethics and principles. The pseudo developers rely heavily on these layout editors to undercut trained developers. As the project advances, the pseudo developer ends up installing more and more options, until the entire CMS spins out of control. Certainly there are true unicorns out there, but these, as the name suggests, are far and few in between.
Clients that are budget conscious are likely to work with these pseudo developers as they are attracted by the low price point and seemingly professional solutions. If the client is lucky, he ends up with a site like CC’s: a semi-functioning website but a nightmare for a CMS. If the client is down on luck then he would have sunk in money but received no website. His “developer” quits on him because he is “too demanding.” The client eventually resigns to his tragic fate, with his belief that tech is difficult and scary, reinforced. And he still has no website to show.
We’ve seen more than our fair share of these heart wrenching cases and these stories are some of the inspiration behind our efforts to create Horlu, an intelligent web design assistant that turns your Facebook Page into a modern, responsive website. Learn more about the story behind Horlu here.
Have you encountered a Wordpress Butcher? How did you survive the onslaught? Share with me your survival tales!