WORDPRESS
WordPress Missing PHP Extensions After Upgrade: Check the Active Handler
Fix missing PHP extensions after a WordPress upgrade by checking the active web handler, FPM pool and modules—not just CLI PHP.
If WordPress reports a missing PHP extension after an upgrade, check the PHP runtime actually serving the affected domain—not just the version selected in the hosting panel or printed by SSH. Extensions belong to a particular PHP installation and configuration. Your command-line PHP can have mysqli while the site’s PHP-FPM pool does not. Confirm the web handler, its loaded configuration and the missing module before changing database credentials or installing packages.
This guide separates a site-stopping requirement failure from a recommended-module warning. It also covers the awkward case where the upgrade appears to have been reversed but WordPress still cannot start. Do not create a publicly accessible phpinfo() page to investigate; use authenticated hosting diagnostics and private logs instead.
Find which PHP runtime is missing the extension
Applies when: A WordPress site reports a missing PHP module after a runtime upgrade or rollback.
Quick answer
Verify the affected domain's actual web PHP version, SAPI and handler before changing packages. CLI PHP and the web handler can load different extensions. A missing mysqli capability is not evidence of an incorrect database password.
What to do
-
Record the domain, timestamp, selected PHP version and whether WordPress can load. Keep configuration details and logs private.
-
Use Site Health Info when accessible, otherwise authenticated hosting diagnostics. Confirm the domain's handler and FPM pool where applicable; do not expose phpinfo publicly.
-
Ask the host to enable the required module in the confirmed web build or apply a verified temporary rollback. Recheck dynamic requests and the originally affected feature.
Which evidence do you have?
All paths are listed below. Select a symptom to focus on the most relevant path.
Inspect the domain's web PHP environment
Have the host verify mysqli availability, handler mapping and extension startup logs for this domain. Do not rotate database credentials to fix an unavailable PHP function. Preserve a supported recovery option before a runtime change.
Compare separate PHP configurations
Compare version, SAPI, loaded configuration and modules using private CLI and web diagnostics. A successful CLI function check does not certify PHP-FPM. Avoid copying extension binaries or editing every php.ini.
Identify the feature requirement
Distinguish a WordPress recommendation from a required capability for your installed plugins and workflows. Confirm the affected feature before changing the environment.
Follow the actual fatal-error evidence
A plugin or theme crash needs its own stack-trace investigation. Do not keep installing extensions without evidence that they caused the remaining failure.
Did this help?
Start with the exact error, not a package name
Copy the message, affected domain, timestamp and selected PHP version into a private incident note. Record whether public pages and wp-admin both fail. A missing-module warning inside Site Health is different from an early bootstrap failure that prevents WordPress from loading.
WordPress’s server-requirements check includes a check for mysqli_connect() when no database drop-in is present. That is why the message “Your PHP installation appears to be missing the MySQL extension which is required by WordPress” directs you toward mysqli. It is not the same diagnosis as “Error establishing a database connection.” Rotating the database password does not make a missing PHP function available.
A real WordPress.org report describes a site failing after a PHP 7.4-to-8.1 change and continuing to show the extension error after switching back. Other sites on that server worked. The thread does not establish a universal fix; it illustrates why another domain working, or a panel selection changing, is not enough to verify this site’s runtime.
Failure matrix: which evidence changes the next step?
| Observation | What it suggests | Safe checkpoint |
|---|---|---|
| WordPress cannot start and names mysqli | The normal database adapter is unavailable to the executing PHP runtime | Ask the host to verify mysqli in this domain’s web handler |
| CLI lists mysqli, but the website still reports it missing | Different PHP binary, SAPI, configuration or disabled function | Compare CLI evidence with authenticated web-runtime diagnostics |
| The panel shows the new version, but Site Health shows the old one | The request may reach a different handler, backend or domain mapping | Confirm the vhost and pool serving the exact hostname |
| Site Health warns about a recommended module; the site loads | A capability may be missing without a complete bootstrap failure | Identify the affected feature and its actual module requirement |
| PHP logs report an extension startup or shared-library error | Installed files may not load in that PHP build | Have the host check the matching package, configuration and dependencies |
| The error changes to a database connection failure | The extension problem may be resolved, exposing a separate problem | Recheck web-runtime evidence, then investigate database connectivity separately |
1. Read the web runtime when WordPress still loads
Open Tools → Site Health → Info → Server. Record the PHP version and PHP SAPI shown there. The Site Health documentation distinguishes the Status checks from the detailed Info inventory. Use both: Status identifies a concern, while Info helps identify the environment WordPress sees.
SAPI means the interface through which PHP runs. A value describing FPM/FastCGI is not the same environment as command-line PHP. The version identifies the release, but does not identify every loaded module, pool override or configuration file. Ask the host for the remaining details if their authenticated panel does not expose them.
Save only the relevant fields. A full Site Health export can include paths, plugin inventory and other operational details that do not belong in public support posts. If WordPress cannot load, skip this step rather than trying to install a diagnostic plugin into a broken environment.
2. Confirm the domain’s handler and FPM pool
In the hosting panel, open the settings for the affected domain, including its document root and PHP handler. Shared hosts can offer several PHP implementations; the same version number may appear under different handlers with different extension selectors. A server-wide default is not necessarily the per-domain assignment.
For PHP-FPM hosting, ask which service and pool the site’s virtual host forwards requests to. Administrators should check the actual socket or upstream mapping, the pool configuration and the relevant startup log. An Apache module, CGI handler or another managed runtime needs its own equivalent check; do not assume all WordPress hosting uses FPM.
Compare apex and www hostnames if both are involved, and identify multiple backends if errors are intermittent. A successful request to one backend cannot certify the others. Also distinguish cached HTML from executed PHP: an old cached homepage can look healthy while an uncached admin request still fails.
Do not edit a FastCGI socket path or restart every PHP service as a guess. A wrong mapping can break neighboring sites. Have the host verify the intended target and a rollback route before changing it.
3. Compare CLI PHP without mistaking it for web proof
If SSH access is available, these commands inspect the default command-line interpreter without deliberately changing configuration:
php -v
php --ini
php -m
php -r 'echo PHP_SAPI, PHP_EOL; var_export(function_exists("mysqli_connect")); echo PHP_EOL;'The results answer four narrow questions: which CLI version ran, which configuration files it read, which modules it loaded and whether that function is available there. A true result is CLI evidence only. It does not prove that PHP-FPM or the domain’s web handler has the same extension.
Compare this inventory with the host’s private web-runtime inventory. If they differ, resolve the mismatch before adding configuration lines. Do not copy an extension’s binary file between PHP versions or blindly add extension=mysqli to every php.ini. Different builds can require different modules and dependencies. Startup logs may explain why an apparently installed extension failed to load.
4. Separate required extensions from recommended capabilities
The WordPress hosting environment handbook distinguishes required extensions from highly recommended and feature-dependent ones. For the normal MySQL/MariaDB connection path, mysqli matters; mysqlnd is not a standalone replacement for it. Installing a database server or changing its login details is a different operation.
Conversely, a recommendation involving image processing, ZIP handling or internationalization does not automatically explain a total outage. WordPress and individual plugins can have different requirements or fallback behavior. Identify the failing feature and the plugin’s documented requirements before deciding that a warning is optional for your particular site.
Check the current WordPress requirements alongside your installed WordPress release. Compatibility with a PHP version does not guarantee that the host installed its extensions, or that every plugin supports it. Avoid solving an environment problem by downgrading WordPress core.
5. Make one reversible environment correction
On managed hosting, request that the required extension be installed or enabled for the confirmed web PHP build and applied to the affected domain’s handler. On a self-managed server, first identify the operating system, PHP package source and exact running service. There is no universal package-install command that is safe across all panels and distributions.
Preserve the current domain assignment and configuration before a change. Have the administrator validate configuration and reload or restart only the affected service as appropriate. Then read the startup log and verify that new web requests use the expected runtime. A checked panel box is not a successful loading test.
If production is down, a host-supported rollback to the previous working runtime and extension configuration can be temporary containment. Reverting only the version selector may not restore the previous configuration. Do not leave an end-of-life PHP branch as the permanent solution; use the recovery window to prepare a supported environment.
6. Verify recovery beyond the homepage
- Confirm the exact extension error is gone on a fresh dynamic request.
- Recheck the web PHP version, SAPI and required module with private diagnostics.
- Test wp-admin, media processing and the originally failing feature.
- For a store, verify relevant workflows in a safe test mode and check scheduled work without triggering duplicate payments.
- Review new PHP startup and request errors, then remove temporary diagnostic access.
If a different fatal error remains, use the critical-error recovery guide rather than continuing to install modules indiscriminately. Before the next runtime change, follow the PHP upgrade compatibility checklist.
Where a static audit helps—and where it cannot
ModelGain PHP Upgrade Risk Audit scans installed plugin and theme files for compatibility risks. It does not install extensions, select the web PHP handler, inspect every FPM pool or repair a database connection. Use it for code-risk review once WordPress or a representative staging copy can run, not as a replacement for the host’s runtime diagnosis.
Frequently asked questions
Why does the extension appear enabled in the panel?
The selector may apply to another PHP implementation or domain. The running service may also have failed to load the module. Verify the web handler and startup logs, not just the checkbox.
Should I upload a phpinfo file?
No public diagnostic page is needed for this workflow. Ask for authenticated host diagnostics. PHP configuration output can expose paths and environment details; do not leave it accessible on the web.
Does a missing mysqli message mean my database password is wrong?
No. It identifies an unavailable PHP database capability in the normal WordPress connection path. Investigate credentials only if separate connection evidence calls for it.
Why do other WordPress sites on the server work?
They may use different pools, handlers or module configurations. Compare the failing domain with a working domain without copying configuration blindly.