Draft of the Plugin Directory Guidelines

With the Plugin Directory now having plugins added, it’s probably time to finalise the guidelines. Below is the current draft of the guidelines from the [last thread on the topic][Plugin Directory Rules - #3 by azurecurve) with a few small tweaks.


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

The following rules are intended to provide transparency around the plugin submission process for developers who submit their plugins to the directory; further the rules 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 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.
    • 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 can be deemed as having 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.

    • Free - completely free, un-crippled, and not soliciting in any way.
    • Freemium - some functionality free, but some requiring payment to the plugin developer.
    • Premium - paid, with no functionality available otherwise.
  6. All Free 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.

  7. Where a plugin includes GPL-licensed code, the plugin must fully adhere to the GPL license.

  8. Developers are solely responsible for the content and actions of their plugin and must not do anything illegal, dishonest, or morally offensive, including exploting 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.

  9. Only completed plugins are acceptable for submission to the Plugin Directory; incomplete or misleading submissions are not permitted.

  10. All files within the plugin must adhere to the rules and 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.

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

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

  13. Developers will act in good faith and will not restore code they were previously asked to remove or write code to circumvent the rules.

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

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

  17. Publicly facing pages and files, such as Readme files, must not be used to spam users or game search results.

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

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

  20. 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].

3 Likes

Only one that is tough at the moment is this one, everything else I think sounds good :+1:

Point 4 could be extended…

  • to exclude opt-in for checking for updates
  • to exclude opt-in for plugin designed to contact external servers (twitter sharing, sending mail ecc…)

Just this for me…

1 Like

At present are we saying only free are allowed?

I can amend the rule to state this for now and it can always be added back if freemium/premium are then allowed.

1 Like

Let me think about the phrasing of this. Plugins which connect to other services probably should state something in the readme (I’ll hold my hands up and say mine don’t).

1 Like

I think Premium is okay, there is just currently no way to flag a plugin as premium in the directory.

I’ve amended for update servers and identification of freemium/premium.

I’m not sure if we need to update rule 4 for plugins which connect to services like Twitter?

Maybe something like “Plugins designed to integrate with third part services such as Twitter or SMTP are excluded from this rule as those services terms of service will be accepted by the user when they configure the integration.”?

2 Likes

Maybe even something easier (but non written so bad :sweat_smile:)
“Plugins designed to integrate with third part services such as Twitter or SMTP are excluded from this rule as their main goal is clearly to connect with a remote service".

1 Like

To be honest, installing a plugin that says it will connect with Twitter/SMTP would to me be “explicit and authorized opt-in” and most times you will be required to add your login/authorize the plugin anyways. I think maybe saying for those plugins that do that they need to be super clear that is their primary function.

I’ve updated based on your and @Simone’s feedback.

2 Likes

I’ve added a new rule recommending the use of vendor prefixes.

1 Like

Updated rule 14 to clarify what a stable release is).

1 Like

But what is this definition?
So we can now use Github feature? Or still need to upload the Zip ourselves?
Is there a point I miss where we define how the GitHub release has to be created?

1 Like

After discussion I’d describe recommended best practice for a release is to create a release on GitHb which includes a separate release zip with the required folder structure in the binaries section:


Adding the separate release zip is recommended but not required, so the automatic source code zip is acceptable.

2 Likes

I did a final tweak to rule 14 based on the previous post, but, unless there are objections, I’d say these rules are finalised and ready for publishing.

2 Likes

@anon66243189 the guidelines are ready to be published; is this something you can do as part of your current updates?

1 Like

We’d have a “plugins standards” space yes where all related plugin dev stuff would be

It’d be a custom post type so easiest would be a csv or xml exported with all export or even WP exporter

I’m finishing up for today and hope to have the system online by tomorrow afternoon

2 Likes

@azurecurve I would like to add a important detail to our requirements both for theme and plugins

The must follow this Header Requirements | Plugin Developer Handbook | WordPress Developer Resources in plugins and Main Stylesheet (style.css) | Theme Developer Handbook | WordPress Developer Resources for themes

In the plugin main .php file and in the theme style.css file, NOT in the readme.txt files
Why?
Because all available WP/CP functions to actually get requirements of a or several themes/plugins do not read the readme.txt file. They read the stylesheet and the main plugin php file.

Thus, 99% of all themes and plugins, unless developed with much love, will all miss the requirements in the main plugin php or theme style file, even if they add it to the readme files (which is what the WP Repo traditionally reads).
And since they only care about passing the review, the information never gets added to the main files, and thus completely defies the purpose of said information other than what’s good for the WP Repo.
WP Plugin reviewers also do a nasty job here, because they only care for the readme file, and do not really check if the information corresponds to the respective style or main php file.

Thus I thought we could do better at CP.
(It is easier to add this requirement than adding a new scanner that scans a readme txt file.)

I should have more time next week and will revisit the guidedlines as I know there is some other feedback I’ve not responded to yet.

1 Like

A post was split to a new topic: Git-php integration for plugins