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
I can see the value in expanding on the review process outline for breaches of the rules.
It may also be worth explicitly mentioning trialware in the rules. That isn’t something which has previously been raised.
1 Like
I think the first version of the directory should only include fully free code, until we are ready to handle freemium/premium products reasonably well.
How would free and freemium differ? Freemium are listed in WP repo just like free, no difference. Or is there a specific use case you’re thinking about?
Maybe we can make a note in the guidelines that support for premium plugins is coming in the near future.
1 Like
Free = completely free and open source
Freemium = some features free, some not
Premium = completely paid
There are also some gray areas like trials that expire after a certain amount of time (which it looks like people are not in favor of allowing), and upsells.
I’m not opposed to us including freemium and premium plugins but I don’t think we’re ready for it yet: the directory should be stable and well-tested for free plugins first.
Maybe a middle ground would be to allow upsells with some rules around that practice (for example: can only appear in the plugin’s own admin screen, must use the default CP styles for admin notices, must be dismissable using the standard X button).
1 Like
We need to be careful with freemium plugins because that may exclude WP plugins that support CP. Shield Security and Beaver Builder are 2 examples. Both are listed in the directory.
1 Like
So, I guess it’s too late to rule out freemium then 
The last time I remember discussing this was around here: Policy for non-GPL plugins - #7 by james
I’m concerned that the core does not do the update, so it has to be built into the plugin. The WP guidelines prohibit plugins from transmitting code:
Plugins may not send executable code via third-party systems.
This seems like a good guideline to have, yet we can’t.
Maybe we can make it conditional and limit it to updating system? And note it’s temporary.