Plugin directory design

This will grow in scope and detail over time, but for now it’s a collection of notes.

Listing Plugins

  • Plugins will be categorised (names tbd):
    • Legacy - plugins from the WordPress repo
      • Download from WP’s repo
      • Support on WP’s forums
      • Uses WP update system
    • ClassicPress - submitted plugins that meet our guidelines
      • Download from Plugin’s repo
        • Option to specify Tag or Release
        • Releases will be validated:
          • Release tags must be signed
          • Signing public key must be registered with CP directory
          • Send email to verify signer has access to email address
      • Support provided by Plugin
        • Option for paid support forum?
      • Uses CP update system
        • Future: auto-update at patch-level for plugins that explicitly support semver.
      • Must not include WP-specific code at runtime
      • Must clearly separate WP-specific code to simplify auditing
    • Audited - ClassicPress + security audit
      • Must use semver
      • Download from ClassicPress repo
      • Support on CP forums
      • Auto-update at patch-level
      • Who does the audit, how it’s paid for, how support forums paid for: tbd

Searching for plugins

  • Dependency resolution will happen on the server

  • Plugins will only appear in search results if:

    1. Plugin compatibility version >= site ClassicPress version, or
    2. Plugin is a dependency of a Plugin where (1) is true, i.e. compatibility is transitive


    1. Plugin has no known security issues, and
    2. Plugin dependencies have no known security issues


    1. Plugin is already installed
  • Plugins with known security issues can be found by jumping through a set of hoops to be determined

Updating Plugins

  • Plugins not using semver must tag bugfix releases
  • Security releases:
    • Where the issue has been responsibly disclosed and is not in the wild:
      • Authors must notify us so that we:
        • can flag the plugin if the issue isn’t resolved after a reasonable amount of time
        • are able to tell if it’s in the wild
      • The security update will be tagged as such after the first of:
        1. 90% of users have updated
        2. 30 days
    • Where the issue is in the wild:
      • Plugin will be immediately flagged as insecure
      • The security update will be immediately tagged as such

Handling Malicious Code

(@timkaye input here please)

  • Trust in the system is more important than any single plugin or author

  • 3 options when malicious code found: (we probably want to rename these)

    • Nuclear - for clear, unambiguous malicious intent
      • For every plugin by that author:
        • Flag as insecure/untrusted
        • Notify authors of plugins with a dependency
          • Decide if it can be forked/merged/etc
        • Change the plugin listing to explain why it was removed
      • No new plugins accepted from that author
        • Should this be permanent?
    • Thermobaric - where there’s a plausible explanation (this is a deliberately vague reason to give some flexibility)
      • As Nuclear but only for that plugin
      • For all other plugins:
        • Flagged as potentially insecure
        • Code review
        • If another malicious plugin found at any point, proceed to Nuclear
      • All new plugins from that author subject to code review
        • Should this be permanent?
    • Cleanup
      • For that plugin, standard security issue procedure
      • For every other plugin by that author:
        • Flag as potentially insecure
        • Code review
  • Process (tbd) - contact author etc

  • Nuclear Example: Things like this (P3) are unacceptable (and very probably illegal in the UK if not elsewhere) and following a process (TBD) would get the Nuclear option - not because the code was particularly bad, but because (assuming Wordfence are quoting accurately) the author said:

    Last year we had some serious problems after someone obtained a huge list of license keys and downloaded all of our products. … The drop tables function was put in place to try to stop this at the time.

    In other words, it was all intentional, they don’t think they did anything wrong, and they’d probably do it again.

  • Thermobaric Example: ???

  • Cleanup Example: PEAR. There was malicious code, but they didn’t add it.


  • Some notification should appear in the dashboard for plugins flagged as insecure
    • Big red warning if the plugin is activated
    • Yellow warning if the plugin is deactivated, and some extra hoop(s) to jump through to activate it
  • Should we handle pre-releases?

Will there be channels (ie, forum) built into the directory for supporting end users?


I’ve updated with support info - as with everything we may decide to do more later, but I’m trying to stick to what we can realistically achieve now.


Thanks. Will plan on keeping my in-plugin support channels open for now.

1 Like

Should we consider adding support forums for plugins in our directory? It would be good to be able to centralize this, but we’d need to evaluate whether we’d be able to meet the extra resource demands this would impose.


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.

1 Like

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.

  1. Does Discourse scale that far at all?
  2. What’s the UX like with that many categories?
  3. Assuming you let plugin authors manage their own category, how do you manage 1000 plugin authors?
  4. 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.

1 Like

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 how well Discourse might scale for this use case.

1 Like

@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 @anon71687268’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. :wink:

It makes no difference to me if WP-supportive code makes it into the CP plugin directory.

1 Like