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.

WordPress is built on PHP, HTML, CSS and Javascript – not the most complex languages out there. The openness of the community and the ease with which you can contribute code means that invariably bad code will be published.

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.

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 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 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 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 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.

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.

18 Responses

  • New Recruit

    I think the founders of WordPress would argue that the current plugin reviews, ratings, and support sections is a form of crowdsourcing that already is identifying what is quality and what is not.

    However, I agree that more should be done to further segment/categorize plugins based on additional quality criteria.

      • Flash Drive

        Come on Daniel, there’s a huge ratings and review system built already. Who the heck is going to run this huge government infrastructure/vulnerable to favoritism/nepotism/insiderism system you’ve dreamed up?

        While I’m all for quality plugins, your recipe seems like the worst way to get there.

        What would help would be a process to identify irrelevant ratings (driveby one star ratings which seem to be for plugins other than the one that the reviewer is reviewing). Perhaps people should have to pass a basic IT test before being allowed to have their ratings counted (i.e. one could allow them to rate but one doesn’t count or show their ratings/reviews by default unless the person takes the test).

        The recent introduction of active installs tells me a lot as both developer and user about the field worthiness of any given plugin.

  • New Recruit

    WordPress did commendable efforts in terms of systemic risk, can you imagine it, less than one year ago exploitable zero-day issues required the admin to manually accept to run blog updates, it wasn’t automatic O_o
    However, wordpress still has a LOT to improve.

    Mainly, I think the main problem here, is that wordpress will allow blogs to exist with plugins in an abandoned state or, worse, that are known to be vulnerable to attacks.
    The idea behind this is that it’s up to the admin to run updates. Well, in the real world, plenty of blogs are left dormant and not monitored daily, and plenty of blog owners are scared to death to update their plugins for fear it will break their website.
    Wordpress won’t even consider sending a private message (by email) to the blog owner to tell a plugin that is active on the blog has been removed from the official wordpress plugin repository for a security reason.
    Lastly, blog owners will not be informed when a plugin on their blog is removed from the repository. New searches won’t display the plugin in the repo, and yet it’s present on the blog : mystery !!
    A “better than nothing” solution is the “Plugin Security Checker” plugin : I’m mentioning it for potentially interested persons, at least, it checks plugins for the most known security holes, and tells blog owners when their plugins aren’t listed in the official repo.

    The devs are more or less aware of the question (I complained about it three years ago, and then one year ago, response was : “we know” , as in https://wordpress.org/support/topic/negative-although-honest-feedback-wordpress-still-generates-systemwide-risk?replies=10 ), but it has yet to bear some visible results.

    Also, wordpress doest a bad job at pushing the best plugins forward.
    Try a web search on wordpress’ website or within a wordpress blog admin. It’s just not possible to figure how the sorting criteria are chosen. You’ll see among the first page results plugins with either 20k+ installs or 700 installs, plugins updated one week ago or unchanged in the last two years.
    We could hope that popularity would ensure a certain minimum level of quality (“if 50 000 people have installed this, somebody would have noticed if there was a security hole, right ?”), for instance.

    • New Recruit

      (a minor update to my comment. I found on a blog a six-years old plugin that had never gotten an update. Most likely it doesn’t *need* one (it’s allowing visitors to add your blog to your firefox browser’s built-in search engines), but, still, there goes my hope the “Plugin Security Checker” plugin would notify us admins of every deprecated plugin.)

  • Design Lord, Child of Thor

    I generally agree with what is being said here and Oliverfr’s comments hits some important points. However, here is the thing no one ever says: WordPress is not Apple Pages or MS Word. It is not a fire-and-forget product and never has been. Today it is a developer’s framework while also being a low-end yet robust Content Management System. The reality is that vast majority of people calling themselves “web designers”, along with the “do-it-your-selfers”, do not know what they are getting into.

    We have created an entire business model around offering fast, stable WordPress installations. This is made possible by using a very stripped down theme as a foundation and only using plugins that are highly supported, very popular, and are cross-plugin compatible. 70% of this framework is WPMUDEV code and we have a direct connection to the the rest of the plugin authors. Plus we spend 100’s of hours testing all combinations every time a new update comes out.

    I hold the folks at WordPress responsible for keeping the core secure and stable and keeping developers as informed as humanly possible. After that it is up to the website owner (or the one who installed the site) to stay on top if the technology and stop expecting it to run like a Mac.

    We use a very popular premium plugin, supported by a large team, that was hacked into recently. They patched it, notified their registered users, we updated, and all was well. The point being that the people at WordPress can set the standards and enhance communication but lets not forget that we are not paying them. The cost, that is not talked about, is in picking up where they stop.

    Perhaps what we really need is a “Yelp.com” for plugins and themes.

  • New Recruit

    I have often had thoughts along these lines although have come to the conclusion that it is an almost impossible task to achieve. You hit the nail on the head when you pointed out that an automated solution would not in itself find good or badly code, merely allow code to pass a basic check.

    The reasons that you give for not limiting the way that WordPress can be extended is also spot on and it is perhaps the major factor in it’s dominance of the current CMS world.

    The free plugin directory is what it is and there are other places to go for a premium plugin – such as this site for example.

    For more longer term maintainability I think you are also right regarding coding standards and a structure for placing code in relevant files is the way to go. This does however come at a cost to any website owner and I think that this is way beyond $20 per modification. I suspect that this puts it out of the reach of the vast majority of site owners who will be blissfully unaware that they are putting a sticking plaster over a hole that needs a proper fix.

  • WPMU DEV Initiate

    I’m tired of hearing that PHP has a shallow learning curve and that it’s one of the big reasons why crappy code lands in the WordPress plugin repository. It’s 2015. PHP has matured into a respectable language with robust tools. Those of us learning PHP are aware of OOP, security, and doing things the ‘WordPress way’. To pretend like we’re all just banging together sloppy procedural code with gaping security holes just advances the narrative the community always hears from the outside. By contrast, you mean to say no one writes sub par code in the C# community? Rubbish.

    I say let’s dig into the root causes and not just parrot some old(ish) saw.

    • Hi there,

      I didn’t say everyone was writing sub-par code, I just said it was easier to do. I also acknowledged your issue with PHP not being outdated anymore when I talked about Laravel. Laravel is PHP and MySQL (if you use MySQL as the database) just the same but since it is purely and wholly object oriented, it’s much more difficult to write sub-par code.

    • New Recruit

      A year ago I was working at a marketing company where they had a plethora of languages in use for web development from c# to ruby and php. I saw C#, ruby and Laravel code that was atrocious and performed very badly. In fact there was a project that was supposed to be delivered in ruby that after 3 months resulted in the worst demo I have seen in my life. I had to rewrite the project and I used WordPress and managed to get a fully functioning system in 2 weeks. Incredibly to me I was still told that an MVC framework promoted ‘good’ code, at this point I am tempted to put in an expletive. And then exactly the same thing happened with a Laravel project. It is VERY easy to write bad code in any language or framework.

      For me the biggest problem is that the WordPress community accepts the claims that are thrown against them.

      I have coded in C++, Java and C#. I have also used Symfony in PHP. There is nothing superior in the coding of any of these but they are potentially more appropriate. They can also certainly have poor code….

  • New Recruit

    open4biz said: “I’m tired of hearing that PHP has a shallow learning curve.. ”

    True. It’s because people don’t learn anymore. Coding used to be an ongoing education which led to further innovation. Now students are gaining degrees based on memorizing what”s already written down.

    • WPMU DEV Initiate

      My experience suggests the opposite. The Facebook groups I’m in contain would-be developers who are mindful of OOP, security, etc and they constantly look to improve. Perhaps I found a pocket of like-minded individuals, but the folks I know busy themselves with practice, sequestering feedback, and tracking down a mentor to up their devy dev game.

      Cheers

    • I think @Ally is definitely on to something but I don’t think this is necessarily a bad thing. I think the fact that people are “memorizing what’s already written down” is a bad thing, but it shows that the “coding profession” is maturing.

      Everything new is full of innovation. As things progress, methodologies are created which can be used extremely well but can also be memorized and misused. The fact that we’re at a point where we can boil things down to memorizable chunks is great for those who have the drive to learn things properly. Of course it also means that we’ll have some bad coders around, but I think this is a necessary evil we have to live with :)

  • New Recruit

    Maybe. But isn’t that the driving force behind wp sales? “One click. No need to know code”. You know, I once heard of a couple of guys who some 30yrs ago who would climb great bins to dig out the dot matrix printouts and try and figure out the code printed on them. I’m not so sure we see that kind of enthusiasm anymore.

  • Hey Daniel,

    You make a lot of great points! I’ve pondered about this a lot myself. Unfortunately, as you pointed out, WordPress has a lot of freedom for developers to make things better consistently for everyone, but it can sometimes lead to sloppy coding.

    It’s a difficult thing to fix, but you have a lot of great ideas. Plus, a plugin could be decent when it’s reviewed and approved, only to have malware injected into later, without any additional review process. It’s certainly a sticky situation without a perfect, quick solution, but it’s more than worth exploring the options. You wrote a great post here!

    Cheers,

    Jenni McKinnon

Comments are closed.