WordPress.org

Ready to get started?Download WordPress

Plugin Directory

Detailed Plugin Guidelines

Since some developers need highly specific details as to what is and is not acceptable, we've developed this list of guidelines as to what is and is not allowed in the plugins repository. Note that this list is not complete and doesn't cover everything (see the last guideline). Still, it's here for the people who want clarification on key points. Most plugin authors probably don't need to read this wall-of-text.

  1. Your plugin must be compatible with the GNU General Public License v2, or any later version. We strongly recommend using the same license as WordPress — “GPLv2 or later.”

    Note: We really do mean this. All the code in the plugin must be compatible with GPLv2 or later, even if you did not write that code. Third-party libraries must also be compatible. Creative Commons licenses are not compatible and are not allowed. Double check your licensing before you start writing your plugin code.

  2. If you don’t specify a compatible license (such as in a license.txt file or referencing or declaring a license somewhere in the code or readme.txt file), what you check in is considered GPLv2 or later. By committing code to our repository at all, you accept this condition.

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

  4. No obfuscated code. We believe that obfuscated code violates the spirit, if not the letter, of the GPL license under which we operate. The GPL 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.

  5. 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. Similarly, you cannot "cripple" functionality in the plugin and then ask for payment or provide a code to unlock the functionality. All code hosted by WordPress.org servers must be free and fully-functional. If you want to sell advanced features for a plugin (such as a "pro" version), then you must sell and serve that code from your own site, we will not host it on our servers.

  6. "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 but 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.

    (Point of clarification: A "storefront" is not a "service". If your plugin merely acts as a front-end to allow its users to purchase product from your systems, then it will not be accepted into the repository.)

  7. No "phoning home" without user's informed consent. This seemingly simple rule actually covers several different aspects:

    • No unauthorized collection of user data. For example, sending the admin's email address back to your own servers without permission of the user is not allowed; but 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.

    • 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's admin screens or description. The point is that the user must be informed of what information is being sent where.

    • 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 advertising 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 of choice is fine. If the plugin does include advertising from a third party service, then it must default to completely disabled, in order to prevent tracking information from being collected from the user without their consent. This is the method commonly known as "opt-in".

    • Note that if you do include what we consider to be "advertising spam", or attempt to game somebody else's advertising system, then we will not only remove your plugin, but also report your code to the advertising system's abuse mechanism as well. We do not react kindly to spam. Don't try it.

  8. 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).

  9. The plugin must not do anything illegal, or be morally offensive. That's subjective, we know. Still, if we don't like it for any reason, it's gone. This includes spam, for whatever definition of spam we want to use.

  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 show the link.

  11. Plugins 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 (aka the readme.txt file) may not have "sponsored" links on it. Same goes for the translation files and any other linkback type schemes that will have content displayed on WordPress.org.

  13. The plugin page in the directory should include no more than 12 tags. Using the names of other plugins as tags should be carefully considered, since it could be construed as "gaming" the search engine.

  14. 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 or removal of the plugin from the directory.

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

  16. A complete plugin must be available at the time of submitting the plugin request to the repository, so that we may examine it prior to approval. It would be appreciated if this is linked to in the plugin description. We do not "reserve" names for future usage. Plugin names that are approved may be taken away if the plugin is not committed to the SVN in a reasonable amount of time.

  17. Don't violate our trademarks. Don't use "wordpress" in your domain name. Use "wp" instead, or better yet, come up with your own original branding! People remember names.

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