Enforcing minimum core and PHP versions

[szepeviktor]

Currently wpackagist may upgrade a plugin to a version that needs newer core than present.

# Check required core version of plugins
wp eval 'foreach(get_option("active_plugins") as $p)if(version_compare(get_plugin_data(WP_PLUGIN_DIR."/".$p)["RequiresWP"],get_bloginfo("version"),">")){error_log("Incompatible plugin version:".$p);exit(10);}'

I use this PHP one-liner to make deployment fail. It works well on staging.

Now I'm experimenting with a Composer plugin that reads readme.txt and plugin main file headers.

The problems is that reading headers needs the package to be extracted thus installed. Has anyone been thinking about this?

[NoelLH]

Hey @szepeviktor, thanks for raising this.

I've just had a quick think, looking for docs to try to assess what options there might be.

I don't think anything that relies on actually executing the PHP in every plugin is likely to be safe enough to consider building into the service, since to my knowledge there's just a cursory review before things are on the SVN server.

It does seem like there's some text-based processing already happening on the WordPress.org side though, which goes slightly beyond readme.txt these days but perhaps still just extends to doc blocks? In particular I'm looking at:

Since WordPress 5.8 plugin readme files are not parsed for requirements. This means that headers Requires PHP and Requires at least are going to be parsed from plugin’s main PHP file.

You'll see there's some other open questions on Wpackagist around packaging quality where using readme.txt info has been suggested, like at https://github.com/outlandishideas/wpackagist/issues/475#issuecomment-1271620724, but I'm not sure they reliably solve the data problem in that case.

If WordPress.org has already parsed the files for decent compatibility metadata, this could suggest we might be able to do this without reinventing the wheel to get it, but I see a few unknowns and quite a lot of work to get there:

• Plugin authors need to have used the correct/new way of defining minimum core compatibility
• We might(?) need to use v1.2 of the API, which could in turn mean working on updates to the https://github.com/Rarst/wporg-client library which uses v1.1
• The plugin API docs are not great. For example, there is a note "see docs" which has no link associated, and v1.2 "includes a different set of default fields" but I don't know which. Consequently I'm not really clear on whether v1.2 is a breaking change vs. v1.1, whether the linked blog refers to fields already available in v1.1.

Perhaps more fundamentally, I could see this enabling us to provide a way to restrict installs based on PHP version, but probably not WP core because there are several common ways to install core – some with Composer and some not. I think a Composer plugin that handles all of these would be a significant undertaking, but I've never built one. Would be interesting to hear if you think there's a way to combine metadata from the repository with runtime logic in your plugin?

Let me know if you have any ideas generally, or a better understanding of the API compatibility info than me.

[szepeviktor]

Thank you for the inspiring response!

there's a way to combine metadata from the repository

I do not trust undocumented WP.org API-s.

I think a Composer plugin that handles all of these would be a significant undertaking

I have two plugins behind my back.

1. hook into pre-install Composer event
2. extract ZIP archive
3. look for min. core version in plugin main file (which is the main file?)
4. fallback to parsing readme.txt
5. throw an exception if plugin needs higher version of core than present

It would be much nicer to have core as dependency of every plugin but that would break current installations: https://github.com/composer/composer/issues/11379#issuecomment-1473535646

Very sad.