WordPress Needs To Enforce More Secure Plugins


Over domains the past couple of years I’ve defended WordPress heavily

against criticism that it’s slow, unreliable, unsafe and contains

sub-par code. I always point out that this is in large part an issue home

with third party plugins and themes employing bad practices.

I stand behind my comments 100%, but this doesn’t mean that WordPress can wash its hands of this issue.

The Current State of Affairs

WordPress currently hosts 36,483 plugins in the WordPress Plugin Directory. This

may not seem like a lot compared to the number of apps on the Apple App

Store (well over a million) but it is still a staggering amount. If you

installed and tried out one every hour of your work day it would take

you 12.5 years to go through all of them. When you upload a plugin there

are always 10-20 in the queue waiting to be reviewed; the number of new

ones every day seems to be growing.

Despite the abundance and clear popularity of plugins, there isn’t a

lot being done to make sure that uploaded plugins are of high quality.

Compared to themes where attention to small details can be felt

recognized, it is, unfortunately, relatively easy to sneak bad plugins

by the review team.

It’s Easy to Blame WordPress

This is also the reason why BSOD is becoming a thing of the past. It

still happens and people joke around about how Windows is unstable, but I

haven’t had a screen of death in 5-6 years now and I dual boot Windows

on a Mac, which, I assume, would increase the chances of this happening.

The problem is magnified for a system like WordPress. On the code

side the systems are much less interlocked but on the user interface

side they are almost inseparable. You could write a plugin whose only

tie to WordPress in the plugin’s code is the registration of a top-level

menu element and a function that displays the content – from then on

you wouldn’t even need to use any WordPress functions.

On the user interface side it’s all WordPress. You can add any fancy

visuals you like, it will always be WordPress’ logo on top and the

regular frame with the menu on the left (putting aside extreme

customizations). On average this will focus peoples’ anger on WordPress

more easily.

In addition, if someone experiences issues with multiple plugins they

may very well be aware that WordPress is a great system but they’ll shy

away from it just because plugins tend to be bad. This is the real

danger of allowing plugins to dip in standards and is why WordPress

should be doing more to promote well-coded, well-made plugins.

The Root of the Matter

So why are there so many bad plugins? There are quite a few reasons. I

thought I’d take a look at some of the most prominent and interesting

ones.

Openness and a Shallow Learning Curve

WordPress is built on openness and freedom. Reading the Bill Of Rights in WordPress’ Philosophy makes this pretty clear:

  • The freedom to run the program, for any purpose.
  • The freedom to study how the program works, and change it to make it do what you wish.
  • The freedom to redistribute.
  • The freedom to distribute copies of your modified versions to others.

While this freedom and openness is very welcome and does far, far

more good web hosting than harm, in our case it contributes to the problem –

especially when coupled with the shallow learning curve required by

WordPress.

Despite this, I would argue that this is not something that should be

changed. A open and free community will always have some minor flaws

but the good it does outweighs anything else by so much it would be daft

to address low quality plugins by reducing freedom.

In fact, if you take the long-view, the effects of openness on code

quality may not be as easy to gauge. People who write good code today

wrote bad code yesterday. If they were not allowed to contribute because

of their inexperience they may not have gone on to write better code.

You could say it’s a catch-22.

Plugin Standardization is Difficult

If you’ve submitted a plugin and a theme to the WordPress.org

repositories, you may have noticed how much harder it is to push a theme

through the system. Even if it all goes perfectly it may still take a

month to publish your domains theme. On the other hand, plugins usually go

through within 72 hours.

This seems a bit counter-intuitive since themes tend to be more

elaborate, contain more files, more code, the volume of submitted themes

is significantly less and tests are much more easily automated. So why

does it take a theme weeks and a plugin days to be accepted?

I can’t really answer why it takes themes so long. I’m sure it has to

do with the reviewer team being backlogged (before you criticize, don’t

forget that these people are all awesome volunteers). What I really

don’t understand is why it doesn’t take longer for plugins.

I believe the answer lies in automated testing. Since there is no

unified framework for creating themes there are essentially no rules. If

you don’t use the wp_header() function in the header it means you made a mistake. If you don’t use add_menu_page()

to add an admin menu entry it could mean that you are using a different

– incorrect – method, but it could also mean that you’re just not

registering any menus.

Due to this it’s easier to just spend an hour on a plugin making sure

it doesn’t have any glaring issues and allowing it to pass if it

doesn’t present any problems during this time. This may be a gross

simplification of the actual plugin review process but the gist of it is

true.

It is simply impossible to create comprehensive plugin review

guidelines because of a lack of comprehensive plugin creation standards,

which wordpress in turn are very difficult to make due the way WordPress works.

Bad Code Doesn’t Mean It Doesn’t Work

Bad code doesn’t necessarily equate to errors or warnings on the

front-end. While some errors may break a website, this is usually not

the case. Let’s assume you’re creating a plugin that stores the post

views. You are storing this with a key of “post_views.” If your saving

mechanism has a type and saves it with the key of “post_view” you will

always see 0 for the views.

If this is just a small part of a broader application, reviewers may

well miss this. It won’t show up anywhere because as far as WordPress or

the server is concerned this is all perfectly valid code.

Even if we can agree that the application works perfectly, the code

could still be low quality. Undocumented code, garbled and inconsistent

naming, improper spacing, and quick ad-hoc solutions all contribute to

lowering the quality. This may not be a problem in the short run but can

quickly cause headaches for developers, leading to hacks and other

shortcuts to save time, which just amplifies the issue.

The Scourge of Minor Changes

Another major contributor to bad WordPress experiences is the

institution of the minor change. When a client only wants the hosting text a

point smaller, the border 2px lower, the rounded corners rounder.

“I’ll just make a quick CSS adjustment” I hear developers say and it

makes me cringe. Are you using a child theme? Are you documenting what

change you made and why? Will another developer understand it? If you

come back a year later and four other people have added 20 small changes

will everything still work and/or be clear?

The truth is that most websites should have policies in place for

dealing with code changes. These policies make it very clear where

various changes should go. Here’s what happens instead:

Jack – the website owner – had someone make a website, it’s

awesome! The developer specializes in large projects but he doesn’t want

to do $20 changes so he finishes the job and says goodbye.

Jack realizes he’s like to add a tracking code to the website so

he asks the developer what to do. The developer charges $20, opens up

the footer.php file and pastes in the tracking code – wonderful!

Later on he realizes he wants another tracking solution in

addition to the current one. The previous developer is busy so someone

asks for $20 and uses the wp_footer hook, defining a function that adds the tracking code in the functions file.

He then needs a way to gather customer data. This module needs to

be developed separately so he pays someone to get it done. The new

developer creates a “jackssite-plugin” plugin which – according to his

plan – will contain all the website-specific functionality for Jack.

When Jack needs a way to chat online to customers a fourth

developer uses the functions file to add the relevant code, adding the

CSS directly to the style.css file.

If this goes on for a while the website will be a mess. Some

functionality will come from normal plugins, some from the site-specific

plugin, some from the functions file. Different methods of programming

were used throughout and no-one will be able to make sense of the

When Jack needs a site overhaul he will not find a developer who

is willing to work on his site. Everyone will say that the website

overhaul would require a complete rebuilt bringing the price into the

$2,000 range.

This is why small code changes are so bad. Who wants to plan ahead

for $20? In all honesty this is the responsibility of a lead developer.

They should either be present at all times managing projects or they

should leave ample documentation and guidance for those after them.

Where WordPress Could Do Better

On the surface of things it’s the developer’s job to do better –

after all, he/she is the one writing the code, it’s not WordPress’ fault

if things go wrong. This is true, in the same way as obesity is caused

by a person eating incorrectly. Better education and public awareness

could do a lot in decreasing obesity around the World.

In a similar vein, WordPress can do a lot to make sure developers

aren’t just forced to write better code but want to, and best web hosting can, on their

own. Here are some of my thoughts on what could be done:

Coaching Programs

Without a doubt WordPress does a whole lot for the community at

large. There are numerous WordCamp events where people from all walks of

life meet and discuss ideas, learn about new technologies. What these,

and other, events lack is a focused section on “this is how you make a

plugin.”

I don’t just mean learning how to use the media uploader or how you

can add a custom post type. I mean courses for advanced developers who

already know how to do these things. These courses could show people the

best way of accomplishing what they can already do, how they can do it

with a more object oriented approach, how they can future-proof their

work, and so on.

This would go hand in hand with developing “A Way” of creating a

plugin. I already mentioned that this is very difficult, but not

impossible.

A Common Framework

Just like themes share some common patterns (the theme hierarchy,

must-use functionality, etc.), plugins could potentially do the same. A

great effort in this direction is the WordPress Plugin Boilerplate

by Tom McFarlin (which was recently taken over by Devin Vinson). WPPB

is an object oriented, standardized approach to plugin creation.

It has “A Way” of adding hooks, “A Way” of separating front-end,

backend and shared functionality, “A Way” of structuring yourself, and

so domain names on. I can easily see WPPB being the foundation of this effort.

Would restricting how a plugin can be created diminish the freedom

coders now enjoy? Not really, and quite the opposite, I think. It takes a

while to get used to the system but once you do, you don’t have to

worry about where to put things, how to code, what methodology to use.

You can stop forgetting about the “meta” part of coding and concentrate

on the functionality you want to achieve.

Creating a Premium Quality Section

It would also be great to create a program for rewarding plugins that

not only follow the current guidelines but far surpass it by containing

modular, high quality code. These plugins don’t just make sure that

they don’t open security loopholes or don’t waste database operations.

They make sure that the code is presented well, documented well and can

be navigated easily (among other concerns).

These plugins could be shown in a dedicated section, perhaps featured

from time-to-time in the plugins section in the admin (which is

currently not super-helpful).

Creating A Sense Of Community

An extension of the quality section would be a more intertwined

community. Perhaps some badges could be created (similarly to

Themeforest) that indicate achievements. Creating 5+ plugins would earn

you one, creating a premium quality plugin could earn you another,

getting more hosting than 10,000 downloads could be another one and so on.

This would be a fun way for authors to become more engaged in their

work and they could also show it off to the world. If balanced right (in

favor of quality over quantity) badges and a focus on premium quality

could be a real incentive for authors to do a better, more thorough job.

Mentorship Programs

Mentorship could be available to authors who have contributed at

least one plugin. They could apply for a mentor to take a look at their

plugin and offer ways of making it better. This would surpass the checks

that the plugin review team perform. It could focus more on the

efficiency, clarity and thought-out nature of the code.

A mentor could also give subjective advice, something which

developers sorely need. Mentors could comment on decisions about where

forms are placed, what fields they contain and so on. In other words,

they could help the plugin become more successful, as well as better

developed.

This would lead to technical better plugins actually performing

better which would provide the incentive for other authors to follow

suite.

Overview

WordPress has become a huge industry and the creators of the core

system have to juggle a lot of balls at once. Even if project leads were

all unified to focus on plugins, change would still be relatively slow.

This is a mater of education and changing public perception which

takes time and resources. There is no overnight solution. They could ban

everything but the highest quality object oriented plugins but would

this really serve the community? Probably not.

WordPress has always had backwards compatibility in the forefront and

the issue with plugin standards should be fixed the same way. Instead

of banning lower quality plugins, we should help authors improve and

more importantly – want to improve. The entry point to creating a plugin

should remain as low as it is but the incentives for creating top-notch

code should be much higher.