WordPress powers around 29% of the internet as of this writing. It’s a pretty big deal. If you had a sudden urge to visit them all in one sitting, you’d be browsing non-stop for a little over twelve years. Hope you have a very comfy chair…
Chances are WordPress is behind some part of your web presence – or all of it. And if you’re thinking about a web project right now, I’ll bet that comfy chair one of the solutions proposed will be powered by WordPress.
So when you hire a WordPress developer, be it to build you a theme or a custom plugin, how do you know you’ve found a true expert?
I’ve been doing WordPress development for many years, and I’ve seen all sorts of setups. And all kinds hacks – from the mild, almost cute ones, to the horrible, “we’ll need an exorcist to fix this” ones.
Because WordPress is so popular, everyone wants in. It’s easy to dub yourself a WordPress developer. However it’s not enough to know ho to code, not even how to code in PHP. (the programming language used for most things WordPress) To be an expert, one needs to know the platform, and how to best work with it.
Here, then, are 5 questions to ask your current or future WordPress developer to separate the sweet from the chief.
1. Do you ever modify third-party code?
Wrong answer: “Don’t you?”
Right answer: “I’m making an effort not to be insulted.” (or something along those lines…)
WordPress has a rich eco-system of themes and plugins. The golden rule is you should try to keep plugins to a minimum, but you will use some, that’s unavoidable. As for themes, it’s likely you’ll want to move away from “Twenty-Seventeen” pretty quickly.
One of the most horrible and frustrating thing I’ve seen is people modifying code directly in the them or plugin files they download from the internet. That’ll work, and you’ll be able to “customize” your theme and plugin without a hitch.
The next time you upgrade that theme or plugin, all files will be replaced by their new version, overwriting any changes you made. That is one of the two main reasons some people fear upgrading anything in WordPress. (the second one is explained further down) And a stale WordPress installation is one with greater security holes.
Ask your theme developer to build a child theme instead of modifying the theme you downloaded. Child themes are lighter themes that load “on top” of their parent theme. It is the WordPress approved way to customize themes.
Note that there could still be some breakage when you upgrade the theme, depending on how the parent theme is designed, how well it respects backward compatibility practices, etc. However, the risk is almost nil. And – bonus! – your customizations will stick around!
There is one caveat with child themes: you can’t make a child theme of a child theme. In some weird Jurassic Park kind of birth control, a child theme is sterile and can’t spawn children. Go figure.
It means that if you have downloaded a theme that’s already a child theme and want further customizations, that might require building your theme from scratch – or picking a brand new theme.
Plugin developers have are a few options available. The first one is to use hooks. Hooks are ways WordPress and some theme or plugin developers allow other developers to access their functionality or affect their output.
If your developer uses hooks from another plugin or from your theme, make sure they code preventively by first checking the hook’s availability before using it. Otherwise if when uninstall a plugin they used a hook from, that could break your site.
Hooks can be coded into your child or custom theme, or in a separate plugin completely.
If a plugin is open source, (as most are) another way to customize them is to grab a copy of the original plugin’s source code, and modify that. You in effect install a custom version of the plugin on your site. (If your developer does that, please make sure they give credit to the original plugin author!)
Note that you are no longer using the original plugin, so you won’t get any updates down the road. Instead, your developer will need to grab a fresh copy of the original code once in a while, and upgrade your custom copy with it.
2. Do you follow WordPress’ Codex rules?
Wrong answer: “Rules are meant to be broken.”
Right answer: “Piously. ‘Tis the most holy document on the inter-webs.”
WordPress has what we call a Codex, a site full of information on best coding practices, How To’s and reference library. It documents all the calls and hooks a developer can use when coding for WordPress. Just make sure your developer knows about the Codex and follows it.
One of the worst example I’ve seen of not following the Codex is when accessing the database. I’ve seen people building raw SQL queries and that is so fragile it makes my head spin. I won’t go into the technical details of this one, but bottom line is: unless you have a very good reason to, (and I can’t think of any, really) stick to the WordPress calls to do the work. It’ll add an additional level of protection, as well as insulate you from upgrade headaches.
3. Are your code files executable in the browser?
Wrong answer: “Yeppers – code is meant to be executed, ain’t it?”
Right answer: “Just thinking about it gives me hives.”
Almost all of a WordPress plugin’s file, and even some of a theme, should never be executed outside of WordPress. That is, those files contain code, that needs to run within the WordPress shell. Calling them up in your browser directly should never run the code they contain, because the WordPress context then has not been setup.
What an expert coder will do, then, is start the code file with a small one liner that basically cancels all the code following it if it’s executed outside of WordPress:
if ( ! defined( ‘ABSPATH’ ) ) exit; // Exit if accessed directly
4. Do you separate theme and functionality?
Wrong answer: “No, no, no: one big package, with everything in it. Much easier to maintain!”
Right answer: “Absolutely: we all need our own personal space. A theme or plugin is no different.”
A theme should be mainly concerned with how things look on your site. Not how things work. There are some exceptions, and the line is a bit blurry – I admit it. But too often I see people putting a lot of functionality into the theme. The problem there is that when you decide to change your theme… All those nice bells and whistles are going out the door with the old theme. So make sure that when you will change your theme, as much as the features, functionality that your site has will stick around. They likely will need a cosmetic overhaul, to look right within the new theme. But at least you won’t have to extract them from the old theme or, worst, rebuild them from scratch.
5. Do you have a staging area?
Wrong answer: “I ain’t running a Broadway show, friend!”
Right answer: “Yes! And we put on the most wonderful plays!”
Ask your developer if they have a staging area, a place where they can install the new version of the code, and you can access it, test it out, see if it works as you wanted or expected. It allows you both to have a better exchange about the new features or the new look, so you can tweak to your heart’s content without disrupting your live site. Plus, it likely will allow you to find bugs that thankfully won’t make it to the live site.
You want the staging area to be as close to possible to the live site. So when you start developing, grab a fresh copy of your live database, and a fresh copy of the “wp-content” folder, and install that on the staging area. If you’re due for a WordPress upgrade, you can test it out in staging first and make sure it’s all smooth. It’s just common sense to have this sandbox to play in.
And now, go forth and hire thy developer…
One final note: I focused on the coding side of things here, today. There are quite a few things one should do when setting-up WordPress to make sure it’s as secure and solid as can be. If your hosting plan is specifically built for WordPress, most of that is likely already done for you. But if you or someone you hire needs to install WordPress from scratch, then you’ll want to make sure they follow good installation rules.
It’s not easy hiring an expert for a job we know nothing about. We’ve all been there. Worst: as entrepreneurs and small business owners, we tend to know so much about our own business that diving into someone else’s world can be particularly unsettling.
My hope in writing this article was to empower you, teach you how to “talk developer” so that evaluating your next hire (or current one) won’t be as daunting. If I have left some stones unturned, or if I’ve not been clear on any of these points, please let me know in the comments and I will definitely do my best to clarify.
Main photo credit: Cindy Tang