Providing the forums is easy (though quickly expensive with load) - moderating them isn’t. We’ve nothing like the resources needed for moderating, so I ruled out doing that for now. However, if we put together a good value-add on top of e.g. Discourse that might be an option.
We could leverage forum groups on Discourse where we hide categories except for when a user is part of x group.
Basically what we are doing with the committee channels on the forums.
OK, but does that scale?
Let’s say we have 1000 plugins that need a support forum; assuming this is a paid offering these are likely to be some of the most popular plugins.
- Does Discourse scale that far at all?
- What’s the UX like with that many categories?
- Assuming you let plugin authors manage their own category, how do you manage 1000 plugin authors?
- If we assume an average of 1000 unique users per plugin (over time) that’s 1m users - is Discourse the right tool for that job?
I mentioned Discourse because we’re using it - I’ve honestly no idea if it’s the right choice. For a few 10s of plugin, no problem - maybe even for a few 100 - but for 1000+?
invisnet [2:04 PM]
there’s no reason we couldn’t add support for a little more control over who sees the beta releases
Code Potent [2:05 PM]
Now, that is a bit more interesting.
I want to restrict pre-releases/betas to users who are well-versed with the current release…to ensure that testers hit the ground running.
If it could be restricted by GitHub usernames - or even members of a GH team – I could see more of a (personal) use-case.
I’m not sure about this either, but keeping everything centralized under Discourse would definitely be easiest if it will work well enough. Maybe we can set up a forums test environment and try out some things (large numbers of subforums and users).
Another thing we could do is ask the folks at https://meta.discourse.org/ how well Discourse might scale for this use case.
@invisnet How exactly the rules should be drafted will depend on whether the directory is simply going to display plugins or whether we are going to have support forums.
I’m thinking, in particular, about the way we handle a report of a security flaw from a user. If we have forums and the report is made there, then we need to spell out how we are going to handle them in addition to outlining what will happen if we (i.e. you) find a flaw (or have it reported to us through a channel other than the forums). If, however, we don’t have forums, then we will be able to address potential security issues in just one way, irrespective of how we obtained the relevant report.
Just to be clear, this should not be taken as suggesting that I am not in favor of having support forums. In fact, I would much prefer to have them. It’s just that the way we draft the rules will need to take account of that fact.
Let’s assume for a moment that we have forums at some point (I doubt we will at the start, but it’d be nice to have eventually).
We should never have security reports via the forums - that’s the wrong way to do it and we’ll need to take those kinds of posts down. The difference there between us and WP is that we’ll have a well-defined way of contacting both us and the author; if it turns out that something is in the wild and being exploited then we can post something to the forum in addition to the normal procedure of flagging the plugin as insecure.
That’s the one scenario I’m still thinking about how best to deal with - if you automatically disable the plugin you might break their site, but if you leave it alone they may well get compromised.
6 posts were split to a new topic: Plugin Vulnerability Warning
3 posts were split to a new topic: Disable Vulnerable Plugins
Here’s a first draft of the security policy for plugins:
We are pleased to provide this plugin directory both as a convenience to our users and to support those developers who have created plugins designed to work with ClassicPress.
Just as ClassicPress takes a security-first approach, we ask that developers who submit plugins for listing in the directory take the same approach. If we identify a potential security problem with any of the plugins listed, we will:
notify the developer of the potential problem;
flag the plugin as potentially insecure within the ClassicPress dashboard of those users with the plugin installed;
remove the plugin from the directory while a code review is conducted; and
flag as potentially insecure all other plugins in the directory that have been created by the same developer while a code review is conducted for each of them.
Once an affected plugin passes code review, it will be eligible for reinstatement in the directory without being flagged as potentially insecure.
Plugin developers who are found to have included a security problem with malicious intent will be banned from having any of their plugins listed in the directory.
Anyone who believes that they have discovered a security problem with a plugin listed in the directory should report the issue as soon as possible to EMAIL ADDRESS. Such reports should NOT be made in the support forums. Any report of a security problem made in the forums will be removed.
In every instance, what constitutes a security problem, code review, or malicious intent are matters exclusively for the forum moderators and the ClassicPress security team leader to determine. Their decision is final.
This is the only part of the current spec that jumps out at me as needing improvement. I expect many plugin authors will want to release a version of their plugin that works with both WP+Gutenberg and ClassicPress. As long as the plugin is tested for compatibility with WP 4.9 and/or ClassicPress this shouldn’t prevent the author from also staying up to date with WP.
As a side-note would it be useful to flag authors with a rating or average response update time or something? I’m not personally a developer of plugins or dedicated themes so I’d be interested in hearing from actual devs - would this be an issue for you?
For clarity I’m trying to think from a user perspective where you might be off-put by a plugin that hasn’t been updated in a while - but perhaps is so simple/basic it doesn’t need updating . Or where plugins are flagged as “potentially unsafe” merely because the user checks the repository at a time when the plugin is is being actively updated but hasn’t been pushed live yet.
I’m not sure what current policy on either WP or CP is but is there potentially a notification system we can use for authors to let them know there’s been CP updates and they may want to check they’re all up to speed - and the ability for them (or maybe others) to flag things as tested, compatible and not a security risk?
That came from @CodePotent’s designed for ClassicPress thread I don’t think it should apply to plugins in the directory as this would rule out lots of plugins for no good reason.
As long as code is compatible and tested with ClassicPress it should be acceptable.
Yes, that applies to my ClassicPress-specific plugins post which is intended to highlight ClassicPress-only plugins – no dual support plugins, no conversions, no WP plugins rebranded for CP…which would be off-topic to the post.
It makes no difference to me if WP-supportive code makes it into the CP plugin directory.
Yes, that phrase could do with some work.
The idea is to ensure that no WP-specific code is loaded (or available) at runtime under CP, not to prohibit a single shared codebase.
Update: that phrase has had some work - feedback welcome!
Quoted for posterity after the changes… this looks good to me.
This does not make sense to me.
Will CP have 3 ways to update a plugin? (that sounds like WP-specific code)
Will every code change to a plugin be audited? (no way to have the manpower for that)
Would there be a way to opt out of auto updates? (there are times updates are not wanted – e.g. Gutenberg)
I think the user would be confused as to what they are getting. With WP, if it’s listed in the admin Plugins search, it has been reviewed (initially at least). If there is a security problem, the plugin is closed so it does not show as available. But there are plugins available everywhere, and the user knows that those external ones have not been reviewed. The plugin author is rewarded with exposure to users by putting the plugin in the WP repo.
Some consideration should be given to what restrictions are put on plugins that are shown to the users, such as advertising or hijacking the admin or removing the plugin Deactivate link or crypto mining or tracking users or phoning home or sending spam, etc. I assume you want to be fair, but if you don’t restrict it, fairness goes out the window.
No, just 2 (we’ll most likely leave the existing WP-based plugin mechanisms in place for people who want to install plugins from the WP directory). There may be some variations in how plugins in the ClassicPress plugin directory are presented but they will be hosted the same way (for example, on GitHub).
The technical meaning of patch-level is important here. Plugins that are audited by ClassicPress will be required to use the semver version specification which is major.minor.patch (e.g.
1.2.3). In this example,
1.2.4 would be an automatic update, but
1.5.0 would not.
A patch version update (only the third number increases) means there are no breaking changes, only minor changes or bugfixes. The responsibility would be on the plugin author to follow this standard.
Please don’t use the words “repository” and “directory” interchangeable. They have a very different meaning in CP.
Maybe you know, that in CP we don’t have repositories, just a directory. WP has a repository. Old member knows this, but suppose, this thread will read a novice.
And if you think about the differences, you will find answers to some questions and worries above.