Skip to content
ThemesIonic — home
Troubleshooting

Your PHP Installation Appears to Be Missing the MySQL Extension

WordPress needs the mysqli extension and the PHP that is serving the site does not have it loaded. The database is fine. The extension is one checkbox in a hosting panel, one package on a server, or one line in a Docker image, and the error appears right after a PHP version change.

Updated 2 min read intermediate

WordPress checked for the mysqli extension before touching the database, and the PHP serving the site does not have it. Current versions show three lines on a page titled "Requirements Not Met": "Your PHP installation appears to be missing the MySQL extension which is required by WordPress. Please check that the mysqli PHP extension is installed and enabled. If you are unsure what these terms mean you should probably contact your host." Older releases, such as 5.8, print only the first sentence. Either way the message has nothing to do with the database server, the credentials in wp-config.php, or the tables. It is PHP's build or configuration, and it almost always follows a change of PHP version.

What WordPress actually checks

Before loading anything else, WordPress tests whether the function mysqli_connect exists, and skips the test only if wp-content/db.php is present — a drop-in that replaces the database layer. Older versions accepted mysqlnd alone as evidence; current ones do not, so a PHP build with the native driver but without mysqli now fails where it used to pass. The page is served with a 500 status, which is why uptime monitors report it as a server error.

Confirm which PHP is missing it

The PHP that serves web requests and the PHP on the command line are often different installs with different extension sets, so test the web one. The simplest check is a one-line file in the site root:

<?php
echo extension_loaded( 'mysqli' ) ? 'mysqli loaded' : 'mysqli missing', ' — PHP ', PHP_VERSION;

Load it in a browser, note the result, delete the file. If the command line is the one you can reach, php -m | grep mysqli and php -v tell you about that PHP, which may not be the one the site uses. A phpinfo() page lists both the loaded extensions and the php.ini path in use, which is the next thing needed.

cPanel and similar panels

Control panels keep a per-version list of extensions. After switching from one PHP version to another, open the PHP version screen — on many cPanel hosts it is called "Select PHP Version" — choose the version the site runs, and tick mysqli. Where the host offers only MultiPHP Manager, that screen picks the version but has no extension checkboxes; extensions are installed server-wide by the host, so ask support. Many builds also list mysqlnd, which mysqli depends on; some offer nd_mysqli as an alternative that uses the native driver. Enable one of mysqli or nd_mysqli, not both. Save and reload the site; on most such setups no restart is needed.

If the extension shows as enabled and the error persists, the site may be on a different PHP version than the one you edited: a per-directory handler in .htaccess, or a domain-level setting, can pin a folder to another version. The panel's PHP version for the domain and the version reported by the test file must match.

Plesk

Plesk sets the PHP version per domain in the domain's PHP settings; the extension list belongs to the PHP handler, which the server administrator manages under Tools & Settings. On shared Plesk hosting you can usually switch the domain to another handler version that has mysqli loaded, but enabling the extension itself is an administrator task.

Your own server

Install the extension for the PHP version in use and restart the PHP process:

# Debian / Ubuntu — replace 8.3 with the version serving the site
apt install php8.3-mysql
systemctl restart php8.3-fpm

# RHEL / Rocky / Alma
dnf install php-mysqlnd
systemctl restart php-fpm

Match the package to the version actually serving the site, which depends on how the server stack is put together — php8.3-mysql for 8.3, and so on. On Debian-family systems the package is -mysql even though it provides mysqli. Apache with mod_php needs an Apache restart instead of FPM. Upgrading PHP with the package manager installs a new version alongside the old and does not carry extensions across, which is the mechanism behind many cases of a site breaking after a PHP update.

Docker

The official PHP images ship without mysqli. A Dockerfile needs:

FROM php:8.3-fpm
RUN docker-php-ext-install mysqli

The official WordPress images include it already. If a custom image was built from the plain PHP base and then updated to a new tag, the extension line may have been lost in the rebuild. Rebuild and restart the container; the error disappears on the next request.

Local development tools

Apps that manage PHP for you — Local and similar — bundle mysqli with every PHP version they offer, so the error there usually means a damaged site or a custom PHP. Switching the site to another PHP version the app offers is the quickest test. In XAMPP, MAMP or a hand-installed PHP on Windows, open the php.ini that phpinfo() reports, make sure the line extension=mysqli is present without a leading semicolon, and restart Apache from the control panel.

Managed WordPress hosting

Managed hosts run a fixed PHP build with mysqli included, and customers cannot change extensions. If this error appears there, something on the platform is broken; open a support ticket with the exact message rather than trying configuration changes.

The error on a site that was working

The usual sequences:

  1. A host upgraded PHP for everyone, and the new version's defaults omit the extension. Enable it for that version.
  2. Someone switched PHP in the panel to fix something else. Enable it there, or switch back.
  3. A server package upgrade installed a new PHP without extensions. Install them for the new version.
  4. A php.ini or a conf.d snippet was replaced, and the extension=mysqli line was dropped — on Debian-family packages it lives in conf.d/20-mysqli.ini, not in php.ini. Restore it (phpenmod mysqli recreates the link there), restart PHP.

None of these touch the database, which is why connecting with another tool works fine while WordPress refuses. If after enabling the extension the site shows a different error about the database, that one is about connecting and has its own checks in error establishing a database connection.

Verify

Reload the test file: it should print mysqli loaded with the version the site runs. Then load the site; it should render. Finally, open Tools › Site Health › Info: the Server section shows the PHP version, and the Database section's Database Extension row should read mysqli.

Frequently asked

The host changed the PHP version, or an automatic update did, and the new version's extension set does not include mysqli. Hosting panels keep extensions per PHP version, so switching versions silently drops any extension not enabled for the new one.
Hard requirements are json and hash, plus mysqli to reach the database unless a db.php drop-in replaces it. Site Health also recommends curl, dom, exif, fileinfo, mbstring, openssl, pcre, xml, zip, filter, iconv, intl and either imagick or gd. Missing recommended ones degrade features rather than stopping the site.
Not on any supported PHP. The mysql extension was removed in PHP 7.0. Current WordPress checks for the mysqli_connect function specifically, and the message names MySQL generically because its wording predates the removal.

Related guides