Over 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 domains is in large part an issue
with third party plugins and themes employing bad practices.
In this article I thought I’d play devil’s advocate and explore some
opportunities WordPress could take to raise the standard of its extended
The Current State of Affairs
WordPress currently hosts 36,483 plugins in the WordPress Plugin Directory. This
may wordpress 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
However, an OS can always implement better memory handling policies,
for example. One reason iPhones freeze less frequently is because they
are strict with memory handling. If an app goes above a limit, the app
is closed without question. While this is annoying, it is vps hosting more obvious
that the app is to blame and at least you don’t need to restart your
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, wordpress 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
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
Openness and a Shallow Learning Curve
WordPress is built on openness and freedom. Reading the Bill Of Rights in hosting 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 than harm, in our case it contributes to the problem –
especially when coupled with the shallow learning curve required by
complex languages out there. The openness of the community and the ease
with which you can contribute code means that invariably bad code will
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 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 domains 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
to add an admin menu entry it could mean that you are using a different
– incorrect – method, but it could domain names 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
It is simply impossible to create comprehensive plugin review
guidelines because of a lack of comprehensive plugin creation standards,
which 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 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, web hosting australia opens up
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 web hosting 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
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
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 can, on their
own. Here are some of my thoughts on what could be done:
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
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
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 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 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 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
This would lead to technical better plugins actually performing
better which would provide the incentive for other authors to follow
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.