Draft of the Plugin Directory Guidelines

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 https://developer.wordpress.org/plugins/plugin-basics/header-requirements/ in plugins and https://developer.wordpress.org/themes/basics/main-stylesheet-style-css/ 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

I was thinking, since ClassicPress introduced Security page should we consider making it into a requirement for security settings to be added to the Security page? Developers like to add top level menus or add menus to the Settings, so it might be a good idea to require them to use Security page so it can be used to its full potential. Otherwise it will remain largely unused.

1 Like

A post was split to a new topic: Security page feedback and improvements

I’m happy to be corrected, but the readme is used by the directory so needs certain elements within it; the plugin header is mainly optional and done if the developer wants to do so. The page you linked seems to support this as only this is required:
/**
* Plugin Name: YOUR PLUGIN NAME
*/

What’s the benefit of having it in the plugin header? (I also ask as someone who does have that in plugin headers).

Well, it’s not optional, for any parts that core is using. See https://docs.classicpress.net/reference/functions/get_plugin_data/ for which parts are expected. Some things, like text domain, rely on WP infrastructure still?

OK, so the linked WP page had bad information.

I don’t think text domain relies on any WP infrastructure?

I can’t find it in the code, but core loads the translations file from GlotPress for themes and plugins in the WP repository. Since WP 4.7, the theme or plugin does not have to put the path in the call for loading the text domain. WP will do it for you, using the plugin or theme slug as the text domain. The translations are also part of the update process.
If your plugin or theme is not in the WP repo, you have to package your language files yourself and use that path in the function to load the text domain.
Since I only know English, I haven’t seen this, but I think the initial download of a plugin would include the language files from GlotPress, which are put in the languages folder, separate from the plugin so that updates are not affected. Then the text domain load tries the languages folder first, followed by the plugin’s folder. Trying those folders is at least part of CP, so it’s only a matter of defining what CP should be doing about language files, if anything.

1 Like

I think this one is a hidden trap for problems. Mika just opened a new ticket in WP meta to automate the checking of trademarks.
#5868: Improve checks on non-viable plugin names to prevent abuse

Indeed it is. There’s a minor controversy I noticed about the automatic rejection of plugins that use “wp” in their name, which was requested by WP foundation. Not sure if this is related to Mika’s ticket.

We probably should have a process for a trademark owner to submit a complaint. This means we should mention that the plugin can be taken down or we may request a name change if trademark owner requests it.

If you read the WP Slack, it seems different than what that article says. And the ticket explains that it’s more about preventing future problems (like changing the display name from wp to WordPress) than it is about wp being a trademark.
But definitely plan to have the means to reject or remove if there is a violation of any of these guidelines.

The irony of all ironies is that the Wordpress Foundation does not own the trademark to “WP” and yet it’s enforcing it as if they do.

Here’s something I think is worth considering, but I admittedly don’t know what the best solution would be.

Wordpress today has a huge problem where plugins with a lot of installations get sold and/ or bought out. Yoast is the latest example.

Sometimes bad actors buy the plugins and insert malicious code into them. Coupled with Wordpress’ auto-update feature and now you have a mechanism not just for potential abuse, but a mechanism that is being abused today.

I think tying the plugins to github will help. But I also think that if the plugin source URI changes for any reason a warning should be displayed to the admin. Same for changes to the “owner” or “developer” and if there is going to be some sort of auto-update mechanism I think that should be turned off any time key metadata does change about any given plugin.

Just thinking out loud here. As an admin and not a developer I know I now am very careful about what plugins I install and enable especially one’s with huge install bases. On one hand a huge install base is reassuring that the plugin is legit, but on the other hand it’s always in the back of my mind will this developer sell us (wordpress sites) out and will malware be surreptitiously inserted at sometime in the future.

1 Like

It seems to be related, based on the answer from WP foundation executive director. They block wp to prevent developers from changing it to WordPress later.

That’s the lamest excuse of the decade. LOL

1 Like

@azurecurve should we include trialware plugins in the guidelines? I saw HappyFiles was delisted from WP repository because the plugin reviewer labeled it as trialware because it has a 10 folder limit. This is probably a mistake because it sounds more like a freemium plugin, but that did make me think about trialware plugins that would stop working after X amount of time.

For reference, here’s an email the HappyFiles developer sent about delisting:

Shortly after the last release (version 1.5.1) the WordPress repository team delisted the free version of HappyFiles on wordpress/org.

No warning, no heads-up, nothing. Straight-up delisted the best-rated media manager plugin for WordPress without me ever having violated anything on wordpress/org before.

All other WordPress media manager plugins that had the same folder restriction as HappyFiles received an email warning upfront about this “violation”. So much for treating everyone equally.

The (anonymous) reviewer labeled HappyFiles as “trialware” due to its 10 folder limit. Which violates the repository guidelines. That is the sole reason it got delisted. Security-wise, etc., everything was fine.

I, every HappyFiles user that I talked to, and the dictionary disagree.

Trialware is defined as: “… computer software that can be used free of charge for a limited evaluation period.”.

That definition does not apply to the free version of HappyFiles.

Thousands of plugins in the WP repository provide a limited, free version, which can be unlocked by purchasing the paid version.

The 10 folder limit has also always been clearly stated upfront and all users of the free version were happy with it.

This so-called “freemium” model is most often the only viable & sustainable way to ensure the people behind any project have the required resources to build, maintain & support their software.

As it stands right now HappyFiles will continue to be delisted on wordpress/org

And this also brings up a question, should we outline a process that ClassicPress will take to suspend a plugin to give developers an idea of what happens and when.

For example, something like this:

  • When plugin guidelines are breached, the plugin developer will receive an email with details of the breach. The developer will have 7 days to reply and/or update the plugin to correct the issue.
  • Failure to respond or correct the issue within 7 days will result in suspension.
  • Ensure you have a valid, frequently monitored email listed on your developer’s profile.
  • ClassicPress reserves the right to suspend a plugin with a serious vulnerability and/or security issue without prior notice to prevent users from downloading a vulnerable plugin.

If we don’t put specific timeframes, then it becomes open to interpretation.

I think we cover it well in 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.

Since we accept Premium, I see nothing wrong with accepting Trialware too, after all, it’s just a Premium Software you have the chance to test…

What I totally agree is that we can’t be arrogant like WP and not send head ups out when removing software, unless as you say, it is a security breach, in which case the software should be temporarily unavailable for download but still the author should be contacted.
But you know, you can contact as much you want when the plugin dev’s have no-reply emails as contacts listed (which they very often do).

WP Team is very quick with making assumptions, both in forum as well as plugin review. Kind of a side effect of having 50 k plugins to keep an eye on I guess but also because in 99% of the cases, they are actually doing things right, and the author is just saying they didn’t get any email, probably because they didn’t read the inbox or as said, have the wrong email added in the plugin contacts.

This is what we need to avoid. Perhaps open communication here in the forum is best (specially when the email fails), so we have both proof that we did initiate contact, and also its not obscure as of why things get removed, if they do get removed.
Like:

  • initiate email
  • wait 5 days
  • if no reaction, initiate forum post, with a @mention
  • if no reaction within 24 hours or so, go thru with the required actions such as plugin removal.

Of course this would only apply to minor violations. A major violation or security issue should be taken down immediately, and everything else should come after.

3 Likes