Add `hash` as a required extension for 6.8

[johnbillion]

Background: ​https://core.trac.wordpress.org/ticket/62815

There's a good chance that this new requirement will ship in 6.8. If it does, the update API needs to be updated to prevent a site from being served the 6.8 update if hash isn't installed. This core change also puts us in a good place to mark further PHP extensions as required in future versions if necessary.

What's needed in order to update the update API?

[dd32]

The API has never enforced PHP extensions, that's left to update-core.php in core which bails if the requirements aren't met.

​https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/update-core.php?marks=1184-1195#L1171

The reasoning for this is

• Historically core did not send PHP extensions as part of the update payload (and it's optional)
• The API doesn't (currently) return a extensions_required field that core could be updated to check against (like it does php_version)

If core would like to update to add a extensions_required field to the endpoint and have core flag this in the UI prior to attempting the upgrade, that's something we can implement on WordPress.org.

[johnbillion]

Thanks, I was under the impression that api.wordpress.org/core/version-check took the extensions query parameter into place when determining whether to include a given version in the update offer. That may have been an assumption on my part.

A response field such as extensions_required would be good. Currently the only extension that's required is json since WP 5.3 (​https://core.trac.wordpress.org/ticket/47699).

What do you think?

[dd32]

Definitely onboard with adding a extensions_required field, although generally core only ends up requiring extensions that are installed on near-100% of sites, with polyfills otherwise.

Technically pcre is an extension, although I'm not sure if it can be disabled. It appears to be installed on 100% of sites though (Same as JSON). hash is on something like 99.99997% of sites, and mysqli that's on 99.998% of sites.

That does make me question if the maintenance burden / minute extra bandwith / extra core logic is really worth it when it might ultimately only ever affect only a handful of sites. The core bootstrap / upgrade-prevention checks are probably enough.

That might change if we ever move to require an extension that's installed on a smaller set of sites, for example, zip that's only on 92.5% of sites.

[johnbillion]

I also agree about the maintenance burden. I had hoped that we wouldn't need to go this far but I started thinking about future proofing.

Thinking about it further, we have ​the same catch-22 situation that I mentioned here in that core can't make use of a new response parameter from the API until it's at least updated to a core version that supports it. We can't stop sites from updating to 6.8 based on required PHP extensions because no such check exists in 6.7. (This is what lead me to thinking about the update offer varying depending on the extensions query parameter.)

Perhaps we should park this for now. Unfortunately there's not much we can do about the handful of sites that don't have hash installed that update to 6.8 -- they'll end up getting updated but going down with an error about the missing extension.

[dd32]

We can't stop sites from updating to 6.8 based on required PHP extensions because no such check exists in 6.7. (This is what lead me to thinking about the update offer varying depending on the extensions query parameter.)

The update-core.php file that's executed as part of the core upgrade is from the newer version. That is, the file included in 6.8 must be compatible with WP 3.0~6.7, as it'll be executed as part of the upgrade routine.

That's why the json check linked above works, if a site attempted to update from 5.2 to 5.3 it would abort with a Sorry, no JSON installed and not take the site down.

That's all to say, any API changes would only be able to affect future 6.8+ required extensions, but we'd still have to have the checks in update-core.php to abort the upgrade for any older sites.

[johnbillion]

Thanks for the info @dd32. That does indeed address the catch 22 situation that I thought existed when checking dependencies for an update. I've updated my PR for the ticket with some extra tests.

I'll close this off as not required. Cheers!