Detailed Plugin Guidelines

Tip: Last Updated: October 20, 2016

The goal of the WordPress Plugin Directory is to provide a safe place for all WordPress users – from the non-technical to the developer – to download plugins that are consistent with the goals of the WordPress project.

To that end, we want to ensure a simple and transparent process for developers to submit plugins for the directory. As part of our ongoing efforts to make the plugin directory inclusion process more transparent, we have created a list of developer guidelines. We strive to create a level playing field for all developers.

If you have suggestions to improve the documentation, or questions about it, please email us at and let us know.

Plugin Submissions Plugin Submissions

In order to submit a plugin, there are three steps:

  1. Register on with a valid, regularly checked email address. If you are submitting a plugin on behalf of a company, use an official company email for verification.
  2. Whitelist in your email client to ensure you receive email communications.
  3. Submit your plugin with a brief overview of what it does and a link to a complete, ready to go zip of the plugin.

Once a plugin is queued for review, we will review the plugin for any issues. Most of the issues can be avoided by following the guidelines below. If we do find issues, we will contact the developer(s), and work towards a resolution.

Top ↑

Developer Expectations Developer Expectations

Developers, all users with commit access, and all users who officially support a plugin are expected to abide by the Directory Guidelines. Violations may result in plugins or plugin data (for previously approved plugins) being removed from the directory until the issues are resolved. Plugin data, such as user 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 the developer being banned from hosting plugins on It is the responsibility of the plugin developer to ensure their contact information on is up to date and accurate, in order that they receive all notifications from the plugins team.

All code in the directory should be made as secure as possible. Security is the ultimate responsibility of the plugin developer, however the Plugin Directory enforces this to the best of our ability. Should a plugin be found to have security issues, it will be closed until the situation is resolved. In extreme cases, the plugin may be updated by the WordPress Security team and propagated for the safety of the general public.

While we attempt to account for as many relevant interpretations of the guidelines as possible, it is unreasonable to expect that every circumstance will be explicitly covered. If you are uncertain whether a plugin might violate the guidelines, please contact us at and ask.

Top ↑

The Guidelines The Guidelines

1. Plugins must be compatible with the GNU General Public License v2, or any later version, to be hosted on

Though any GPL-compatible license is acceptable, using the same license as WordPress — “GPLv2 or later” — is recommended. All code, data, and images — anything stored in the directory — must comply with the GPL (any version, two or later), regardless of their creator. Included third-party libraries must also be compatible. For a specific list of compatible licenses, please read the GPL-Compatible license list on

2. Plugin developers are responsible for the files they upload and services they utilize.

It is the sole responsibility of the plugin developer to ensure all files within their plugins comply with the guidelines. They are expected to confirm, before uploading to SVN, the licensing of all included files, from original source code to images and libraries. In addition, they must comply to the terms of use for all third party services and APIs utilized by their plugins. If there is no way to validate the licensing of a library or the terms of an API, then they cannot be included.

3. A stable version of your plugin must be available from its WordPress Plugin Directory page.

The only version of the plugin that distributes is the one in the directory. Though you may develop your code somewhere else, please remember that users will be downloading from the directory, not your development environment.

4. Keep your code (mostly) human readable.

Intentionally obscuring code by hiding it with techniques or systems similar to p,a,c,k,e,r‘s obfuscate feature, uglify’s mangle, or unclear naming conventions such as $z12sdf813d, is not permitted in the directory. Unfortunately, many people use such methods to try and hide malicious code, such as backdoors or tracking. In addition, WordPress code is intended for anyone to be able to learn from, edit, and adapt. Making code non-human readable forces future developers to face an unnecessary hurdle. Minified code may be used, however the unminified versions should be included whenever possible. We recommend following WordPress Core Coding Standards.

5. Trialware is not allowed in the directory.

Attempting to upsell the user on other products and features is acceptable within limits.

  • Upsell notifications should not be overly prominent or annoying.
  • Plugins may not contain functionality that is crippled or locked, only to be unlockable by payment or upgrade. Paid functionality must be part of an externally hosted service or a separate plugin, that is not hosted on
  • Plugins may not disable included functionality after a trial period or quota.

6. Software as a Service is permitted in the directory.

Plugins that act as an interface to some external third party service (e.g. a video hosting site) are allowed, even for paid services. The service itself must provide functionality of substance and be clearly documented in the readme file submitted with the plugin, preferably with a link to the service’s Terms of Use.

Services and functionality not allowed include:

  • A service that exists for the sole purpose of validating licenses or keys while all functional aspects of the plugin are included locally is not permitted.
  • Creation of a service by moving arbitrary code out of the plugin so that the service may falsely appear to provide supplemented functionality is prohibited.
  • Storefronts that are not services. A plugin that acts only as a front-end for products to be purchased from external systems will not be accepted.

7. The plugin may not “phone home” or track users without their informed, explicit, opt-in consent.

In the interest of protecting user privacy, plugins may not contact external servers without the explicit consent of the user via requiring registration with a service or an checkbox within the settings. This method is called ‘opt in.’ Documentation on how any user data is collected, and used, should be included in the plugin’s readme, preferably with a clearly stated privacy policy.

This restriction includes the following:

  • No unauthorized collection of user data. Users may be asked to submit information but it cannot be automatically recorded without explicit confirmation from the user.
  • Intentionally misleading users into submitting information as a requirement for use of the plugin itself is prohibited.
  • Images and scripts should be loaded locally as part of the plugin whenever possible. If external data (such as blocklists) is required, their inclusion must be made clear to the user.
  • Any third party advertisement mechanisms used within the plugin must have all tracking features disabled by default. Advertisement mechanisms which do not have the capability of disabling user tracking features are prohibited.

The sole exception to this policy is Software as a Service, such as Twitter, an Amazon CDN plugin, or Akismet. By installing, activating, registering, and configuring plugins that utilize those services, consent is granted for those systems.

8. The plugin may not send executable code via third-party systems.

Externally loading code from documented services is permitted, however all communication must be made as securely as possible. Executing outside code within a plugin when not acting as a service is not allowed, for example:

  • Serving updates or otherwise installing plugins, themes, or add-ons from servers other than’s
  • Installing premium versions of the same plugin
  • Calling third party CDNs for reasons other than font inclusions; all non-service related JavaScript and CSS must be included locally
  • Using third party services to manage regularly updated lists of data, when not explicitly permitted in the service’s terms of use
  • Using iframes to connect admin pages; APIs should be used to minimize security risks

9. The plugin and its developers must not do anything illegal, dishonest, or morally offensive.

While this is subjective and rather broad, the intent is to prevent plugins, developers, and companies from abusing the freedoms and rights of end users as well as other plugin developers.

This includes (but is not restricted to) the following examples:

  • Artificially manipulating search results via keyword stuffing, black hat SEO, or otherwise within the readme
  • Offering to drive more traffic to sites that use the plugin
  • Compensating, misleading, pressuring, extorting, or blackmailing users for reviews
  • Implying users must pay to unlock included features
  • Creating accounts to generate fake reviews or support tickets (i.e. sockpuppeting)
  • Falsifying personal information to intentionally disguise identities and avoid sanctions for previous infractions
  • Taking other developers’ plugins and presenting them as original work
  • Utilizing the user’s server or resources as part of a botnet
  • Intentionally attempting to exploit loopholes in the guidelines
  • Violations of the WordCamp code of conduct

10. The plugin must not embed external links or credits on the public site without explicitly asking the user’s permission.

All “Powered By” or credit displays and links included in the plugin code must be optional and default to not show on users’ front-facing websites. Users must opt-in to displaying any and all credits and links via clearly stated and understandable choices, not buried in the terms of use or documentation. Plugins may not require credit or links be displayed in order to function. Services are permitted to brand their output as they see fit, provided the code is handled in the service and not the plugin.

11. The plugin should not hijack the admin dashboard.

Users prefer and expect plugins to feel like part of WordPress. Constant nags and overwhelming the admin dashboard with unnecessary alerts detract from this experience.

Upgrade prompts, notices, and alerts should be limited in scope and used sparingly or only on the plugin’s setting page. Any site wide notices or embedded dashboard widgets must be dismissible. Error messages and alerts should include information on how to resolve the situation, and remove themselves when completed.

Advertising within the WordPress Dashboard should be avoided. While developers are permitted to promote their own products and services, historically they have been ineffective; ideally users rarely visit these screens. Remember: tracking referrals via those ads is not permitted (see guideline 7) and most third-party systems do not permit back-end advertisements (notably, Google). Abusing the guidelines of an advertising system will result in such actions being reported.

Developers are welcome and encouraged to include links to their own sites or social networks, as well as locally (within the plugin) including images to enhance that experience.

12. Public facing pages on may not contain “sponsored” or “affiliate” links or third party advertisements.

Public facing pages, including readmes and translation files, may not contain affiliate or sponsored links. Directly required products (such as themes or other plugins required for the plugin’s use), are permitted within moderation. Related links may be included on the WordPress Admin settings pages for the specific plugin. In all cases, affiliate links must be disclosed and must directly link to the affiliate service, not a redirect or cloaked URL.

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 to a plugin should be avoided.

The SVN repository is a release repository, not a development one. All commits will trigger a regeneration of the zip files associated with the plugin, so only code that is ready for deployment (be that a stable release, beta, or RC) should be pushed to SVN. Including a descriptive and informative message with each commit is strongly recommended. Frequent ‘trash’ commit messages like ‘update’ or ‘cleanup’ makes it hard for others to follow changes. Commits that only tweak minor aspects of the plugin (including the readme) cause undue strain on the system and can be seen as gaming Recently Updated lists.

15. The plugin version number must increment every time a new version is released.

Users will only be alerted to updates when the code version is incremented in SVN. Developers can deploy these updates either by incrementing the plugin version number in the readme.txt in the trunk branch or by creating a new tag branch with a readme.txt which has an incremented plugin version matching the branch directory name.

If a developer employs the tag directories approach to distribute the latest version of their plugin, the trunk folder can be continually updated without version number changes. The tag directories should generally not be updated past the initial tagging unless the readme.txt needs to be updated to support the release of a new version of WordPress.

For more information on tagging, please read our SVN directions on tagging and how the readme.txt works.

16. A complete plugin must be available at the time of submitting the plugin request to the directory.

All plugins are examined prior to approval, which is why a link to a zip is required. Names cannot be “reserved” for future use. Directory names for approved plugins that are not used within a reasonable amount of time may be given to other developers.

17. Respect trademarks and projects.

The use of trademarks or other projects as the sole or initial term of a plugin slug is prohibited unless proof of legal ownership/representation can be confirmed. For example, the WordPress Foundation has trademarked the term “WordPress” and it is a violation to use “wordpress” in a domain name. This policy extends to plugin slugs.

As another example, only employees of Facebook should use the slug “Facebook,” or their brand in a context such as “Facebook Dancing Sloths.” Non-employees should use a format such as “Dancing Sloths for Facebook” instead to avoid potentially misleading users into believing the plugin was developed by Facebook. Similarly, if you don’t represent the “Chart.js” project, it’s inappropriate to use that as the name of your plugin.

Original branding is recommended as it not only helps to avoid confusion, but is more memorable to the user.

18. We reserve the right to alter the Plugin Guidelines at any time with or without notice.

We reserve the right to update these guidelines at any time as we feel necessary.

We reserve the right to arbitrarily disable or remove any plugin from the directory for any reason whatsoever, even for reasons not explicitly covered by these guidelines. Our intent is to enforce these guidelines with as much fairness as humanly possible to ensure plugins’ quality and the safety of their users.