WordPress Needs to Enforce Better Plugins – and Here’s How to Do It
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 is in large part an issue 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.
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 environment.
A note before we begin: I will be writing a lot about badly coded plugins and bad plugins in general. I want to make it clear that WordPress has some amazing plugins (especially the ones on this site!), which set a great example for coders everywhere. In this article I’m focusing on the bad ones, due to the nature of this article. I’m fully aware of the amazing products that are out there.
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
It seems to me that WordPress has similar problems to Windows. When you get a blue screen of death – lovingly known as BSOD – you always blame Windows, even though it may well have been caused by a massive memory leak in an application. Since Windows is the “public face” of your computer, when something happens that doesn’t seem to be app-specific, the operating system is always blamed.
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 more obvious that the app is to blame and at least you don’t need to restart your phone.
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 than harm, in our case it contributes to the problem – especially when coupled with the shallow learning curve required by WordPress.
A system such as Laravel is in sharp contrast. It is just as open but you need to know advanced object oriented techniques and have some outlying skills with the terminal and software such as Composer in addition to everything else to use it properly. This means that by the time a developer learns enough to code with Laravel, they will be churning out better products.
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 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 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.
1.6 million WordPress Superheroes read and trust our blog. Join them and get daily posts delivered to your inbox - free!
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, 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
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 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 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 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 developed.
This would lead to technical better plugins actually performing better which would provide the incentive for other authors to follow suite.
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.
If you’ve seen any projects that promote best practices or you have any ideas on how WordPress could do better do let us know in the comments below.