L’erreur qui apparaît soudainement
Vous mettez à jour PHP.
Ou migrez votre site.
Ou lancez un nouveau VPS et installez WordPress depuis zéro.
Tout semble fonctionner — jusqu’à ce que ce ne soit plus le cas.
Soudain, au lieu de votre page d’accueil, vous voyez ceci :
Votre installation PHP semble ne pas inclure l’extension MySQL requise par WordPress.
C’est l’un de ces messages qui semblent simples… mais qui le sont rarement.
Dans les anciens guides, l’explication est presque toujours la même :
« Installez l’extension MySQL ».
En réalité, surtout dans les environnements modernes (PHP 8.2, 8.3, 8.4), cette erreur a généralement très peu à voir avec une extension manquante — et beaucoup plus avec la façon dont PHP est configuré, chargé ou séparé entre différents environnements.
Elle apparaît parfois :
- juste après une mise à jour vers PHP 8.3
- après être passé d’Apache à Nginx
- lors d’une reconstruction Docker
- après une migration de serveur
- lorsque CLI et FPM utilisent des versions différentes de PHP
Et parfois — après
Diagnostic rapide en 60 secondes
Avant de réinstaller quoi que ce soit ou de modifier les fichiers de configuration, prenez un moment. Lorsque vous voyez le message your php installation appears to be missing the mysql extension, le réflexe est souvent de commencer immédiatement à installer des paquets. En pratique, cela aggrave souvent la situation.
L’objectif réel est simple : déterminer si wordpress missing mysql extension est réellement causé par une extension manquante, ou si PHP charge quelque chose de différent de ce que vous attendez.
Dans les environnements modernes, en particulier avec PHP 8.2 ou 8.3, le problème est souvent lié au contexte plutôt qu’à une véritable absence.
1. Vérifier la version PHP active
Commencez par les bases. Quelle version de PHP est réellement en cours d’exécution ?
Si vous avez un accès SSH :
php -v
Cela affiche la version CLI. C’est utile, mais pas définitif. Votre serveur web peut exécuter une version de PHP totalement différente.
Pour confirmer l’environnement web, créez un fichier temporaire nommé info.php dans le répertoire racine de votre installation WordPress :
Ouvrez-le dans votre navigateur et vérifiez :
- la version de PHP
- le chemin du Loaded Configuration File
- le Server API (Apache, FPM/FastCGI, etc.)
Il est étonnamment courant de voir PHP 8.3 en CLI alors que le navigateur indique PHP 8.1. Dans ce cas, php missing mysql extension wordpress peut ne pas concerner MySQL du tout. Il peut simplement s’agir de la mauvaise instance PHP.
2. Vérifier que MySQLi ou PDO_MySQL est chargé
Dans la sortie de phpinfo(), recherchez :
mysqlipdo_mysql
Si aucun des deux n’apparaît, alors PHP ne dispose réellement pas du support MySQL et le message your php installation appears to be missing the mysql extension est techniquement correct.
S’ils apparaissent, la situation devient plus intéressante. WordPress peut toujours afficher une erreur missing mysqli extension wordpress même si l’extension existe. Cela indique généralement un problème de configuration plutôt qu’un échec d’installation.
Depuis SSH, vous pouvez également exécuter :
php -m | grep -i mysql
Encore une fois, cette commande vérifie uniquement les modules CLI. Le serveur web peut charger un ensemble d’extensions différent.
3. Vérifier le fichier php.ini chargé
Sur la page phpinfo(), repérez la ligne :
Loaded Configuration File
Assurez-vous que le chemin correspond à la version de PHP réellement utilisée par votre serveur web.
Puis recherchez :
extension_dir
Si extension_dir pointe vers un répertoire incorrect ou vers une autre version de PHP, des extensions comme mysqli ou pdo_mysql peuvent exister sur le disque mais ne pas se charger à l’exécution. Dans ces cas, fix mysql extension error wordpress ne signifie pas installer quelque chose de nouveau. Il s’agit plutôt d’aligner PHP avec son répertoire d’extensions correct.
À ce stade, l’une des trois conclusions suivantes apparaît généralement :
- L’extension n’est pas installée du tout.
- L’extension est installée mais n’est pas activée pour l’environnement d’exécution actif.
- Le PHP en CLI et celui du serveur web utilisent des configurations différentes.
Ce n’est qu’après avoir identifié le scénario correspondant que vous devez avancer. Sinon, vous risquez de résoudre le mauvais problème.
Pourquoi cette erreur est trompeuse dans les environnements PHP modernes
À première vue, le message your php installation appears to be missing the mysql extension semble précis. Il suggère qu’un élément est absent et que son installation résoudra tout.
En 2026, cette hypothèse est souvent incorrecte.
L’extension mysql d’origine est obsolète depuis des années et a été complètement supprimée des versions modernes de PHP. WordPress ne l’utilise plus. À la place, il s’appuie sur mysqli ou pdo_mysql, tous deux standards dans les versions PHP 8.x.
Ainsi, lorsque WordPress affiche aujourd’hui une erreur wordpress missing mysql extension, cela signifie rarement « vous avez oublié d’installer le support MySQL ». Le plus souvent, cela indique que PHP n’a pas réussi à charger le module correct au moment de l’exécution.
Cette distinction est importante.
Lire aussi: Comment améliorer le Time to First Byte (TTFB) de votre site WordPress

MySQL vs MySQLi : le piège du nom
Le message d’erreur fait toujours référence à « l’extension MySQL », ce qui pousse de nombreux développeurs à rechercher le mauvais paquet. Ils essaient d’installer mysql, qui n’existe plus dans PHP 8.2 ou 8.3.
En réalité, WordPress a besoin de :
mysqli- ou
pdo_mysql
Si aucun des deux n’est disponible pour l’environnement PHP actif, vous pouvez voir des variantes comme missing mysqli extension wordpress ou php missing mysql extension wordpress.
Mais la formulation du message d’erreur n’a pas évolué avec PHP. C’est là que la confusion commence.
PHP 8.x et le problème du contexte d’exécution
Les environnements PHP modernes sont rarement simples.
Vous pouvez avoir :
- plusieurs versions de PHP installées
- des pools PHP-FPM séparés
- des déploiements conteneurisés
- des versions de PHP compilées sur mesure
- différents fichiers
php.inipour le CLI et le web
Dans ces environnements, fix mysql extension error wordpress ne consiste pas à télécharger un module. Il s’agit de s’assurer que le bon environnement PHP charge la bonne extension depuis le bon répertoire.
Par exemple :
- le CLI peut afficher
mysqlicomme chargé - alors que l’environnement web ne le charge pas
- ou PHP-FPM peut pointer vers un
extension_dirobsolète - ou une reconstruction de conteneur peut avoir ignoré
pdo_mysql
Tous ces scénarios déclenchent le même message.
C’est pourquoi installer des paquets à l’aveugle est rarement la bonne première étape. Le vrai problème concerne presque toujours un manque d’alignement.
WordPress, PHP et la base de données doivent fonctionner dans le même contexte de configuration. Lorsqu’un élément change — notamment lors d’une mise à niveau de PHP vers 8.3 — le système se dérègle discrètement et WordPress affiche cette erreur générique.
Quand le problème ne vient même pas de l’extension
Il existe une autre nuance facile à négliger.
Parfois, l’extension est correctement chargée, mais WordPress ne peut toujours pas se connecter à la base de données. Dans ces cas, le message peut apparaître parce que la couche de connexion à la base de données échoue très tôt dans le processus d’initialisation.
Cela peut se produire lorsque :
- les identifiants de la base de données sont incorrects
- le chemin du socket MySQL a changé
- MariaDB fonctionne via TCP alors que PHP attend un socket Unix
- le service de base de données est arrêté
- SELinux bloque l’accès
Du point de vue de WordPress, la connexion à la base de données échoue. L’hypothèse de secours est alors un support MySQL manquant.
Autrement dit, le message d’erreur ne décrit pas toujours la cause réelle. Il décrit le symptôme.
Comprendre ce contexte change la manière d’aborder le problème. Au lieu de réinstaller des extensions, vous commencez à analyser la chaîne d’exécution.
Et c’est là que commence le véritable diagnostic.
Lire aussi: Comment vider le cache WordPress lorsque vos modifications n’apparaissent pas
Où la connexion se rompt
Lorsque WordPress affiche le message your php installation appears to be missing the mysql extension, quelque chose échoue dans la chaîne d’exécution. La façon la plus claire de le comprendre est d’observer directement cette chaîne.
À un niveau global, le flux ressemble à ceci :
WordPress Core
↓
PHP Runtime (Web SAPI / PHP-FPM / Apache Module)
↓
MySQL Extension (mysqli or pdo_mysql)
↓
Database Engine (MySQL 8 / MariaDB)
Si un maillon de cette chaîne est mal aligné, WordPress ne peut pas initialiser la couche de base de données. Le résultat peut être une erreur wordpress missing mysql extension, même si l’extension existe techniquement.
Examinons où cette chaîne se rompt le plus souvent.
1. L’extension n’est pas installée
C’est le scénario le plus simple. PHP a été installé sans mysqli ni pdo_mysql.
Cela peut se produire lorsque :
- PHP est compilé depuis les sources sans
mysqlnd - des images de conteneur minimales sont utilisées
- PHP est installé manuellement sur un VPS sans le paquet MySQL
Dans ce cas, php -m et phpinfo() n’afficheront pas mysqli ni pdo_mysql. L’erreur est alors correcte.
2. L’extension est installée mais non activée
Ici, l’extension existe sur le disque mais n’est pas chargée.
Raisons courantes :
extension=mysqliest absent du fichierphp.ini- l’extension est compilée mais non activée
- différents fichiers
php.inisont utilisés pour le CLI et le web - un mauvais
extension_direst configuré
C’est dans ce cas que se situent de nombreux problèmes php missing mysql extension wordpress. Les développeurs voient mysqli.so dans le dossier des extensions et supposent que tout fonctionne. Pendant ce temps, PHP-FPM ne le charge jamais.
3. Le PHP CLI et le PHP du web sont différents
C’est l’une des causes les plus fréquentes dans les environnements modernes.
Vous exécutez :
php -m | grep -i mysql
La commande affiche mysqli.
Tout semble correct.
Mais le serveur web utilise en réalité une autre version de PHP. Cette version peut ne pas avoir le support MySQL activé.
Dans cette situation, le problème n’est pas l’absence du support MySQL. Il s’agit d’un décalage entre les environnements d’exécution.
Cela arrive particulièrement souvent après :
- une mise à jour vers PHP 8.3
- un changement de panneau d’hébergement
- l’activation de MultiPHP dans cPanel
- une migration d’Apache vers Nginx
Les environnements CLI et web se désynchronisent silencieusement.
4. L’extension se charge mais la couche base de données échoue
C’est le cas le plus subtil.
mysqli apparaît dans phpinfo().
PHP est correct.
Les chemins de configuration semblent corrects.
Pourtant, WordPress affiche toujours des messages du type fix mysql extension error wordpress.
Ici, la rupture se produit plus bas dans la chaîne :
- chemin du socket incorrect
- hôte incorrect dans
wp-config.php - service de base de données non démarré
- MariaDB a été mis à jour et a modifié ses paramètres par défaut
- problèmes de permissions sur le fichier socket
Du point de vue de WordPress, la connexion échoue lors de l’initialisation. Le message d’erreur suppose que la couche d’extensions en est responsable.
Techniquement, ce n’est pas le cas.
5. Environnements conteneurisés et cloud
Dans les déploiements Docker ou cloud, la rupture peut se produire au moment de la construction.
Par exemple :
- L’image de base n’inclut pas
pdo_mysql docker-php-ext-install mysqli pdo_mysqla été ignoré- Une reconstruction a remplacé la couche PHP mais pas la configuration
- Des variables d’environnement ont modifié la connectivité à la base de données
Dans ces cas, wordpress missing mysql extension peut apparaître après ce qui semblait être une mise à jour d’infrastructure sans rapport.
C’est pourquoi cette erreur est rarement isolée. Elle est presque toujours liée au contexte.
Lorsque vous comprenez la chaîne, vous cessez de considérer ce problème comme une simple question d’installation. À la place, vous identifiez quelle couche a changé.
Cette approche rend la résolution méthodique plutôt que réactive.
Les causes réelles derrière l’erreur d’extension MySQL
À ce stade, vous avez probablement identifié où la chaîne se rompt. La question devient maintenant pratique : que faut-il exactement corriger ?
La réponse dépend entièrement de votre environnement. Un hébergement mutualisé fonctionne très différemment d’un VPS personnalisé ou d’un déploiement Docker. L’erreur affichée peut être identique, mais la cause sous-jacente varie.
Passons en revue les scénarios les plus courants.
Environnements d’hébergement mutualisé
Sur un hébergement mutualisé, en particulier avec cPanel ou des panneaux de contrôle similaires, le problème est souvent lié au changement de version de PHP.
De nombreux fournisseurs d’hébergement permettent d’utiliser plusieurs versions de PHP simultanément. Vous pouvez passer à PHP 8.3 dans le panneau de contrôle, mais le domaine peut toujours être lié à un gestionnaire plus ancien.
Si vous voyez wordpress extension mysql manquante sur un hébergement mutualisé, vérifiez les points suivants :
- Quelle version de PHP est attribuée au domaine
- Si
mysqlietpdo_mysqlsont activés dans la liste des extensions PHP - Si le gestionnaire MultiPHP applique le bon handler
Dans cPanel, cela implique généralement :
- Ouvrir Sélectionner la version PHP
- Confirmer que PHP 8.2 ou 8.3 est actif
- S’assurer que
mysqlietmysqlndsont cochés
Après avoir enregistré les modifications, actualisez le site. Si l’environnement d’exécution bascule correctement, l’erreur disparaît immédiatement.
Si ce n’est pas le cas, le domaine peut toujours être associé à un autre pool PHP.
C’est précisément là qu’une maintenance WordPress continue évite les dérives de configuration silencieuses. De petites incompatibilités de version passent facilement inaperçues jusqu’à ce qu’elles perturbent l’environnement de production.
Configurations VPS et serveurs dédiés (Ubuntu / Debian)
Dans les environnements VPS, le problème est généralement plus explicite.
Si PHP a été installé sans prise en charge de MySQL, vous pouvez vérifier avec la commande suivante :
php -m | grep -i mysql
Si rien n’apparaît, installez le module requis :
sudo apt update
sudo apt install php-mysql
Ensuite, redémarrez le service approprié :
sudo systemctl restart php8.3-fpm
Ou, si vous utilisez Apache :
sudo systemctl restart apache2
Mais c’est précisément ici que beaucoup font une erreur.
Ils redémarrent la mauvaise version de PHP-FPM.
Si plusieurs versions sont installées, assurez-vous de redémarrer exactement le service utilisé par votre serveur web. Redémarrer php8.2-fpm alors que Nginx pointe vers php8.3-fpm ne change rien.
Ce décalage à lui seul peut provoquer des erreurs php extension mysql manquante wordpress même lorsque l’extension est bien installée.
Incompatibilité Nginx + PHP-FPM
Dans les configurations modernes, notamment après une mise à niveau de PHP, les fichiers de configuration peuvent encore faire référence à d’anciens sockets.
Par exemple :
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
Si le système est passé à PHP 8.3 mais que Nginx pointe toujours vers le socket 8.1, WordPress s’exécute avec le mauvais environnement.
Dans ce cas :
- La CLI affiche
mysqli - PHP 8.3 prend bien en charge MySQL
- Mais le serveur web continue d’utiliser la version 8.1 sans cette extension
L’erreur apparaît alors et donne l’impression qu’une extension est manquante.
En réalité, il s’agit simplement d’un problème de configuration.
Docker et déploiements conteneurisés
Les environnements conteneurisés ajoutent encore une couche supplémentaire.
Si vous construisez à partir de l’image officielle PHP, les extensions MySQL ne sont pas toujours incluses par défaut. Vous devez les ajouter explicitement lors de la phase de build :
RUN docker-php-ext-install mysqli pdo pdo_mysql
Si cette ligne est supprimée, ignorée ou écrasée lors d’une reconstruction, le déploiement suivant peut soudainement déclencher l’erreur votre installation PHP semble manquer de l’extension mysql.
Cela se produit souvent après :
- des mises à niveau de l’image de base
- le passage d’images Debian à Alpine
- des modifications dans le pipeline CI/CD
L’extension n’a jamais été « supprimée » manuellement. Le conteneur a simplement été reconstruit sans celle-ci.
Dans des environnements complexes impliquant des couches API, des systèmes SaaS ou l’intégration de l’IA dans les plateformes web modernes, ces effets secondaires lors des reconstructions sont fréquents. WordPress peut n’être qu’un composant d’une architecture plus large.
Installations Multi-PHP
Ce point mérite une attention particulière.
De nombreux serveurs exécutent :
/usr/bin/php/usr/local/bin/php- plusieurs pools FPM
- des pools distincts par domaine
Vous pouvez confirmer que mysqli est installé globalement, mais le pool actif peut utiliser un autre fichier php.ini.
C’est ici que l’expérience en développement web professionnel WordPress devient essentielle. Identifier quel environnement PHP traite réellement la requête nécessite d’examiner les fichiers de configuration des pools, et pas seulement de vérifier les modules.
Lorsque des configurations multi-versions se désynchronisent, WordPress ne se préoccupe pas de la raison. Il signale simplement qu’une extension est manquante.
Dans tous ces scénarios, le schéma reste le même. Le problème concerne rarement l’installation de quelque chose de nouveau. Il s’agit plutôt de s’assurer que le bon environnement d’exécution charge la bonne extension dans le bon contexte de configuration.
Plus l’infrastructure est complexe, plus le désalignement devient subtil.
Lire aussi : 5 étapes pour ajouter des redirections 301 dans WordPress via htaccess (guide pratique complet)
Tableau de dépannage : Symptôme → Cause principale → Solution
Voici une référence pratique présentant les variations les plus courantes de l’erreur votre installation PHP semble manquer de l’extension mysql.
| Symptôme | Cause probable | Élément à vérifier | Solution pratique |
|---|---|---|---|
php -m n’affiche aucun module MySQL | Extension MySQL non installée | Liste des modules CLI | Installer php-mysql ou activer mysqli / pdo_mysql |
php -m affiche mysqli, mais pas le navigateur | Différence entre PHP CLI et PHP Web | phpinfo() vs version CLI | Aligner la version PHP-FPM avec le serveur web |
mysqli visible dans phpinfo() mais WordPress échoue | Mauvais extension_dir | extension_dir dans php.ini | Corriger le chemin du répertoire et redémarrer FPM |
| L’erreur apparaît après une mise à jour PHP | Nginx ou Apache pointe vers un ancien socket | Configuration du serveur web | Mettre à jour fastcgi_pass ou le gestionnaire PHP |
| L’erreur apparaît après une migration | Version PHP changée silencieusement | Panneau d’hébergement / MultiPHP | Réassigner la bonne version PHP au domaine |
| Erreur dans Docker | Extension non installée lors du build | Dockerfile | Ajouter docker-php-ext-install mysqli pdo_mysql et reconstruire |
| La connexion à la base de données échoue toujours | Incohérence du socket ou de l’hôte | wp-config.php DB_HOST | Ajuster l’hôte vers le bon TCP ou le bon chemin de socket |
| L’erreur apparaît de manière aléatoire | Plusieurs pools PHP actifs | Configurations des pools FPM | Vérifier le pool actif et redémarrer le bon service |
Ce tableau reflète ce qui déclenche le plus souvent l’erreur wordpress extension mysql manquante dans les environnements PHP 8.x modernes.
Remarquez un point important.
Dans plus de la moitié de ces scénarios, l’extension est techniquement présente. Le problème est contextuel — mauvais environnement d’exécution, mauvais fichier de configuration ou mauvais service redémarré.
C’est pourquoi réinstaller des paquets à l’aveugle ne résout généralement rien.
À ce stade, si aucune des lignes ci-dessus ne correspond à votre situation, il vaut mieux observer le comportement réel du système plutôt que de rester dans la théorie.
Voyons à quoi cela ressemble en pratique.
Cas réel : après une mise à niveau vers PHP 8.3
Une situation fréquente ressemble à ceci.
Un serveur fonctionne avec PHP 8.1 sans problème.
Tout fonctionne correctement.
L’administrateur met ensuite à niveau vers PHP 8.3.
Immédiatement après la mise à niveau, WordPress affiche :
votre installation PHP semble manquer de l’extension mysql
Le premier réflexe est de penser que PHP 8.3 a supprimé la prise en charge de MySQL.
Ce n’est pas le cas.
Ce qui s’est réellement produit dans de nombreux cas :
- PHP 8.3 a été installé correctement
mysqliétait compilé et disponible- Nginx pointait toujours vers l’ancien socket 8.1
- PHP-FPM 8.3 n’a jamais été redémarré
Du point de vue de WordPress, la couche base de données a échoué lors de l’initialisation. Le message d’erreur générique s’est alors affiché.
Chez CoDiCo, nous avons observé ce schéma à de nombreuses reprises lors des transitions de version. La solution consistait rarement à installer quelque chose de nouveau. Dans la plupart des cas, il s’agissait simplement d’aligner correctement les couches d’exécution après la mise à niveau.
Une fois que le serveur web a pointé vers le bon pool FPM et que le service a été redémarré correctement, l’erreur a disparu instantanément.
Cas particuliers auxquels vous ne vous attendez peut-être pas
Il existe des situations où tout semble correct à première vue. mysqli est visible dans phpinfo(). La version de PHP correspond bien à celle que le serveur est censé utiliser. Les identifiants de base de données dans wp-config.php paraissent exacts. Et pourtant, WordPress affiche toujours votre installation PHP semble manquer de l’extension mysql.
À ce stade, le problème se situe généralement plus profondément dans l’infrastructure.
L’une des causes les plus souvent négligées est une incohérence de socket. Sur de nombreux systèmes Linux, MySQL ou MariaDB communique via un fichier socket Unix plutôt que via TCP. Si le chemin du socket change lors d’une mise à niveau, PHP peut toujours charger mysqli, mais échouer à établir la connexion. WordPress affiche alors un message générique wordpress extension mysql manquante, même si l’extension fonctionne parfaitement.
Un autre problème plus subtil apparaît après les mises à niveau de MariaDB. Les méthodes d’authentification par défaut ou certains paramètres de connexion peuvent changer discrètement. Si PHP attend une configuration alors que le serveur de base de données en exige désormais une autre, l’établissement de la connexion échoue très tôt. Du point de vue de l’application, cela ressemble à une absence de prise en charge de MySQL. En réalité, il s’agit d’un problème d’authentification ou de transport.
SELinux peut également interférer. Sur les systèmes renforcés, même lorsque mysqli est activé et correctement chargé, les politiques de sécurité peuvent empêcher PHP d’accéder au socket de la base de données. L’extension est présente, mais l’environnement d’exécution ne peut pas l’utiliser. Le message d’erreur qui en résulte est trompeur, mais techniquement cohérent avec un échec d’initialisation de la base de données.
Les versions de PHP compilées sur mesure introduisent une autre variable. Si PHP a été compilé sans mysqlnd ou lié à une bibliothèque client incompatible, le module peut apparaître comme installé mais se comporter de manière imprévisible. Ces situations sont rares, mais lorsqu’elles surviennent, les méthodes de dépannage classiques échouent, car le problème est structurel.
L’orchestration de conteneurs ajoute également sa propre complexité. Dans les environnements distribués, l’hôte de base de données défini dans wp-config.php peut être résolu différemment à l’intérieur du réseau de conteneurs. Un nom de service mal configuré ou une variable d’environnement incorrecte peut interrompre la connectivité, et WordPress peut à nouveau afficher php extension mysql manquante wordpress, même si l’extension est correctement chargée dans le conteneur.
Le schéma reste le même dans tous ces cas particuliers. L’erreur visible décrit rarement la cause réelle. Elle indique simplement que WordPress n’a pas réussi à initialiser sa couche de base de données, et la couche d’extension est seulement la première hypothèse.
Lorsque vous arrivez à ce niveau de diagnostic, la solution ne consiste plus à installer des paquets. Il s’agit plutôt d’analyser le flux d’exécution, de vérifier l’alignement des configurations et de confirmer que chaque couche communique exactement comme prévu.
La bonne nouvelle est qu’une fois le véritable point de rupture identifié, la correction est généralement simple. La difficulté ne réside pas dans l’application de la solution, mais dans l’identification de la bonne couche à diagnostiquer.
Ensuite, nous allons tout regrouper dans une liste de diagnostic finale afin que vous puissiez vérifier chaque couche de manière méthodique avant d’aller plus loin.
Lire aussi : Un guide simple et clair pour modifier le fichier functions.php dans WordPress
Liste de diagnostic finale
Si vous souhaitez résoudre ce problème de manière claire et méthodique sans tester des solutions au hasard, utilisez la liste ci-dessous. Elle est conçue précisément pour les situations où WordPress indique votre installation PHP semble manquer de l’extension mysql, alors que la cause réelle peut être cachée dans le contexte d’exécution.
- Vérifiez la version de PHP dans le navigateur via
phpinfo(), et pas uniquement via SSH. Si les versions CLI et web diffèrent, vous ne diagnostiquez pas le même environnement d’exécution. - Dans
phpinfo(), vérifiez quemysqlioupdo_mysqlapparaît dans la liste. Si aucun des deux n’est présent, l’extension est réellement absente. - Vérifiez le chemin du Loaded Configuration File. Assurez-vous que le fichier
php.inique vous modifiez est bien celui chargé par l’environnement web. - Repérez
extension_diret confirmez qu’il correspond à la version active de PHP. Un mauvais répertoire peut empêcher silencieusement le chargement des modules. - Si vous utilisez PHP-FPM, vérifiez quel pool et quel socket sont utilisés par votre serveur web. Après une mise à niveau, les configurations Nginx ou Apache continuent souvent de pointer vers d’anciens sockets.
- Redémarrez le bon service. Redémarrer « un » service PHP-FPM ne suffit pas si plusieurs versions existent. Celui qui est réellement actif doit être redémarré.
- Si l’extension est chargée mais que l’erreur persiste, vérifiez la connectivité à la base de données : statut du service, type d’hôte (socket ou TCP) et éventuel changement du chemin du socket.
- Vérifiez à nouveau
wp-config.phppourDB_HOST. Dans les environnements conteneurisés, l’hôte correct est souvent un nom de service plutôt quelocalhost. - Si votre système utilise SELinux ou des politiques de sécurité renforcées, assurez-vous que PHP est autorisé à accéder au socket ou au port réseau de la base de données.
- Supprimez le fichier
info.phpune fois vos vérifications terminées. Le laisser accessible publiquement représente un risque de sécurité.
Si vous pouvez valider tous les points ci-dessus et que le site ne fonctionne toujours pas, vous n’êtes plus dans le cas d’une « extension manquante ». À ce stade, il s’agit plutôt d’un problème d’infrastructure plus profond ou de cohérence de build, et non d’un problème lié à une mise à jour de WordPress.
FAQ
Pourquoi WordPress indique-t-il que l’extension MySQL est manquante si MySQLi est installé ?
Parce que le message utilise une formulation héritée. WordPress a besoin de mysqli ou pdo_mysql, mais si PHP ne les charge pas dans l’environnement d’exécution actif, ou si le contexte d’exécution ne correspond pas, WordPress peut toujours afficher l’erreur wordpress extension mysql manquante.
PHP 8.3 prend-il toujours en charge MySQL ?
Oui. PHP 8.3 prend en charge MySQL via mysqli et pdo_mysql. Si vous voyez l’erreur php extension mysql manquante wordpress, il s’agit généralement d’un problème de configuration ou d’alignement de l’environnement d’exécution, et non d’une absence de support dans PHP.
Comment activer MySQLi dans PHP ?
Sur la plupart des systèmes, vous pouvez l’activer en installant le paquet approprié (souvent php-mysql) ou en activant le module dans votre panneau d’hébergement. Sous Windows, cela peut nécessiter de décommenter extension=mysqli dans php.ini. Le point important est de l’activer pour l’environnement PHP réellement utilisé par votre serveur web.
Pourquoi php -m affiche-t-il mysqli, mais WordPress ne fonctionne toujours pas ?
Parce que php -m vérifie l’environnement d’exécution CLI. Votre serveur web peut utiliser une version différente de PHP, un fichier php.ini différent ou un autre pool PHP-FPM. C’est l’une des causes les plus fréquentes dans les situations liées à corriger l’erreur d’extension mysql wordpress.
Cette erreur peut-elle être causée par des identifiants de base de données incorrects ?
Oui. Si WordPress échoue dès l’initialisation de la base de données, le message d’erreur peut être trompeur. Des identifiants incorrects, un service de base de données arrêté ou une incohérence de socket peuvent provoquer des symptômes similaires même lorsque mysqli est chargé.
Ce problème est-il généralement résolu en mettant WordPress à jour ?
Parfois, mais rarement dans les configurations modernes. Dans les environnements PHP 8.x, cette erreur est le plus souvent liée à la configuration du serveur plutôt qu’à des fichiers du cœur de WordPress obsolètes.
Remarque finale
Dans la plupart des cas réels, votre installation PHP semble manquer de l’extension mysql n’est ni un problème WordPress ni un problème à résoudre en « réinstallant PHP ». C’est un signal indiquant qu’une couche de la chaîne d’exécution PHP est désynchronisée. Une fois que vous identifiez quel environnement traite réellement la requête et que vous confirmez que mysqli ou pdo_mysql y est chargé, la correction est généralement directe.
Chez CoDiCo, les solutions les plus rapides consistent presque toujours à vérifier d’abord l’alignement de l’environnement d’exécution, et non à installer davantage de paquets.


