Detailed Plugin Guidelines

Alert: The guidelines are being currently reviewed and a new format is planned for later this summer (July 2016). Please pardon our dust.

As some developers require highly specific details as to what is and is not acceptable, we’ve created this list of guidelines as to what is and is not allowed in the plugins repository.

Violation of plugin guidelines may result in plugins or plugin data being removed from the repository until the issues are resolved. Plugin data, such as reviews, may not be restored, depending on the nature of the violation and the results of a peer-review of the situation. Repeat violations may result in all the author’s plugins being removed and them being banned from hosting plugins on WordPress.org. It is the responsibility of plugin authors to ensure their contact information on WordPress.org is up to date and accurate, in order that they receive all notifications from the plugins team.

Note that this list is not complete and doesn’t cover everything down to the last millimeter (see the last guideline). There is no list that could possibly address every possible permutation of the guidelines. The summary is considered to be ‘don’t do bad things’ and ‘respect everyone.’

If you are uncertain whether your plugin might violate the guidelines, please contact us at plugins@wordpress.org and ask.

  1. Your plugin must be compatible with the GNU General Public License v2, or any later version. We recommend using the same license as WordPress — “GPLv2 or later.”
    This rule applies to everything in the plugin, including code, data, and images, even if you did not create that particular piece. All third-party libraries must also be compatible. For a specific list of compatible licenses, please read the GPL-Compatible license list on gnu.org. Double check all licensing before you start writing your plugin.
  2. If you do not specify a compatible license, what you check in is considered GPLv2 or later. By committing code to our repository, you accept this condition. In the absence of your own license.txt file, referencing or declaring a license somewhere in the code comments, or within you readme.txt file, the plugin and all it’s components are considered GPLv2 (or later).
  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.
    This includes having your plugin serve updates from non WordPress.org servers and not having your plugin behave as a storefront. The point is to use our repository, not your own.
  4. No obfuscated code. Intentionally obfuscated code is not allowed in the repository under any circumstances.
    This is an ‘above and beyond’ GPL requirement for being hosted here. The intent of WordPress is for anyone to be able to learn from code and edit it and adapt it. By making code non-human readable, future developers face an unnecessary hurdle. In addition, many people use such methods to try and hide evil code.
    Some systems, like Paypal donation buttons, use encrypted 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 is permitted in the repository. “Serviceware” plugins are defined as plugins that merely act as an interface to some external third party service (eg. a video hosting site). These are allowed even for pay services, as long as the service itself is doing something of substance and clearly documented in the readme, preferably with a link to Terms of Use.
    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.
    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.
    • 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.
    • Attempts of “ad spamming”, or abusing the guidelines of an advertising system such as Google Ads (which does not permit ads on the WP Dashboard), will result in your plugin being removed and your actions reported to the advertising system.
  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. While this can be subjective, it includes what the plugin review team deems to be spam. This includes (but is not restricted to) the following examples:
    • Keyword stuffing or SEO scamming in the readme.
    • Compensating or blackmailing users for reviews.
    • Creating sockpuppet accounts to generate fake reviews.
    • Taking other developers’ plugins and presenting it as original work.
  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.
    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. Third party ad systems rarely permit their usage on admin-only screens (notably, Google Ads does not permit its usage there); if they do permit back-end ads, the quality will be low as those systems cannot see the page content to determine good ads.
    Putting links back to your own site or to your social-network of choice is fine. So are locally (within the plugin) hosted images that link to your other products.
  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. Affiliate links are to be avoided. If they are included on settings pages, they must be disclosed.
  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.
    NOTE: With the new version of the repository we will be enforcing this behavior and restricting your choice of tags.
  14. Frequent commits can be seen as gaming the Recently Updated lists. Please limit commits to prevent this.
    All commits should include a commit message describing the content of the commit, in reasonable detail. Frequent ‘trash’ commit messages like ‘update’ or ‘cleanup’ makes it hard for other developers and users to follow what is changing in the plugin. Commits that only tweak minor aspects of the readme cause undue strain on the system, as they require a plugin’s zips to be rebuilt, and should be avoided. Blank commit messages are not permitted by our system and are automatically rejected.
    Only commit code that is ready for deployment. Do not attempt to A/B test a readme in our system. Commit messages that are placeholders may be cause for 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 unless the readme is being updated with regards to supporting the newest version of WordPress.
    For more information on tagging, please read our SVN directions on tagging and how the readme.txt works to better understand this.
  16. A complete plugin must be available at the time of submitting the plugin request to the repository. All plugins are examined it prior to approval, which is why a link to a zip is required. We do not “reserve” names for future usage. Approved plugins may be taken away if the plugin is not committed to the SVN in a reasonable amount of time.
  17. Don’t violate trademarks. Remember the WordPress Foundation has trademarked the term “WordPress” and you cannot use “wordpress” in your domain name. We extend this policy to plugin slugs, and do not permit you to use ‘wordpress’ or any other trademarked term as your plugin slug unless you legally own/represent said term. You also may not use someone’s trademark or product name as the first term in your plugin name. To think of it simply, if you don’t work for Facebook, you cannot submit “Facebook Dancing Sloths” as a plugin (but you can submit “Dancing Sloths for Facebook”).
    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.