Detailed Plugin Guidelines
Tip: Last Updated: January 30, 2017
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
email@example.com and let us know.
Plugin Submissions #Plugin Submissions
In order to submit a plugin, there are three steps:
- Register on WordPress.org 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.
firstname.lastname@example.org your email client to ensure you receive email communications.
- 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.
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 WordPress.org. It is the responsibility of the plugin developer 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.
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
email@example.com and ask.
The Guidelines #The Guidelines
1. Plugins must be compatible with the GNU General Public License v2, or any later version, to be hosted on WordPress.org.
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 gnu.org.
2. Plugin developers are responsible for the files they upload and services they utilize.
3. A stable version of your plugin must be available from its WordPress Plugin Directory page.
The only version of the plugin that WordPress.org 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 wordpress.org.
- Plugins may not disable included functionality after a trial period or quota.
6. Software as a Service is permitted in the directory.
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.
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 WordPress.org’s
- Installing premium versions of the same plugin
- 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.
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 WordPress.org (readmes) may not spam.
Public facing pages, including readmes and translation files, may not be used to spam. Spammy behavior includes (but is not limited to) unnecessary affiliate links, tags to competitors plugins, use of over 12 tags total, blackhat SEO, and keyword stuffing.
Links to directly required products, such as themes or other plugins required for the plugin’s use, are permitted within moderation. Similarly, related products may be used in tags but not competitors. If a plugin is a WooCommerce extension, it may use the tag ‘woocommerce.’ However if the plugin is an alternative to Akismet, it may not use that term as a tag. Repetitive use of a tag or specific term is considered to be keyword stuffing, and is not permitted.
Write your readmes for people, not bots.
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 should make use of WordPress’ default libraries.
WordPress includes a number of useful libraries, such as jQuery, Atom Lib, SimplePie, PHPMailer, PHPass, and more. For security and stability reasons, plugins may not include those libraries in their own code, but instead must use the versions of those libraries packaged with WordPress.
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.
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.