Lately I’ve had some back and forth with the WordPress members that “oversee” the plugin repository. At the moment I am slightly annoyed at the way they go about “managing” the repository but I’ll leave that for another post.

After some back and forth I was finally able to get the Plugin Guidelines that they use for determining if a plugin is qualified for the repository. In the hopes that other plugin developers don’t go through what I experienced I’m including it below. These Guidelines are as-is and as-of August 10th, 2011 the date I received them.

1. Your plugin must be GPLv2 Compatible. GPLv3-only is not allowed because it is incompatible with the GPLv2 and with WordPress itself. A “GPLv2 or later” license is acceptable, as this gives users the freedom to choose the GPLv3 if they want.

2. If you don’t specify a GPLv2-compatible license, then what you check will be considered to explicitly be GPLv2 code. By committing code to our repository at all, you accept this condition.

3. No obfuscated code. We believe that obfuscated code violates the spirit, if not the letter, of the GPL license under which we operate. The GPLv2 specifically states “The source code for a work means the preferred form of the work for making modifications to it.” Intentionally obfuscated code is not the preferred form, and not allowed in the repository under any circumstances. However, note that some systems, like Paypal donation buttons, use encoded code as part of their normal operating mechanism. This is not considered to be “obfuscated” as this is simply how these types of systems operate and it is not a choice by the plugin author. These types of things are acceptable, but may result in the author being questioned about it for edge cases. If a non-encoded method for such services is available, use it.

4. Trialware is not allowed in the repository. It’s perfectly fine to attempt to upsell the user on other products and features, but a) not in an annoying manner and b) not by disabling functionality after some time period.

5. Serviceware plugins are defined as plugins that merely act as an interface to some external third party service (eg. a video hosting site). Serviceware plugins ARE allowed in the repository, as long as the code in the plugin meets all other conditions. These are allowed even for pay services, as long as the service itself is doing something of substance. Creation of a “service” which does nothing put to provide keys or licenses or anything similar for the plugin, while the plugin does all the actual work, is prohibited. Moving arbitrary code into the service so that it can appear to do some work is also prohibited. This will be handled on a case by case basis and our judgment on any given case is final.

6. No “phoning home” without user’s informed consent.

a. No unauthorized collection of user data. For example, sending the admin’s email address back to your own servers without permission of user is not allowed. Asking the user for an email address and collecting if they choose to submit it is fine. All actions taken in this respect MUST be of the user’s doing, not automatically done by the plugin.

b. All images and scripts shown should be part of the plugin. These should be loaded locally. If the plugin does require that data is loaded from an external site (such as blocklists) this should be made clear in the plugin admin.

c. In general, things like banner or text link advertising should not be anywhere in a plugin, including on its settings screen. Advertising on settings screens is generally ineffective anyway, as ideally users rarely visit these screens, and the advertising is low quality because the ad-systems cannot see the page content to determine good ads. So they’re best just left off entirely. Putting links back to your own site or to your social-network-system of choice is fine. Furthermore, if the plugin does include advertising from a third party service, it must default to completely disabled, in order to prevent tracking information from being collected from the user without their consent.

7. No sending executable code via third-party systems. Use of third-party systems is acceptable in a service-client type of model, but sending actual PHP or other executable code over the network is considered a security risk. Executing outside code like this is not allowed except for specific and very carefully considered cases (such as during upgrades, for example).

8. The plugin most not do anything illegal, or be morally offensive. That’s subjective, we know. Tough. If we don’t like it for any reason, it’s gone. This includes spam, for whatever definition of spam we want to use.

9. You have to actually use the subversion repository we give you in order for your plugin to show up on this site. The WordPress Plugins Directory is a hosting site, not a listing site.

10. The plugin must not embed external links on the public site (like a “powered by” link) without explicitly asking the user’s permission. Any such options in the plugin must default to not showing the credit/link.

11. Plugin should not hijack the blog admin. It is fine to include an Upgrade prompt on the plugin admin page but not throughout the blog. It is acceptable to embed a widget on the dashboard but this should be the same size as others and be dismissable. It’s fine to put an error message at the top of the admin for special cases, but it should be linked to a way to fix the error and it should be infrequent. Any form of “nagging” is absolutely prohibited.

12. The plugin page in the directory should include no more than 12 tags. No sponsored links are permitted there. Using the names of other plugins as tags should be carefully considered.

13. Frequent commits can be seen as gaming the Recently Updated lists. Try to limit commits to prevent this. All commits should include a commit message describing the content of the commit, in reasonable detail. Frequent blank commit messages makes it hard for other developers and users to follow what is changing in the plugin. Blank commit messages may also be cause for rejection of the commit.

14. All code changes to a plugin that has a Stable Tag of “trunk” must result in the version number being upgraded. For the trunk and tags method, trunk can be continually updated without version number changes, while tags should generally not be updated ever past the initial tagging.

15. A complete plugin must be available at the time of submission. It would be appreciated if this is linked to in the plugin description.

16. We reserve the right to alter this list in the future. We reserve the right to arbitrarily disable or remove any plugin for any reason whatsoever. Basically, this is our repository, and we will attempt to maintain a standard of conduct and code quality. We may not always succeed, but that is our goal, and we will do whatever we feel is necessary in furtherance of that goal.

In my opinion there are some questionable items in the list, myself I fell afoul of #6 as I wanted to have actual statistics on usage of my plugin, which is something that WordPress itself does so still not sure why it is present in the guidelines for a no-no with plugins.