Why are plugin headers treated this way? Make it make sense!

Don’t overcomplicate things :wink:

Reduce it to the basic scenarios and then look for the simple solution to each - As I’m sure most of it is already in place and can be achieved with a few relatively simple tweaks.


To start, remove all extra functionality and underlying update logic from the Requires CP header. This is mainly so that it works predictable and the same way as the WP counterpart. It also helps people like me who have plugins elsewhere but still want to provide useful compat information to users.

Where updates come from should be handled by, and depend on, the integration plugin. They should not be fully dependent on a header. But then only if a optional extra plugin is in place. And maybe this or what, or whatever… That’s not predictable, not logical OR useful.


Also, advertise in the dashboard that the integration plugin exists… I’ve been using CP for years and didn’t even know that it existed until 3 days ago. Hell, bundle it like that pepper plugin you guys keep forcing into every update. And make it clear what it does, what it’s for and why people should have it alongside the “normal” updates.

Perhaps it should be renamed to Classicpress Update System or something recognizable and convenient to help adoption.


Or as an alternate to having the integration plugin, which at the core shouldn’t be required. Introduce a new header that decides where updates come from.

Like you have the Requires CP header for the version, and another one which could literally be something like “ClassicPress Updates: Yes|No|Compatible” And the value would decide what happens.

Yes for updates definitely should come from CP.
No for updates should NOT come from CP.
And Compatible, where CP can decide what works best, because perhaps the plugin is on both CP and WP systems, or maybe even on a 3rd (4th?) party server.

The value is up to the developer, but CP should dictate valid values. The yes/no could even be the literal download url.


You can also, and this is probably a lot simpler, work with the guys from hub2wp ( GitHub - WP-Autoplugin/hub2wp: Browse, install, and update plugins hosted on GitHub directly from your WordPress dashboard. ) and have their update plugin take over from the integration plugin and have them fully support CP. They did most of the work already, and it’s kinda what you guys are trying to achieve anyway. Surely there is a useful overlap in features and functionality that you can benefit from. It really is a useful plugin with some clever mechanics for updates.

The extra benefit for them is that their plugin becomes more visible and popular, which may help regular WP users de-couple from the Automattic dominance as well.

Kinda win-win at the surface level.


And finally - Add the relevant headers from API responses to core. When I tested a requires_cp thingy in my api responses CP didn’t even pick up on that, despite the integration plugin using it. Which I don’t use.

But add that stuff into core so it can be shown in the plugins dashboard alongside the requires_wp field, or even replace it in some instances.

And, well, I again spent way too much time writing this - Back to work :waving_hand:

With PR #2262 merged it takes the “ClassicPress” tag from the WP Repo into consideration. I think plugin compatibility notifications are now as best as currently possible. It has been included in CP Nightly.