Plugin Directory Guidelines

The ClassicPress Plugin Directory is intended to be a safe, one-stop source for all ClassicPress compatible plugins for all types of user, from a non-technical end-user to a developer.

The following rules are intended to provide transparency around the plugin submission process for developers who submit their plugins to the directory; the rules also aim to provide consistency and a level playing field for all developers.

If you have suggestions on improving the rules, or questions about them, please contact the plugin moderators at [email protected]

  1. All developers, users with commit access, and all those who officially support a plugin, are expected to follow the ClassicPress Plugin Directory Rules.
  2. All developers will ensure their contact information is accurate and up-to-date.
  3. Developers must take a security-first approach to their plugins and ensure their plugins are as secure as possible.
  4. Plugins may not contact external servers without explicit and authorized opt-in consent from the user. Documentation on how user data is collected and used must be included in the plugin’s readme along with a clearly stated privacy policy.
    • Integration with update servers which allow plugins to update to new versions (such as Update Manager) is not included in this rule, but update services must not collect identifiable data.
    • Plugins designed to integrate with third party services, such as Twitter or SMTP, must be clear in the readme file that this is their primary function. If this condition is met then the user will be deemed to have given explicit authorization.
  5. Free/Freemium/Premium plugins are all welcome in the ClassicPress Plugin Directory, but must be clearly identified as such in the description. Software-as-a-Service must be categorized as a Premium plugin. In this context:
    • Free means completely free, un-crippled, and not soliciting upsells in any way.
    • Freemium means some functionality is free, but some functions require payment to the plugin developer.
    • Premium means paid, with no functionality available otherwise.
  6. Trialware is not permitted in the directory; any plugin submitted to the directory must be functional when installed and not stop working; plugins using SaaS which stops functioning when a subscription ends is not included in the definition of trialware as they are regarded and classified as premium.
  7. All Plugins must be compatible with the GNU General Public License; using the same license as ClassicPress (GPLv2 or later) is strongly recommended, but any GPL-compatible license is acceptable.
  8. Where a plugin includes GPL-licensed code, the plugin must fully adhere to the GPL license.
  9. Developers are solely responsible for the content and actions of their plugin and must not do anything illegal, dishonest, or morally offensive, including exploiting loopholes in the Plugin Directory rules. Furthermore, developers must respect trademarks, copyrights, and project names; including such terms in the plugin name may be acceptable depending on use, but never at the start of the name.
  10. Only completed plugins are acceptable for submission to the Plugin Directory; incomplete or misleading submissions are not permitted.
  11. All files within the plugin must adhere to the rules. The developer will, prior to submitting their plugin to the Directory, confirm the licensing of all included files (including all code, images, etc.) and that the terms of use of any services or APIs called by the plugin are met. If this cannot be done, the plugin should not be submitted.
  12. Each time code is updated in the repository, the version number must be incremented; the use of Semantic Versioning 2.0.0 is strongly recommended. Frequent updates are not acceptable and will be seen as an attempt to game the search results; only release ready code should be committed.
  13. ClassicPress ships packaged with libraries such as jQuery, Atom Lib, SimplePie, PHPMailer, PHPass, etc.; plugins must not include their own versions of any standard libraries.
  14. Developers will act in good faith and will not restore code they were previously asked to remove; nor will they write code to circumvent the rules.
  15. The developer will maintain their own GitHub repository for each plugin which will include a stable version of the plugin (as defined by the creation of a release).
    • It is recommended best practice, but not required, that a release zip is included in a release (added in the Attach binaries by dropping them here or selecting them section).
    • Plugins defined as “Working with ClassicPress” do not require a GitHub repository, although it is recommended, but source code must be available. Plugins without a repository will not benefit from full ClassicPress Directory and core integration.
  16. It is recommended for new plugins that the plugin folder/slug contain a vendor prefix. For example, a plugin called SMTP should have a folder slug of vendor-smtp/vendor-smtp.php where vendor is the developer’s unique prefix.
  17. Code must be human readable. Obfuscating code by use of systems or techniques such as p,a,c,k,e,r’s obfuscate feature, uglify’s mangle, or unclear naming conventions such as $abc123, is not permitted in the directory.
  18. Publicly facing pages and files, such as Readme files, must not be used to spam users or game search results.
  19. Only critical or highly important notifications should be displayed outside of a plugins settings pages and must be dismissible; adverts are not permitted outside of the Plugin settings pages.
  20. Plugins must not include credits or links on the public facing site without explicit opt-in permission from the user. Free plugins may not require permission for plugins to function.
  21. ClassicPress will maintain the Plugin Directory to the best of our ability, but reserve the following rights:
    • To update the rules at any time.
    • To suspend or remove a plugin from the directory for breach, in word or spirit, of the Plugin Directory rules.
    • To allow new, active, developers to take over an orphaned plugin (see adoption rules for further details).

Failure to follow the rules, or respond in a timely manner, will result in a plugin being suspended from the directory until such time as the issue has been resolved; repeated failure to follow this rule may result in all a developer’s plugins being removed from the directory and the developer banned from future submissions.

If you are uncertain whether a plugin might violate the rules, please contact the plugin moderators at [email protected].