"Requires at least" guidelines

[smileBeda]

https://docs.classicpress.net/plugin-guidelines/plugin-header-requirements/ says (yeah, I have had written that myself in past) that:

Requires at least: The lowest WordPress version that the plugin will work on. Note: this field only works if the plugin is stored on the WordPress Repository. Note 2: if set, the version should be no higher than 4.9.15

That is suboptimal, because a plugin can very well require WP above 4.9.15 and also support CP. The way to do that, is to require WP > 4.9.15 in the header, and if CP is active load whatever other code. This can be done using something like function_exists( 'classicpress_version' ) && version_compare(classicpress_version(), '1.0.0', '>=');

However, due to the header requirements, one wouldn't be able to do that.

Has the CP Community meanwhile created other types of Header tags (remember that the Requires at least actually ONLY works if the plugin is stored on WP Repo), and/or removed this requirement?

Thanks!

[viktorix]

Thanks @smileBeda for pointing this out. It's a good reminder to re-visit plugin header requirements. Haven't looked at this page in a while. With the upcoming v2 based on WP 6.2, this may need to be adjusted further to accommodate that.

We do have a directory requirements, which relate to plugin header requirements: https://docs.classicpress.net/plugin-guidelines/directory-requirements/

[smileBeda]

I think as long CP ignores the Requires at least: if Requires CP is set, then this would be OK! It would allow the plugin to both support a higher WP Version, and a CP version of choice.

It might sound weird, but indeed it is entirely possible to (example) produce a plugin with a Block (thus requiring WP 4.9+) and if CP is detected, simply not add that Block and instead provide a fallback solution. Not that this happens often, but, I am rewriting the https://github.com/TukuToi/better-wp-plugin-boilerplate completely to a more modern codebase, and would like to keep it WP and CP compatible. So this came up. I will use Requires CP in the header and make some tests once I have a first working version.

[viktorix]

@smileBeda make sure it's compatible with v2+. Once we release 2.0, support for 1.x will be stopped soon.

@xxsimoxx might be able to add more information about this, but he might reply after August 21 when he returns from a holiday.

[xxsimoxx]

I agree with this, but I think it's not yet time to discard Requires at least: header.

• There are a lot of checks for that value in the code
• We get many plugins from WordPress directory

[smileBeda]

Just out of curiosity - as CP is going 2.0 and will be a copy of some 6.+ WP (without blocks), it will supposedly not require WP 4.9 max anymore, right? But, then, if a plugin says "min version required 6+", it will actually mean it needs blocks code available. That then however won't work still on CP as it won't have blocks code available.

So - if I understand it right - if CP indeed is listening to that directive inside its own code, this would have to be removed prior to any 2.0 release, because it would otherwise effectively "allow" install of plugins requiring 6+ from the repo, and still fail to run those plugins (if they include blocks, which is highly expected)?

_However, also note that the Requires at least: is supposedly only used by the WP Repo and its API, not by the actual source code of WP (meaning, if you upload the plugin manually, it should actually not check that directive). But I could be wrong about that, it has been a while that I checked how it works._

[viktorix]

it will supposedly not require WP 4.9 max anymore, right?

That's correct. $wp_version is set to 6.2.

it will actually mean it needs blocks code available

That's also correct. This is why we've added block compatibility mode to prevent block functions and some classes in themes/plugins from causing fatal errors. Some classes we were not able to polyfill, but they are used by plugins that add/modify blocks so they should not be used by CP users at all. For example, Spectra plugin.

We've also disabled FSE themes from being installed in CP v2.0.

I've been using v2 in production (I like to live dangerously) and so far, I've been able to use plugins that did not work in v1.x, such as Gravity Forms, SEOpress Free/Pro, and Pretty Links Free/Pro.