ClassicPress PetitionsClassicPress Petitions
This is a read-only archive. Post or comment on the live version of this page on our forums.

Have a page on the website where plugins that support ClassicPress can be added and rated.

December 4, 2018 · 22:24 · Ray Gulick

Plugin compatibility is one of the biggest concerns for people considering the switch. If there was an easily findable place where plugin support for CP could be documented and rated (eg, 1-works great; 2-minor issues; 3-breaks), it would make it easier to select plugins for CP sites.

+54 more
Laurence Bahiirwa

All plugins that worked with WP 4.9.8 should be working

Ray Gulick

Understood, but that will change over time. Having a place CP users can go to find vetted plugins will be helpful to them.

James Nylen

Good idea - I think this should be part of whatever the ClassicPress plugin directory ends up looking like.


Like the idea.




I would definitely support a plugins directory of sorts, however, I think this is directly related to how much support for GitHub (etc) that ClassicPress will have.


Specifically, to differentiate this project from WordPress, to reduce work load, and to empower developers and agencies rather than creating another fiefdom of favoritism and corruption, I think a sort of "meta engine" or index of plugins would be more appropriate than a full blown style directory.

We were planning to do something similar for SlickStack, using the below website and their open source code as inspiration:

See also:

This could be up and running in a matter of days, instead of years. Instead of e.g. whitelisting or blacklisting plugins or agencies that ClassicPress doesn't like, which is the drama that has gone on for a decade at, it would entail something more along the lines of indexing every single compatible plugin on GitHub that currently supports ClassicPress (whether or not still maintained). I don't think over moderating or filtering such an index is a good idea because it will only narrow the potential ecosystem of developers, cause drama, etc. Instead, the meta engine could integrate a reviews system, but not host the plugin code. To login and leave a review (or to login to it could require GitHub Oath to ensure that real identities are being used, to avoid trolling and spam, and to eliminate fake reviews and extortion of plugin authors... the reviews could also have a merit-based requirement meaning that only reviews that directly address the plugin's functionality, code, etc will be retained. Complaining about the agency's customer service or other unrelated topics ("I'll change my review if you do XYZ...") could be disallowed...