There are a lot of plugins on (more than 30,000) and there are a huge number of new plugins submitted to the repository every single week. What you may not know is that there are only two people that review the vast majority of the plugin submissions each week: myself and Mika Ipstenu (she does far more than me). That means the review queue gets really back logged anytime one or both of us is traveling, busy with work, or simply unable to make it through the review queue for one reason or another.

Mika and I see a lot of plugins come through the review queue, so naturally we see a lot of trends with plugins that get approved, rejected, or held back. Tonight, for example, I reviewed a list of about 30 plugins. Of those 30, 15 or so got approved, 2 got rejected, and the rest got “soft” rejected (meaning there was a small modification or improvement needed). Of the 13 that were soft rejected, 10 were given the exact same reason.

Tonight’s review queue was very typical, in terms of the number that were approved, rejected, and soft rejected, and also the reasons for each plugin’s review status.

While it is purely an estimation, I’d speculate that 9 out of every 10 plugins that is soft rejected never gets approved.

I’d like to go over a few tips on how you can improve the chances of your plugin getting approved on the first try.

1. Always prefix your functions and class declarations

The single most common reason for a plugin to get soft rejected is non-unique function or class names. For example, we see this every single day:

function my_plugin_settings() {
	// Register a setting here
add_action( 'admin_init', 'my_plugin_settings' );

This is usually due to the plugin’s author copying and pasting some code from a tutorial that explained how to store options for a plugin.

Tip: your plugin should never have a prefix of my_.

Instead of “my_” for the prefix, use a unique prefix that is specific to your plugin. For example, if your plugin’s name is “Easy Content Types”, use a prefix of “ect_”.

If your plugin contains non-unique function or class declarations, we will send you an email asking to you update it.

2. Always send a zip file of your plugin

This is a simple one but we do see submissions without valid plugin files every week. Always ensure you have uploaded a proper zip file of your complete plugin that we can review.

Believe it or not, but we do review every single line of every plugin that is submitted to the repository. If we can’t see your code, we can’t approve your plugin.

3. Do not obfuscate your code

Plugin developers sometimes choose to obfuscate their plugin’s source as an attempt to better protect their work from copyright infringement and to make it more difficult for someone to copy the code.

We do not permit any obfuscated code on, so if you intend to obfuscate or encrypt your code in any way, do not worry about submitting it to because we cannot accept it.

4. Do not call home without permission

“Calling home” refers to the practice of sending data from the site a plugin is installed on back to your own servers. Many developers do this in order to better understand the kinds of sites their plugins are installed on, or as a way to maintain a list of sites that are using the plugin.

Most developers do this for legitimate, well-meaning reasons, but some developers do this with malicious intent.

Regardless of the intent, calling home from your plugin is only permitted if the user of your plugin explicitly gives you permission to do so. Again, the user must give you permission. Providing an option to disable call home does not suffice; it must be turned off by default.

5. Do not load your own jQuery

Plugins should never load their own versions of jQuery or any other script that is included in WordPress core.

When plugins are submitted that load their own versions of jQuery, or load it from any external CDN, we will soft reject it, every single time.

6. Include a good ReadMe.txt file

The readme.txt file is the file that controls the display of the plugin’s page on While it’s not a hard requirement for the plugin to be accepted, it is very, very important for your plugin to have a valid readme.txt file. You can see a standard readme.txt file here, and you can validate your readme.txt file here.

If you don’t include a readme.txt file with your plugin, we will ask you to create one before we approve your plugin and this will only slow down the approval process.

These are by no means the only things you should do to ensure your plugin is accepted on the first try, but following these six tips will dramatically improve the likelihood that your plugin is approved quickly.

  1. Mike

    Hi Pippin
    I posted a question on support about a plugin that stored all data on the developer’s site and the developer was completely anonymous – no data available on the developer site nor in the DNS registrar. This doesn’t seem appropriate to me.

    Those who use this plugin have no idea who owns their data. There is 0% transparency and no warning about this.

    If the developer refuses to reveal his/her/their identity, I think the plugin should be removed ASAP.

    • Mike

      PS: I asked the developer via twitter and the answer received was that they were in NYC. The tweet appears to have been subsequently deleted.

    • Pippin

      Do you mean the plugin is taking data from the site it is activated on and sending it back to the developer’s site?

    • Mike

      As far as I understand, the plugin takes all the data. None of it is stored on the user’s site. It’s a hosted service.

    • Pippin

      I just read over your post here:

      Revealing your identity as a developer is not a requirement for plugins to be hosted on If a developer or company chooses to remain anonymous, that is their decision. It is also your decision, and the decision of each user that chooses to use the plugin, whether to trust an anonymous developer.

      In this case, I don’t see this plugin as being any different (from a anonymous-not-anonymous perspective) than any other company. Company names are often known while the people behind a company are not personally named. Right or wrong, it is in now way against regulations.

    • Pippin

      Hosted services are perfectly acceptable.

    • Mike

      IMHO, anonymous && hosted = unacceptable.
      Common sense.
      At a minimum, there should be a warning.
      If you think about it, you’ll figure out why.
      And I’ve never seen this before in the repository.
      Maybe you know another example?

    • Pippin

      Does that mean that every single thing built by companies like Facebook, Twitter, Apple etc should reveal the names of the individuals that worked on a project or product? No, it is branded as the company, not the individuals.

    • Mike

      With all do respect, that makes no sense. These are all public companies and by definition are very reachable. That is way beyond the criteria I think is necessary. is run by an unknown person or people at an unknown location and they are taking 100% of the user’s data. We have no idea where the money comes from to finance the company since they are not charging for the services.

      If it was a plugin adding local functionality, not phoning home – anonymity is the developer’s prerogative. Even if the developer has a premium add-on but is not taking any data from the site (apart from the financial transaction process) it is still the developer’s prerogative.

      But is very different then this.

    • Pippin

      There’s a difference between plugins that “phone home” to report data and plugins that tie into a service in order to leverage the service’s features.

      For example, take any plugin that connects your site to Facebook or Twitter. Those plugins tie into the services offered by those companies in order to post to the social networks.

      This live blogging tool is exactly the same. It ties into the service in order to provide the live blogging features.

      Like the service or not, their plugin is doing nothing wrong. We audit the code the service installs on your site and the data the code reports, not what the service does with the data that gets sent to the service or who operates the service.

      Personally, I hate anonymity but it is not for me to tell someone they must or must not show their face.

    • Mike

      How do we know is not evil and harvesting personal details in order to perpetrate something horrible? What is the other reason for all this super secrecy?
      And if I am correct and something horrible happens and it is connected with the wp repository, the finger will be pointed at the managers of the repository. And the obvious question will be asked by the FBI, ” why was a plugin permitted that collects personal data when you have no idea who the collectors are? Didn’t a bell ring in your head that this isn’t a good idea? 16 tweets and an anonymous domain?
      If the rules permit this plugin on the repository, the rules should be changed ASAP.

    • Pippin

      We are all entitled to our own opinions and we all get to make our own decisions for who to trust. Clearly you don’t trust this company, and that is fine. It is up to you whether to use their service or not.

    • Chris Christoff

      Think about going to a school PTA potluck dinner. Everyone brings food for it. Does every person have to put their name and address in front of what they made? No. But what if ten people bring chocolate pie and what if someone dies from eating the chocolate pie because they have the rare condition canteatchocolatepieinitus? The finger will be pointed at the PTA managers. And the obvious question that will be asked by the FBI “why wasn’t each piece of food labeled with who made it and their address?”.

      Same exact deal.

      There’s alot of good reasons some plugin authors don’t associate themselves with their plugins. Maybe they are building a brand. For example, all my plugins are lableled with “chriscct7”. None of them say my name, they all say “chriscct7”.

      At the end of the day if you don’t trust, then don’t install their plugin or use their service. Simple as that. No one is forcing you to do it.

    • Mike

      LOL Chris. Something similar happened to me at my university and the professor responsible got in trouble.
      But you are also missing my point, which I thought I made very clear, that as this plugin is actually a means for hosting ones data on the site there should be different criteria for the developer identity than if the user is in control of the data.

    • Chris Christoff

      There’s many good reasons that plugin authors don’t often reveal the identities of those who actually store the data. For starters, not all plugin authors actually work for that company their plugin connects them to. Think about MailChimp. There’s a million MailChimp plugins on the repository. All of the ones that aren’t made by MailChimp simply integrate your site with MailChimps service. They send data, in this case emails, from your site to MailChimps servers, because thats how the service operates (it needs the emails). The developers of these third party plugins often don’t ever even know anyone at MailChimp. They just read the developer api documentation for MailChimp and they integrate the two. Thats just one example of why they don’t identify the people behind the service (maybe they never met that person). The companies themselves are not required to list that data either. There’s no law saying a company has to list all of their team members on their site. There’s no law saying a company has to use Twitter. If you go to 99% of all websites on the Internet, the company behind them doesn’t list any or all of their employees.

      If you look at Facebook, they don’t use Twitter. There’s no listing of their staff, other then whats directly required (list of officers) on a the corporate investing subsite since the SEC requires that in the form of a law. Does that mean Facebook plugins shouldn’t be allowed on No.

      WordPress is a community build around freedoms. You have the freedom to share, distribute, modify, or do whatever you want with its code, the code of its themes, or (depending on who you ask) plugins. WordPress gives people the freedom to people in Russia and Iran and China a way to voice their opinions, free from whats politically acceptable. In the same way we don’t require WordPress users to post who they are and their address on their WordPress site, we don’t require every single service that integrates with WordPress (millions of them) to identify who they are and what they do.

      Like Pippin said, if you don’t trust their company, you don’t have to use it.

    • Mike

      You both are doing a great job making my point by bringing up examples such as Facebook, Twitter and even MailChimp, all of which have publicly available contact information, unlike which offers nothing, nada, zilch.
      if a developer connects a user to these services and remains anonymous, who cares? Users still know where their data is.

      But if a user installs the wp plugin from the Pippin/Ipstenu approved WP repository and starts using the service, he/she have NO IDEA who is storing the data, where the data is, who is sponsoring the service.
      It is easy to parse the difference! I don’t understand why you are not getting this!

    • Chris Christoff

      That’s not the point of the repo though. The repo doesn’t care whether or not there’s contact information. The repo doesn’t care how the service stores the data (so long as it meets the repo’s requirements). It’s up to users to determine what services are safe for them to use. Some users would argue Facebook stores their data in a way they don’t like. Others have no problems with it. The repository’s job is just to allow services the opportunity to create plugins that integrate sites with the service, not to make a judgement of the service based on lack of contact information or other identifiable information. Developers, and the services they are integrating with are allowed to remain anonymous. Its up to users to decide whether to trust an anonymous developer.

      Again, if you don’t like the fact there’s no publically available contact information, that’s fine. Don’t use them. The plugin is still going to be allowed to remain in the repo for those who wish to use that integration.

    • Mike

      My point is the policy should be changed.
      At a minimum there should be a warning if there is 100% anonymity ALONG WITH 100% data hosting.
      Hopefully you will consider my suggestion seriously before it’s too late.

  2. James

    This is a great write up and I just want to say thank you to you and Mika for being incredible assets to this community! I appreciate the hard work you guys put in and how much you guys give back to the community.

  3. Rick Boatright

    Thanks for this. I’ve encountered a slightly different problem in re (1) where I have multiple plugin authors who are using the same — non wordpress — library.

    The most recent one was a second plugin (not yours) that used stripe’s payment gateway that conflicted with the already-installed payment gateway of RCP.

    That was a few hours of frantic patching when the plugin author was out-of-town. :-)

  4. Pete

    I agree 100% with Mike… if a plugin is sending away data from a website it must satisfy certain (extra) criteria. Telling us to choose to use the plugin at our own peril is a bit naive as there’s LOTS of users like me who know nothing about plugins other than a pretty screenshot, a cool name and a groovy description. We all get on to planes at our own risk but there’s a also a high level of security that we rely on (and expect).

    • Pippin


      It’s not nearly as much about trusting the plugin as it is trusting the service that is being used by the plugin. For example, anyone that uses a Facebook plugin is trusting Facebook with the data the plugin sends to Facebook.

    • Pete

      I agree, my assumption (in my above comment) was the plugin was sending website data to it’s own servers. That being said you have to admit a trusted/verified/accountable company makes for a trusted/verified/accountable plugin which makes for a trusted/verified/accountable use of a users data in any context. So therefore… my first comment still applies?

    • Pippin

      “it’s own servers” applies to any plugin that sends data offsite, whether it be from major companies like Facebook or Twitter to little companies that no one has heard of.

      It’s the same scenario in both: since the data is going off site (with the user’s permission), it is up to the user to decide whether to trust how that data is handled.

      Facebook, as an example, is easier to trust simply because everyone knows who they are. That does not, however, give Facebook anymore right to providing a service in the repository than anyone else, regardless of size.

      When we (the plugins review team), decides to approve or reject a service plugin, we do look into the service to try and determine it’s trustworthiness. If we deem the service untrustworthy out of the box, we do not approve the plugin. In order to decide a service is untrustworthy, however, we need to have some evidence to that.

  5. Pete

    I think my previous post disappeared?

    “we do look into the service to try and determine it’s trustworthiness”

    Awesome, can you tell us how you specifically do that?

    • Mike

      The policy should be simple, if the data phones home the user should be able to phone that home too. All the company examples here used to argue against my point in fact enabled this, but the original company I brought up doesn’t. They are a 100% unverifiable entity hosting all the data generated by the plugin. Not good at all. This a binary issue. No nuances.

    • Pippin

      We look at the service as best we can. Usually this means looking at their website, looking at the plugin code, and making the best judgement we can based on the information provided.

    • Pippin

      Could you clarify what you mean by this? “if the data phones home the user should be able to phone that home too”

    • Pete

      I think Mike means where ever the data goes there is a way we can contact whoever sees that data.

    • Mike

      Yes. Simply that if data goes from ones site to another by the plugin, one should know who that is. For Facebook, Twitter, and a whole slew of other plugins – in fact every other plugin in this situation except the one I mentioned – the data host is identified somehow. You may not be able to literarily phone Facebook, but I think my point is understood. With this plugin the destination and owner of a user’s data is unknown – completely.

    • Pippin

      The company in question has one:

      There are other methods to find their info as well. The only thing they do not have is a public list of who is part of the company, which is in no way a requirement (nor do I believe it should be).

    • Mike

      A contact form, web site, and twitter account. Circular anonymity.

    • Pippin

      The best I can do is tell you to contact them and ask them to put up that information.

    • Mike

      Pippin, with all due respect, I have given YOU that respect. I would never have bitched and moaned and wasted your time like this without making a “Joe College” attempt to contact them.

      I tweeted them and they responded they were located “somewhere in Soho” if my memory serves me correctly and then they deleted the tweet and didn’t respond to my followup question.

    • Pete

      “The best I can do is tell you to contact them and ask them to put up that information.”

      Don’t take this the wrong way but i think you’ve answered our concerns. If that’s the best WP does in it’s plugin security for data collection then I reckon it’s reasonable to for all us to agree that there is a potential problem with data usage. Could it be something you could bring up with your boss?

    • Pippin

      First, I don’t work for, nor does anyone else that is involved with the plugin review team. We are all volunteers are not compensated for our time in any form whatsoever.

      I do not have a boss to raise this issue with. I can, however, raise it with the other members of the plugin review team to see what they think about adjusting the guidelines.

      I will be honest and tell you that I do not agree with your concerns, but that does not make your concerns invalid. It simply means I do not feel the same way.

      To try and appease your worries, however, I will raise this internally to see what the other members of the review team think.

    • Pete

      Pippin, you do work for WP, you just don’t get paid. By your boss, yes I mean the review team.

    • Mike

      Pippin, Thanks. Much appreciated. Please stress that the concern is based on complete 100% circular anonymity. This is not a covert assault on companies trying to profit from WordPress.

  6. Pete

    By contact I mean… able to serve a court summons type of contact :)

    • Otto

      The 24liveblog people have a big contact-us box at the bottom of their plugin page, with Email, Twitter, and Facebook links.

      I don’t think that just the fact that somebody creates a service should also require them to actually give out their name and home address or anything similar. It’s not about being “anonymous”, it’s about what information you have a right to as well. I made the service, does the fact that I did such entitle anybody to get my mailing address or real name?

      If you don’t trust some web service, then you can simply not use them. Who to trust is a choice every individual must make for themselves. We do not have to police it for you.

      And frankly, the “court summons” thing is silly, at best. If there was an actual court case, then the fact that they’re called “24liveplus Inc.” and are in New York is plenty to look them up for any court. Incorporated entities are registered.

      There’s nothing wrong with that plugin, and it will not be removed for these concerns. If you find something actually morally objectionable about the plugin’s code itself or the behavior of the service, then by all means, let us know. But the fact that “it’s a service” and “I can’t find their real names” is not a valid objection.

    • Mike

      Otto, can you prove they are not an outlet of Boko Harem harvesting personal details from user data collected on their servers with intent to harm? If not, then this plugin shouldn’t be in the repository.

      There contact info is circular so in fact there is no contact data.

      I would say that if you want to place a plugin in the repository with the purpose of harvesting user data on your server, yes absolutely you should be forced to reveal some data about yourself. That seems like more than common sense to me. It can be corporate data as in the case of Mail Chimp or just a verifiable name, but something.

    • Otto

      @Mike: Why do you keep characterizing “signing up for a service” as “harvesting personal data”? If you have to actually sign up to use their service and give them the data in question, then it’s hardly “harvesting”.

      If you don’t want them to have your data, then don’t give it to them. I realize that this is an amazing concept in privacy that is new to most people, but it is shockingly effective.

      They run a web based service. You have to sign up on their site to use their service in the first place. The plugin just sticks a bit of a javascript widget on your page. It doesn’t “harvest” anything, nor does it send them any information from your server.

      See, I’ve actually read the code of the plugin, examined how it operates, and come to a decision based on that information. That’s what we do in the plugin review team, we review things. And in my opinion, based on my review, there’s nothing wrong with the plugin. If you have an issue with their service, then I suggest perhaps not using it.

    • Pete

      I didn’t realise that you had to go to there website to use the plugin first I thought the plugin provided the service by signing you up within the plugin itself. If I have to sign up externally then I agree WP shouldn’t have to check it out, but if it’s within the plugin then yes.

    • Otto

      Pete: The plugin’s admin screen essentially shows in an iframe. The first thing it shows there is a login screen that is clearly part of their service.

      So while yes, that interface portion is in an iframe on your site and you can sign up through that, it’s also really obvious that you’re signing up an account on an external service.

    • Mike

      @otto I don’t actually remember characterising signing up for the site that way. I am accusing the whole purpose of the site is to harvest personal data.

      Let’s review:
      1. The site is in an iframe meaning one’s WP installation is a proxy gateway to somewhere else.
      2. The site is about inviting colleagues and friends to live blog about whatever.
      3. All the live blogged data is stored on Boko Haram’s servers.
      4. All the contacts provided are circular – twitter->site->Facebook->twitter etc.
      5. There is no data in the DNS registrar

      Basically Boko Haram is using as a front to market their data harvesting intentions. Can you prove I am wrong?
      At a minimum there should be a warning on the plugin page.

    • Otto

      Why do you keep referring to “Boko Harem”? What does that have to do with anything at all? And who is “Boko Harem”? If you’re talking about the Nigerian terrorist group, then for starters, you’re spelling it wrong.

      Basically, you’re talking nonsense without any proof to back it up. Feel free to not use the service if you have a problem with it. But let other people make their own decisions. I can find nothing wrong with the plugin or the service, and nothing you have said here is in any way compelling me to think otherwise.

    • Mike

      Apart from my spelling mistake, what nonsense?
      Nothing I wrote is inaccurate.
      You have no idea who is behind this plugin and the plugin is storing 100% of the data created with it on its servers.
      The debate is not about me.
      It’s about whether it’s a appropriate for to facilitate this.
      The only argument for this is that users should know.
      I think that’s wrong and since the plugin is for users to create communications with their communities, I don’t see how these communities would/should be expected to know.
      Insulting me only weakens your argument.

    • Otto

      Mike, so, your argument is that because you don’t know something, you assume the worst possible scenario, without evidence.

      That’s a point of view that you’re free to hold, certainly. But it’s not everybody’s point of view. And I believe that people can make their own decisions based on the available data. If they don’t trust it, then they won’t use it, or will use it only in a limited capacity.

      Unless you can show me actual evidence that the plugin or service is behaving in an evil manner or doing evil things, then I will not make the assumption that it is. The fact that you don’t like the forms of contact information that are available is your problem, but not ours. We’re satisfied with a functional email address for our own needs to contact plugin authors.

      > You have no idea who is behind this plugin and the plugin is storing 100% of the data created with it on its servers.

      This is true. The difference between me and you is that I don’t actually care who is behind the plugin or the service. I only care about what it does, and what you can prove that it’s doing. Without some evidence of an actual violation, we will not remove a plugin based on your opinions about contact information.

      Show me that they’re evil. Then you’ll have something worth pointing out.

  7. adrian gray

    Does JavaScript minification count as obfuscation? I’m almost ready to submit a plugin to .org and I’ve written a fair bit of it in CoffeeScript. Best practice is to minify the CoffeeScript on building JS, which I do. But I’m unsure whether this is seen as an attempt to obfuscate the code?

    I can always include the CS source in the plugin, but this would add the the size, and the source to parse when WP loads plugins, so I’m not sure if this is a good idea…

    Any suggestions on best practice here?

    • Pippin

      No, minification is just fine.

  8. David Neal

    Hey Pippin,

    I didn’t know you were involved in the plugin review process, you do seem to crop up everywhere!

    I’ve just submitted my next plugin for review, pretty sure it ticks all the boxes but came here while looking for tips just to be sure.



    P.S. been a while since I was here, new site is looking nice!

Error: Please enter a valid email address

Error: Invalid email

Error: Please enter your first name

Error: Please enter your last name

Error: Please enter a username

Error: Please enter a password

Error: Please confirm your password

Error: Password and password confirmation do not match