Behind The Scenes In The WordPress Plugin Directory With Mika Epstein

The WordPress Plugin Directory currently lists more than 29,000 plugins. It’s the first stop for any WordPress user looking to extend the capabilities of the software. With over 585 million downloads and a massive worldwide user base, it takes a dedicated team to monitor the quality and security of so many extensions.

I had the opportunity to interview Mika Epstein, better known around the web as “Ipstenu“, about her work behind the scenes with the plugin directory. Epstein is part of a team of folks, including Scott Reilly, Pippin Williamson, Otto, and a handful of others, who stand at the door of the repository and review incoming plugins to make sure they meet the guidelines.

How does someone get involved with reviewing plugins for WordPress? For Mika it was in the vein with something she’d be doing already. She has a passion for helping plugins play nice with WordPress.

Otto reached out to me to join the plugin review team after I started, on my own, scanning the repo using Mark Jaquith’s slurper – for people who were doing some silly, but easy to mistake, things like jquery. This started after WP upgraded jquery and a lot of plugins and themes broke. I was so annoyed, I started trying to head them off at the pass.

The Plugin Review Process

Once a plugin developer submits his work to the directory, he or she generally has to wait a little while for it to be approved. Epstein says that they try to get to everyone within seven days but that some weeks are better than others. “Small plugins are often approved right away, larger can take a while,” she said. “On our good days, we can same-day review everyone. How long each review takes is also subjective to the plugin size and complexity. [pullquote]Many times a delay pops up when we have to figure out what the code was supposed to do because of poor documentation.[/pullquote]”

There’s a helpful gem in there for aspiring plugin developers submitting to WordPress.org: The better your documentation is, the faster your plugin is likely to move through the process.

You might be surprised to learn that the plugin review process is not terribly mysterious or complicated. It simply takes a little bit of time. Epstein outlines what’s involved:

We review plugin submissions, and that really means we download the zip, read the code, test it, and approve it or push back for various things. Every single line of code is looked at, and we generally look for things that are ‘wrong.’ After a while, they start to jump out at you.

This translates into a daily routine for her. “I usually spend an hour or two a day just on plugins,” Epstein said. “Minimum’s an hour, which lets me run a decent triage on people with pending requests and some of the new ones.” Additionally, there are reports and weird issues that come in that she will funnel to the entire team.

The Most Common Issues With Plugins

Believe it or not, the most common reason for a plugin to get rejected is not ultimately due to brazen violations of the guidelines. Epstein says that many plugin authors simply do not reply to emails: “After 7 days, if the plugin code isn’t completed, the plugin’s rejected.”

Bad plugin names are another reason that she says are grounds for rejection, as well as HTML in the title. “We auto-reject anyone with ‘wordpress’ in the plugin slug (like you can no longer request ‘wordpress-fedex-shipping’) but manually we reject anything with encoded HTML characters in the title (like %d) or the term ‘plugin’ (most of the time… if your plugin is ‘network plugin settings’ that’s okay, but ‘rebooter-plugin’ is not).”

Why Plugins Get Pulled From the Directory

You’ve probably seen it happen a time or two: A plugin is newly listed in the repository and then it suddenly vanishes a day or two later. I asked Mika why it is that a plugins make it through this review process but end up being pulled just a couple days later. She replied:

Ouch. So … we’re human, right? And SOME plugins are really simple and others are really complex. Just like the dev may miss a security hole in their plugin, we might too. While we do look at every line of code, the problem with this is the same as the problem with all security reviews and that is we look for wrong, and sometimes miss it in the cruft of right.

In addition, Epstein said that sometimes WP Tavern or another site will post about a new plugin and then a larger number of people will take a look at it, inspect the code, and uncover something that might have been missed. However, there are some plugin developers out there with bad motives, who knowingly violate the guidelines through what Epstein calls a “bait-and-switch”:

Someone submits plugin A, we approve it, but they upload plugin B to the repository. That’s something a lot of spammers like to do. Sometimes people upload the wrong version of the code by accident, other times they intentionally go back and add in code we told them to remove. We try to mitigate this by filtering emails (I actually get an email for every single plugin check in) and scan for known issues, but it’s never-ending. Right now there are 20 security reports to go through.

The review team is constantly improving its checks, which help them scan for the most basic and unintentional violations. Unfortunately, there is no way to scan for bait-and-switch techniques, which require someone to go back and manually check for violations after the plugin is already sent to the repository.

Advice For Managing Orphaned Plugins

One of the problems plaguing the plugin directory is plugins that have been abandoned or are no longer maintained. Given Epstein’s close involvement with support, I asked her what the best course of action is for a plugin author who no longer wishes to update his/her plugin on WordPress.org. Would it be best to remove it? If he/she can’t find someone to adopt the plugin, is it better to leave the plugin there as a starting point for someone else or to remove it entirely to prevent frustrating users? Ultimately, the decision falls to the plugin author, but Epstein offered some practical tips:

• If a plugin author wants to no longer support or update a plugin, I suggest they make DARN SURE that’s documented in their readme!
• If they want to leave it open for someone else to adopt that’s great, just make sure to put up a way to be contacted.
• If they want to close it forever and ever, that’s okay too, just email plugins AT wordpress.org and link to the plugin.

“Which is better? Depends on the plugin,” she said. “Like Blackbird Pie, the plugin to embed Twitter, was something I would feel was essential not to close … until we added in Twitter oEmbeds. Now it’s not really as needed and may not even work. Would I extend that or close it? Hard to say, even if it was mine.”

The Readme.txt File is Key to Improving User Experience in the Plugin Directory

When searching the directory, it’s not uncommon to find plugins with what seems to be only a title. Many plugins are missing vital details (or any details), screenshots, FAQs and basic information about what the plugin does. I asked Epstein what can we do to encourage plugin authors to provide more information. She has a few solid tips:

I hate bad readmes with a passion. I try to push people to make better ones, pointing out that if the readme (which makes your wporg repository page) isn’t descriptive and helpful, no one will use your plugin and you’ll waste time answering easy questions. But we only force them to have a readme at submission if they’re a service (that is they’re calling other servers). Screenshots aren’t always needed, but a good and descriptive readme would save everyone a lot of pain. Short of letting me actually chase after people with a baseball bat, I don’t know if we’ll ever get to a place where everyone’s doing that.

Unfortunately, the plugin review team cannot require better readme.txt files, but her advice would be good to take to heart if you are a plugin developer reading this. Don’t leave people in the dark about what your plugin does if you want anyone to use it.

Now that you know a little bit more about what the plugin review team has to contend with, aren’t you grateful for everything they do on WordPress.org? Many thanks to Mika Epstein and the rest of the team for their daily work on the WordPress Plugin Directory. Without them, the directory would be a wasteland, overrun with spam and security threats. Because of their dedication, WordPress.org remains one of the safest places to look for extensions.