Be a Web Developer Not a Plugin Installer Masthead

Be a Web Developer. Not a Plugin Installer

WordPress is my CMS of choice based on it’s simplicity, extensibility and the variety of plugins and extensions. Given it’ popularity, I’m not the only one.

But I’ve been stepping out on my lady. I’m working on a project in which the client chose the platform before I joined the team because it provided key features and it’s stock theme roughly matched their mock-ups. The choice to use third-party code led to missed deadlines, scope creep, and scrapping features because the platform isn’t easily extended. (For the record, WordPress would have been a terrible choice too.)

We’ll never know if it was the right decision, because the project will launch duct-taped together. This project wasn’t built on WordPress. So why am I talking about it? If we abstract away the technology there is an important lesson to be learned about what it means to be a web developer.

Hold Yourself Accountable

Developers are responsible for the code they sell to clients, not just the code they write. Our clients trust us to make good decisions on their behalf, and we often take that trust for granted.

We shouldn’t expect a client to understand the difference between our code and third-party code. If we choose to use plugins to build a solution we take credit when that choice results in success. Yet when the extensions we install (plugins and themes) lead to failures like hacks or broken updates, we’re perfectly willing to absolve ourselves of responsibility. It’s not our fault! It’s the plugin!

Who made the decision to install that plugin? Are you a web developer? Or are you just a Plugin Installer?

Be a Web Developer. Not a Plugin Installer

Choosing to install a theme or a plugin should not be a careless act. Perhaps we’ve stopped thinking about it because WordPress has made installing them so easy. Many developers approach plugins with a cavalier attitude and don’t consider the consequences of blindly installing third-party code that could do just about anything intentionally, accidentally, or through a hacker’s exploitation.

Plugins: WordPress’ Double-Edged Sword

Plug-ins made WordPress successful. So how can we leverage the massive library of free and paid extensions while minimizing our exposure to the problems they can produce? Here are a few questions to ask yourself to avoid installing bad plugins.

1. Did you pirate the plugin?

If you pirate a WordPress plugin, shame on you. People who make things for a living shouldn’t be comfortable stealing other people’s creative works. It’s really that simple. Besides: installing plugins from pirated sources is a recipe for disaster.  Pirated plugins often come with exploit code baked right into them. Their backdoor isn’t technical: it’s exploiting your cheapskate nature. Just. Don’t.

2. Does the plugin come from a trustworthy source?

There are a ton of sources for WordPress plugins on the Internet. The official WordPress Directory for example. It should go without saying that you shouldn’t install plugins and themes from disreputable sources. Don’t shy away from premium plugins from foundries like WooThemes and developers that sell their work via CodeCanyon, but research them before you install them.

  • Consider plugin and theme ratings.
  • Read user reviews
  • Check the plugin’s update history to make sure the developer is dedicated to maintaining it
  • Look for third-party information on whether or not the plugin has been hacked in the past

3. Do You Really Need a Plugin?

We’re web developers, right?

So why do we feel like we need to introduce other people’s  code into our sites just to add social sharing buttons, insert a tracking code, or add an image slider? If you can’t do these things for yourself, you’re not a developer. You’re a plugin installer.

Plugins make some tasks so easy we take them for granted.   But it’s important to remember that every time you install a plugin you introduce another potential vector of attack and another thing  that needs maintained forever.

Sliders are a great example.  Everybody wants a slider (though their value is dubious). Most of us simply install one of the many popular slider plugins and get on with our day. But slider plugins have been particularly vulnerable to attack. The incredibly popular Slider Revolution plug-in has been a very popular hacking target in the past.

So ask your self: do you need that slider?  Does the client really need to maintain it from the WordPress Dashboard? If not, it’s a prime candidate for skipping a plugin, and writing a few lines of JavaScript that won’t get your site hacked.


These lessons aren’t specific to plug-ins. They’re not specific to WordPress. Heck, I’m not even sure they’re specific to web development. As professional problem solvers we need remain conscious of the individual parts we use to build our solutions. Don’t Repeat Yourself, and Don’t Reinvent the Wheel. These philosophies remain true.  But don’t be afraid to build better mousetraps, particularly when the current design has a history of failure.