What Lurks in the WordPress Plugin Repository?

We all love the WordPress plugin repository. It’s our playground, where we find new toys and shiny things that make our websites sparkle. With more than 15,000 plugins it’s a massive repository of code that is growing all of the time. But have you ever sat down and thought about all of the different plugins in there? Probably not, why would you?

I did, and here are a few of the things that I found out:

  • More than half of the plugins in the repository are not compatible with WordPress 3.x
  • 85% of the plugins I tested had PHP warnings, errors and notices
  • With a little bit of digging I found a plugin in the repo with a weakness and was able to use it to hack a site and turn it into a drone
  • Only 32% of those 15,000+ plugins have been updated in 2011

And that is just for starters…..

In the Beginning

Here’s what got me thinking – do a search for “Contact Form” in the repository and on the first page of search results is a plugin that was last updated in 2009:

WordPress.org search results with plugin showing as updated in 2009

And what has always been a little bit of a bugbear with me is that there is no advanced search option so there is no meaningful way to target your searches.

And then I thought about it some more – I build websites for clients and then leave them to their own devices. Despite my telling them that they should always check a plugin’s details before installing to get information about it, they often ignore my good advice.

client clicking on the install button without looking at the details

photo of bakiThe thing is, not every plugin is going to work with your version of WordPress. In fact, there are plugins in the directory that were last updated in 2004.

So, I thought I’d do a little digging and, with the help one of my favourite developers, Baki, we did our best to snoop through the directory to see what we could find.

The Stats

Did you know that there is an API to get all of the info about every plugin in the directory? Well, there is, and back in July that’s what we did. We (I say we but, of course, I mean the gorgeous and talented Baki) pulled out all the information we could get and dumped it into a spreadsheet so I could do what I love best….. make pie charts! (*drool* pie……..)

As well as slowing my computer down to a sub-snail’s pace, it also had lots of delicious information that could be baked up into pie charts. Let’s look at the first one:

Pie chart showing 32.3% WordPress plugins updated in 2011, 33.1% last updated in 2010, 20.9 last updated in 2009, 9.9% last updated in 2008, 3.8% last updated before 2008

For people who like figures that’s:

  • 2004 – 8 Plugins
  • 2005 – 151 Plugins
  • 2006 – 69 Plugins
  • 2007 – 490 Plugins
  • 2008 – 1509 Plugins
  • 2009 – 3062 Plugins
  • 2010 – 5052 Plugins
  • 2011 – 4927 Plugins

The means around two-thirds of all plugins haven’t been updated this year, and one third haven’t been updated since 2009.

With more than 15,000 plugins around that’s a lot of plugins that aren’t quite up-to-date. Of course, many of these will work fine with your version of WordPress, but not all of them. And when it comes to end users doodling around not knowing what they are doing it can cause problems.

Plugin developers are able to mark what version their plugin is compatible up to. Here’s the breakdown:

Pie chart showing 8.4% of plugins compatible with WordPress 3.2, 21% compatible with WordPress 3.1, 22% compatible with WordPress 3, 12.5% compatible with 2.9, 9.9% compatible up to WordPress 2.8, 8.7% compatible with WordPress 2.7, 17.5% compatible with earlier versions

The graph shows that around half of the plugins in the repository are marked as compatible with WordPress 3.0 or above.

WordPress 3.0 was a big landmark in WordPress’ development, and these days I rarely install a plugin until it’s marked as compatible up to WordPress 3.x+. Here’s a graph to show how many plugins are compatible with 3.x +

chart 3

Just over 50% – that means around 7,500 plugins are not up to scratch with developments in WordPress since 3.x

Plugins with Old Bones

WordPress has a pretty fast development cycle and things have changed a lot over the years. Functions and files change as WordPress develops – some drop out of usage and become deprecated and WordPress plugin developers are expected to get up-to-date. This means that some of these plugins are using deprecated functions or using functions in a deprecated manner.

Here’s what Nacin had to say on his blog about deprecated functions:

Deprecated functions cannot be relied upon to work efficiently or correctly and may be disabled by default or entirely removed in future versions of WordPress. But really, I would think about it like this: By using them, you’re likely missing out on new features afforded by the new function.

Keep that in mind!

To try to get a grasp of the number of plugins that include deprecated functions, I chose 50 plugins at random from those not updated since the start of 2010, installed them, turned on debugging and took a look inside.

Out of the 50 plugins I installed, 31 contained deprecated functions. Of course, I produced a graph:

Bar chart showing 31 plugins out of 50 with deprecated functions or function usage, 18 with deprecated usage of has_cap, 1 with get_settings, 2 with add_option, 10 with register_sidebar widget, 1 with upgrade-functions.php, 2 with add_settings_field, 1 with add_settings_section, 4 with load_plugin_textdomain

The most common notice relating to deprecated functions is the way that has_cap is used. Has_cap gives or takes away author access to specific parts of pages based on a user’s capabilities.  However, user levels were deprecated in WordPress 3.0 and were replaced by WordPress roles and capabilities. This means that these plugins are not working efficiently, may not be working correctly, and you certainly aren’t getting the new features that came along with the introduction of roles and capabilities.

If you’re interested in finding out if plugins you are using have deprecated functions you should check out Andrew Nacin’s Log Deprecated Notices plugin.

But deprecated functions weren’t the only problems that we found:

pie chart showing that we were unable to auto-install 16% of the WordPress plugins tested

I was unable to auto-install 8 out of 50 plugins. These plugins generated a “Plugin does not have a valid header” message.

Image showing The plugin does not have a valid header message

In the case of the 8 plugins I installed, they all had the same problem. Here’s what the Codex has to say:

WordPress only supports plugin files in the base plugins directory (wp-content/plugins) and in one directory above the plugins directory (wp-content/plugins/my-plugin).

Check out the WP Plugin manager plugin:

image showing file structure of the WP Plugin manager as incompatible with WordPress' auto-install

The file system is a bit of a mess and there’s no way you’re going to be able to auto-install it. In order to get it installed I had to manually put each of the files in the correct place. I’ve had to do this with plugins I’ve gotten from outside the WordPress repository, but never with ones that live there.

Just one more graph for you before we move on:

Pie chart showing that 72.5% of plugins tested generated notices, 11.8% showing errors, and 15.7% if plugins with no problems

37 out of 50 plugins generated PHP notices, with another 8 showing other warnings or errors. That leaves only 8 with clean error logs – that’s only 15% of the plugins I tested are 100% clean…..

As a comparison, let’s have a look at what the Theme Directory Guidelines have to say about submissions to the Theme repository.

On the first line of the Theme Directory Guidelines:

Themes are required not to generate any WordPress deprecated-function notices, PHP errors, warnings, or notices, HTML/CSS validation errors, or JavaScript errors.

And further down:

Themes are required not to have any notices, warnings, errors; or use of deprecated functions.

You can check out the plugin guidelines by comparison. Errrrr….

What Lurks Beneath?

So I installed lots of plugins, tested them out, and made some graphs. But I wasn’t finished. I was sure that there would be something in there that we could exploit.

The next step was to install every plugin in the repository and try, one by one, to exploit them look on Security Focus to find a live issue.

This is where it gets exciting – we found a plugin called Recip.ly that had an arbitrary file upload vulnerability.

We got the team together and this is EXACTLY how it went down:

What all of those visuals are showing you is me (played by Angelina Jolie – obviously) targeting the uploadImage.php file in the Recip.ly plugin folder. We were able to exploit it and upload a shell straight into the folder.

Here is folder before the exploit:

Recip.ly folder showing only two images

Here it is after:

Recip.ly folder showing uploaded shell

A hacker could upload any file to this folder. They can do it straight from their local computer. But he doesn’t need to do much more than load this shell to take control of your site.

Hacker visits the location of his exploit file and gets this screen:

website shell login at the test site domain

Logs in and arrives in the images folder of the Recip.ly plugin:

shell logged in directly to the plugin folder on the hacked site

He can hop up to your site root:

 

hacker in site root

And even into your server:

hacker in server root

Once there they can upload files:

hacker able to upload any file

Run a shell:

hacker running a shell

And all sorts of other things that you do not want going on on your web server.

Basically, your site is a drone.

But, dear readers, before you start getting excited – you can’t exploit my website. The more observant of you will have noticed that I did all of this on my localhost. So ha!

And we’ve notified the WordPress plugin repo, and the plugin developer to tell them about the exploit.

Argh! Is Nowhere Safe?

It was disappointing, but not unexpected to find this exploit in the plugin repository. We were so sure that we would find something we could exploit that we actively went looking for it. And we took a rather lazy route to get there. No doubt there are actual hackers, who really want to hack your site, who use the plugin repository as a starting point for their antics. In fact, recent events have shown us that it is.

This doesn’t mean that the WordPress repository is unsafe, it just means that you should be using it correctly.

Tips for Using the Plugin Repository Safely

  1. Never just click “install” – always look at the details of a plugin before you install it.

always click the details link to check out the details of the plugin

  1. Don’t just look at the star rating. Look at what version of WordPress the plugin is compatible up to. It’s not essential that it’s the latest version but it helps if it is close.

check out the WordPress version - this one shows WordPress 3.2.1this plugin is only compatible up to WordPress 2.8

  1. Go to the plugin page on WordPress.org and look to see if the plugin is compatible with your version of WordPress.
User defined compatiblity information on WordPress.org

Pass this information on to your clients to make sure that they don’t do anything dumb!

I’ve put together a whitelabel WordPress plugin manual that you can pass on to clients to help them along.

WordPress Plugin Safety

The Debate

The issue of orphaned plugins has come up in the past with this discussion on Weblog Tools Collection  back in 2009. In fact, the idea of an “Adopt-A-Plugin Program” was floated on WordPress Ideas 4 years ago its current status is “Good idea! We’re working on it.”

It cropped up again in August 2010 in a WordPress podcast with Matt Mullenweg. In the interview, Matt says that he would rather see major plugins adopted rather than introducing an end of life sequence (go to around 15:00 on the podcast). Fredrick Townes makes the good point that as a consultant it’s difficult to educate users about using plugins that are up-to-date. Matt replies that they would like to see the most popular plugins incorporated into core.

As someone who works with a lot of end-users and clients who have minimal web expertise, I appreciate Fredrick’s question. And it’s never the guy who wants to install Contact Form 7 or NextGEN Gallery that’s the problem – it’s always the client who wants something really random , a small and obscure plugin that only 7 people in the world would install. It’d be nice to see the most used plugins brought into core, but all of those tiny orphans with no one to love them, what about those guys?

In the absence to any real answers to my questions, I did what any dedicated WordPress user always does and turned to Drupal.

There is a really interesting post by Dries Buytaert called “Responsible Maintainers” that is recommended reading for all people who want to submit a module to Drupal. I would suggest it as reading to WordPress developers as well. Here’s a good bit:

You need to realize that if you created a Drupal module that thousands of people depend upon, you created a successful Open Source project. Successful Open Source projects need responsible maintainers in order to sustain. As the maintainer of your project you are in charge, and you have to take responsibility. Period.

Good point – and I think it’s important for people to keep in mind when they embark on creating a new WordPress plugin.

But what about those plugins that haven’t been updated since 2004, 2005,2006, 2007, 2008 – how do we know which ones are reliable or not?

Doing Our Bit

As users we can do our bit to help the community. When you install a plugin, go to its page on WordPress.org and look for this box:

the login box on WordPress.org

If the plugin works, mark it as working. If it doesn’t, mark it as not working. This will help plugin developers to know if there are problems, and tell end users whether they should install.

People don’t do this enough. Check out the data for WPTouch:

WP Touch compatibility information showing only 5 people have marked it as working but 2,381,488 downloads

That’s 2,381,488 downloads – and only 5 people saying it works with 3.2.1.

WordPress community – get off your asses and mark those plugins!

What Can Be Done?

No doubt the guys at WordPress.org are aware of this problem – it’s a tough one to crack. It reminds me of the cupboard in my bedroom – I just pile loads and loads of stuff in there until it’s so full that I keep the door closed, only ever thinking about the nice things in there, and forgetting about the crap.

But, here are some small suggestions that might help:

  • Have a more advanced search function in the WordPress back end and in the repo. Let users search for plugins that are compatible with their version of WordPress.
  • In the back end enable users to order their search by date, compatibility, popularity. You know, like they do on Amazon.
  • Make the search more like Drupal’s search:
  • Drupal's search engine for its modulesEnable developers to mark plugins “Unsupported” or “No Longer in Development” (source)
  • Add a more visible compatibility notice on the back end:

mock-up of plugin compatibility shown on the plugin search results page in the WordPress back end

In Conclusion

This doesn’t make me love the WordPress Plugin Repository any less, but it reminds me of the necessity of being careful. The repo is like a big treasure chest full of pirate’s loot. There are some diamonds in there, some rubies and some chunky gold coins. But there are also coppers, and some bits of tin, a worn out hook, and a whole load of drift wood. And just occasionally you come across a coin which looks shiny but it’s cursed and you end up like those pirates in that film that no one has ever seen… that one with Johnny Depp – you know, some tiny little fun park somewhere made a ride out of it. I doubt you would have seen it anyway.

Enough metaphors! Back to plugins – the WordPress plugin repo is growing all the time and there’s bound to reach a point when there’s more junk than gold. Can things be changed before then?

What do you think? Do you have suggestions for dealing with orphaned plugins? Do we need stricter guidelines about what is allowed in the plugin repository? And what gets to stay? Or do we need better ways ways to educate WordPress users? Let us know in the comments!

P.S. You got to the end! Want to see all the data?  Check out the spreadsheet!

(header image CC peasup)

Comments (48)

  1. “Good idea! We’re working on it.” LOL! This has got to be the funniest post on your site so far! Totally agree with beefing up the search options. And Dawson Leery with Lara Croft … awesomesauce, hahahahaha.

  2. Holy heck. I’d love to have see a snippet of y’alls code to pull the Plugins API so we could start with sorting through 3.x+ compatible for first pass checks for an existing plugin. Then and only then work backwards based on downloads and responses for the funcationality of something important (php includes come to mind for an old but useful plugin for example).

  3. Maybe plugins on the repository should have an expropriation date after which they will not longer be available unless they are updated to the current version of WordPress.

    • How would it be made available for someone to adopt/update to make compatible though…?

      Definitely a case for not being able to auto-install plugins that are behind on their updates. Ideally plugins should be tested and the comment code updated and the plugin re-released for every WP version.

  4. There are things that I love about WPMU and things that I know I could love more…

    One thing that I do love is the ongoing attention to WP that is always evident. You have a great consistency with producing valuable and readable articles… which I’ve been both informed by and happy to receive…

    One thing that I would love more – and this article may be a nice jumping off point for that conversation – is the “recipes” for plugins – modules and the like that you’ve deployed.

    I know that in the last several months that I’ve been prepping a few different wordpress/joomla/hand-rolled projects, I’ve turned to various sources time and again trying to find a way to quickly gain a foothold of understanding on bringing the right plugins together to solve all my little wants and desires. The trouble has been just this – things are constantly in motion with development, and plugins die.

    Where this has me now is that except for keeping it on my radar, I’ve all but abandoned WordPress and Joomla as starters. There’s too many options without much guidance. (I should offer my caveat here, I’m “techy” but not steeped in WordPress how-to’s and what’s its… : I’m probably like 85% of the folks who troll through here and other sites similar – I have a substantial amount of expertise in creating great good things, but I’ve seen the great results from hand rolling my own. (Learn J-Query and the world is prettier?))

    What I’ve wanted and hoped for from WPMU is really your cook book. With EduBlogs you have such a great opportunity to share what you use on a daily basis without revealing anything that is proprietary. I’m pretty sure that your headstart in that sphere has you untouchable in many ways… but yeah – I’d LOVE to get a snapshot of your active plugins/tools for development/modules on EduBlogs.

    Also, it would be SUPER SWEET to basically provide “dummy kits” for people who want to use the robust plugins and tools that you have – so like the “essentials” kit would have all those root and base things that EVERY WP site should have (security etc.) the “Social Kit” would have all those plugins that anyone wanting to create a pay membership site would want.. (You’ve got the tools now – but they are a bear to configure in the vacuum of the inter webs…)

    Anyway – These are my thoughts as I see you’ve been sorting through the weeds with me…

  5. Wow,To think how I’ve ignored whether a plugin is compatible or not with my theme in the past has me now on edge. I really appreciate this information. Although I don’t consider myself tech savvy,you’ve provided me with some things I .can do in the future to safeguard my WP-site. Keep it coming

  6. The repository should be organized by known compatibility according to specific generations of WordPress. If not compatible, the plugin is not listed. That would encourage developers who still care about their plugins to update them, or otherwise for ad-hoc teams of developers to update plugins they deem important and that the original developer has left dormant. The existence of plugins that crash WordPress in the repository is a problem for WordPress’s growth as a user friendly, accessible web platform. What is on wordpress.org should just work. Period.

  7. I would love to see a filter in the results that allows the user to view ONLY plugins (and themes for that matter) that are compatible with the specific WP version you are using. So if I am running 3.2, I want to only see plugins that actually can be supported by 3.2.

    I would think though, there would need to be some sort of a simple testing method that allows older plugins to be tested against the latest version, so that even if an older plugin is no longer maintained, but still works and is viable to the community, it’s compatibility information can be updated easily.

  8. I’ve stumbled upon this website recently try wpplugindirectory.org

    I’ve stumbled upon this website recently, I use this as a alternative of official repository. It’s great if you want sort plugins based on vote, rating,published,updated date. Besides that they have a list feature which I find very useful.

Participate