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:

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.

The 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:

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:

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 +

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:

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:

I was unable to auto-install 8 out of 50 plugins. These plugins generated a “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:

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:

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:

Here it is after:

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:

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

He can hop up to your site root:

And even into your server:

Once there they can upload files:

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

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

3. Go to the plugin page on WordPress.org and look to see if the plugin is compatible with your version of WordPress.

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:

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:

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:
• Enable developers to mark plugins “Unsupported” or “No Longer in Development” (source)
• Add a more visible compatibility notice on the 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)