ClassicPress Plugin Directory (Development)


For any non-trivial program in a general-purpose programming language it is virtually impossible to say “there are no security issues” - there is no practical level of auditing to achieve that.

This is a well-known issue (we’re hardly the first to tackle this problem), so I would expect there to be standard legal language to deal with it.



I hope we can automate as much of our plugin auditing process as possible, both due to lack of time to review everything manually and to create an objective standard. A couple of potential starting points:

As others have said, even with an excellent automated review process there is no way to guarantee security, only to eliminate the “low-hanging fruit” in terms of potential issues.

I’d definitely be interested in exploring automated auditing further.

Under a system like this, ClassicPress would be building a plugin directory, not a repository. For each plugin, we’d store at least the repository name (on GitHub), the git commit hash (to make sure that we’ve audited the current version of the code), and the basic info like icon, description, and website.



There are lots of auditing options, up to and including partnering with a company that does code review. That’s a topic for another thread.

We should not be auditing every plugin in the directory - not even in a fully-automated way - as it will cause vastly more problems than it solves.

I was simply trying to make the point that we need a directory, but unless we’re going to do something useful with it - like audited plugins - we don’t need a repository.



Clarification: I used the terms repo and directory interchangeably in my post above. I was referring to the directory.



@azurecurve I know enough to be dangerous. I know it’s a royal pain and massive amount of work to fork a codebase. I can’t do it so I have immense appreciation for what goes into the work. I was referring to the act of finding plugins that already are “CP friendly” that with a few tweaks could be relevant for a CP plugin repo and then picking what would be in that repo. Technically, I’m not always going to be on-target because my coding skills are HTML, some CSS, very basic JavaScript and that’s it. It’s the marketing behind the movement that I’m trying to help with. That’s all.



I should clarify that a directory is a place to list public plugins and a repo is a place to work on code. From what I gather above, CP is looking at creating a directory, but not a repo.

It sounds like we (plugin devs) will submit plugins for inclusion in the directory, but will manage our repos on our own. This is ideal. The CP project doesn’t need to have copies of every branch of every plugin (in a repo) – instead, it only needs the finished plugin for listing (in a directory.)



No need to reinvent the wheel I think… Given the plethora of information available on existing plugins via the WordPress Plugins API, wouldn’t a plugin repository mirror approach make for a good starting point?

Auditing plugins is an impossibly time-consuming job and would mean nothing else would ever get done. Instead, we can start with the fact that most plugins will be already be compatible with ClassicPress if working with WP4.9… So wouldn’t a process of elimination be much easier…?

  • remove anything made for specifically for Gutenberg (and that specifically won’t be made backwards compatible with Classic Editor, but most will anyway at least for a while.)
  • temporarily remove “old” plugins (consider them abandoned until they can be manually reviewed - in the sense any “auditing” could be left to just checking if they still work or not.)
  • can still mark/remove certain plugins if broken for ClassicPress as they come up, but keeping on top of those shouldn’t really be too hard. either they get fixed by the author and relisted or they don’t.
  • perhaps a simple gist on Github could keep track of these via pull requests while the actual directory is being developed.
1 Like


Note: I’ve moved this thread to the new Plugin Directory subforum.

From here I’d suggest moving to new threads to discuss and plan specific topics related to developing the directory.

1 Like


Just my two-cents… for paid services i hope there will be a good invoicing system.

I find graphicriver billing method terrible: you must handle 3 invoices for every order (sometimes I pay more my business consultant for handling those invoices than the cost of a plugin).
Amazon also, when you buy something that they don’t sell directly, gets terrible. You have to manually ask for an invoice to the seller, sometimes without answer.


automatically bumped #32