Opened 2 years ago
Last modified 2 years ago
#56017 new task (blessed)
Check the required PHP extensions during WordPress installation and updates
Reported by: | SergeyBiryukov | Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Upgrade/Install | Keywords: | dev-feedback |
Focuses: | Cc: |
Description
Background: #55603
Currently, marking a PHP extension as required in Site Health displays a warning on existing sites if the extension is unavailable, but it does not block the WP installation for new sites, nor the updates to the new version for older sites.
To avoid fatal errors, WordPress core should check for the required PHP extensions both during installation and updates, similar to how we check for the required PHP and MySQL versions.
As also noted by @jrf in comment:2:ticket:55603:
Might also be a good time to improve the code re-usability in that regards (have one master list of requirements and recommendations, which both the requirements checker on installation/load + the Site Health component draw from).
Change History (12)
This ticket was mentioned in Slack in #hosting-community by javier. View the logs.
2 years ago
This ticket was mentioned in Slack in #hosting-community by jadonn. View the logs.
2 years ago
This ticket was mentioned in Slack in #hosting-community by javier. View the logs.
2 years ago
This ticket was mentioned in Slack in #hosting-community by chaion07. View the logs.
2 years ago
This ticket was mentioned in Slack in #hosting-community by jadonn. View the logs.
2 years ago
This ticket was mentioned in Slack in #hosting-community by javier. View the logs.
2 years ago
This ticket was mentioned in Slack in #hosting-community by amykamala. View the logs.
2 years ago
#9
@
2 years ago
- Keywords dev-feedback added
@SergeyBiryukov @jrf What's the preferred approach here for code reusability? Should we use a new constant, such as WP_PHP_EXTENSIONS
in wp-includes/default-constants.php
?
In this Site Health location, it can still be filtered for BC.
If not, what would you propose?
#11
@
2 years ago
- Milestone changed from 6.1 to Future Release
With WP 6.1 RC 1 scheduled tomorrow (Oct 10, 2022), there is not much time left to address this ticket. Given it still needs a patch, let's move this ticket to Future Release
.
Ps: if you were about to send a patch and if you feel it is realistic to commit it in the next few hours, please feel free to move this ticket back to milestone 6.1.
#12
@
2 years ago
As noted in comment:36:ticket:55603:
There is precedent for blocking a site from upgrading when a PHP extension is missing. In WordPress 5.2, the native JSON extension was marked as required (see [46455]). When an upgrade was attempted and a site did not have this extension loaded, an error was shown and the update was cancelled.
...
One other thing to note is that an error code specific to the scenario where the JSON extension missing is returned, which allows the number of sites to being blocked from an update to be tracked in .org's mission control to gauge whether this deprecation ends up being problematic or not (see [46560]).
This has always been a big discussion in the Hosting Team.
WordPress Handbook PHP extensions
Required:
Highly recommended:
Fallbacks or optional:
File changes (depends on hosting):
And, finally, a recommendation we did some time ago:
Why hosters should install the PHP-intl extension