I’m not a super-psycho coder. But between being a busybody and being a volunteer plugin referee, I do spend a disproportionate amount of time looking at the code people put in for plugins, which means I actually see a lot more code, and a lot more submissions, than you might expect. This puts me in a place where I actually can offer some of the world’s most basic advice ever, that a surprising number of people seem to miss, about how to submit your plugins, what will get them downcheked, and what you really just shouldn’t do.

This list is not all encompassing, but touches on the issues I see the most often.

What You Must Do

Failing to do the following will likely end up in your plugin being yanked (or not approved at all).

Read The Guidelines

We are not pirates. These are not wishy-washy rules, though they are intentionally kept as light as possible. You see, the more you make a rule “You can’t do this!” then the more you get “Well, you said I couldn’t dig to China, not Australia!”(That’s a true story on my part. I once got my kindergarten school class to dig to China. After being told not to, I got them to dig to Australia. At this point, they said ‘No digging tunnels at school.’ My parents explained in more detail why this was dangerous, and we watched The Great Escape to understand tunnel collapse. I forget how Dad explained the distance, but I remember a long explanation about the earth’s core being molten, and no, you can’t dig under the ocean. I was bummed. I was also 4.) The basic guidelines are on the front page of the Developer Center, but it’s the expanded guidelines you really need to read. I helped write those guidelines (over beery emails with Otto) and he and I both hate that we have to spell certain things out, but apparently they’re unclear. Just read them. If you think you’re doing something that might be on the far side of okay, ask around. Tweet, post in the forums, or find a plugin dev you respect and ask them directly.

Check Licences

All plugins must be GPL2 (or later) compatible. This is pretty basic, but a lot of people don’t realize what that means. First, there’s the issue of GPL2 versus GPL3. While the WordPress repository accepts GPL3 plugins, it’s still not compatible with everything, so make sure the code you fold into the plugin will work with which ever license you chose. If you don’t want to use GPL, you don’t have to! Remember, there are a lot of GPL Compatible Licences. At the same time, there are a lot of incompatible licences as well. And there are the Non-free Software licenses. When you’re only releasing your own code, this is pretty easy. You pick a compatible license and move on. When you’re incorporating other people’s code, however you have to study their license carefully.

Generally I’ve seen people get dinged for using the Creative Commons license, and in most cases this is because they’re not using the CC0 license. That is the only CC license that really works with GPL (except for CC BY ND). Your code really shouldn’t be CC licensed, anyway, though. Just don’t use it.

Provide the code

When you submit your plugin, put in a link to the code so it can be downloaded and checked. (See Expanded Guidelines, Rule #16) If, for some reason, you can’t because the code is behind a paywall, or you don’t want it in the wild, don’t worry! The only people who see that link are the plugin review team, and they’re trustworthy. They don’t need an API key, either, they just want to make sure you’re not breaking the repo guidelines. If you don’t provide a link to the code, you don’t get in. It’s really that simple.

Don’t break the other WP rules

Did you know you can’t use ‘wordpress’ in your domain name without permission? If your author or plugin URL is http://mycoolwordpressplugins.com then your plugin will be rejected. (See Expanded Guidelines, Rule #17) In addition, you’re still going to be held subject to the forum rules with your account. I mention this because if you get blocked on the forums for rampant asshattery, you won’t be able to check new code in. Basically remember that it’s the internet, and we can see your behavior on Twitter, Forums, Faceybooky, etc. Don’t be an idiot.

What You Should Do

Not doing the following won’t get you punted from the repo, but they’re still good to do, in order to provide the best support possible.

Write a good readme

A good readme file is going to tell the person everything they need to know before they download the plugin. This means:

1. Describe what the plugin does
2. Explicitly state any and all requirements
3. Be upfront about any external accounts required (for APIs or what have you)
4. Inform users if their information is being sent to another site, where, and why (not necessarily technical explanations, just ‘Your IP, browser specs, etc will be sent to Google for Analytics purposes. This is required if you want to use Google Analytics.’)
5. Include screenshots of the options
6. Include a screenshot of what the plugin looks like on the unmodified default theme
7. Document if no support is provided (or if support is handled somewhere other than the WordPress forums)

Credit Appropriately

A subset of that is that if your plugin is a fork of someone else’s, be the good person and credit them! It’s not required all the time, but take a look at the copyright information on a plugin. Sometimes they say they require credit in the code. If so, you’ve got to do it. Even just a line that says “Copyright 2009-2011 Some Other Dude” and then “Copyright 2011 Me” below it. That’s a nice CYA. If you want to be really nice, put their userID under ‘contributors’ in the readme file, and they’ll have their pretty face on your plugin.

Write Good Code

Using good code is complicated. I don’t pretend to be the best at it myself (seriously, the level of shenanigans I went through over nonces cannot be measured on a human scale). But I know that good code is secure code. I know I should use nonces in certain situations, I know to protect against SQL injections, and I know to not let total strangers upload executable files (so they can’t upload a PHP file that wipes my DB, for example). And I know when to go find Otto, WePay him a beer, and say “So what the hell did I do wrong, here?”

Writing good code is exceptionally complicated, which is why, if you’re going to write a large plugin, you need to know what you’re getting into. The problem a lot of people get into is the classic ‘Your eyes are bigger than your stomach.’ When you write a plugin, keep it simple. Start with the code you know, slowly fold in the new stuff. Try to test as many different ways as you can think of, but know that you’re going to miss something.

What To Do If Your Plugin Is Yanked?

Every plugin developer’s worst nightmare is waking up to find that their plugin was yanked from the WordPress repository.

Don’t panic!

This happens when your plugin has been reported as possibly being in conflict with the developer guidelines, or it has a security hole. Many times you will not be notified when this happens. Sometimes you’re not notified because the report is found to be incorrect, and sometimes it’s because you’ve been warned before. And, once in a while, it’s because the person who closed your plugin doesn’t have the ability to email you. Surprise! There are some people on the plugin repository team who don’t have the access to the plugins email system, so when they close your plugin, they’ll ask someone else to email you. If that person is busy, it might take a while.

When a plugin is closed, the rest of your plugins are usually checked over to make sure they’re not also having an issue. For example, if you have one plugin with a front facing link that’s turned on by default, all your plugins will be checked for that and, if they all have the same problem, they will all be yanked. This is why you need to keep up to date on the plugin guidelines, and follow the WordPress Development Blog.

As soon as you find out your plugin is closed, email plugins@wordpress.org and ask what you can do to restore it. Posting in the forums won’t help much.