Plugin directory design


#1

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
    • 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

    and

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

    or

    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

Misc

  • 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

Plugin Adoption/Takeover Rules
Themes and Plugins Repository
#2

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


#3

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.


#4

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


#5

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.


#6

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.


#7

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.


#8

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+?


automatically bumped #10