Lire le prérequis qui bloque réellement WordPress
Vous ouvrez l’installation ou une mise à jour de WordPress, et un message indique une version PHP insuffisante, une base trop ancienne ou une extension PHP absente. Le but est d’obtenir un environnement compatible avec la version prévue, sans contourner le contrôle ni effacer une installation existante.
PHP est le moteur qui exécute WordPress. MySQL ou MariaDB est le service qui conserve ses données. Une extension PHP est un module du moteur, différent d’une extension installée dans le tableau de bord WordPress. Ces trois éléments demandent des vérifications distinctes.
Copiez le texte exact du refus avec la version de WordPress concernée et l’heure. Ne retenez pas seulement « serveur incompatible » : le message peut préciser le composant et le seuil attendu. Une erreur de connexion à la base ne prouve pas, à elle seule, que sa version est trop ancienne.
Ne modifiez pas les fichiers du cœur pour supprimer le contrôle de version. Cela ferait disparaître un avertissement sans fournir les fonctions dont WordPress a besoin.
Protéger ce qui existe avant de relancer l’installation
Vérifiez si le domaine doit héberger un site neuf ou retrouver un site qui contenait déjà des données. Si des articles, comptes ou commandes existaient, ne poursuivez pas l’assistant comme une nouvelle installation. Faites confirmer la bonne base, le bon répertoire et le contexte de la mise à jour.
Conservez les fichiers et une sauvegarde de la base dans un stockage privé avant une évolution d’environnement. Vérifiez leurs dates et la possibilité de les restaurer. Un téléchargement du répertoire du site n’inclut pas automatiquement les données MySQL ou MariaDB.
Notez les versions et réglages actuels ainsi que les autres sites qui utilisent le même compte. Un changement de PHP ou de service de base peut avoir une portée partagée. Préparez le retour avec le prestataire ; un retour de version de base n’est pas un simple bouton garanti.
Si vous préparez une copie de test, assurez sa séparation de base et protégez son accès. Neutralisez courriels, paiements et automatismes externes avant de l’utiliser. Une adresse de préproduction ne suffit pas à rendre les essais sans effet sur l’activité.
Identifier l’offre, les droits et l’environnement
Sur WordPress autohébergé, utilisez le compte d’hébergement autorisé ou l’assistance du prestataire. Le rôle administrateur dans WordPress ne donne pas nécessairement le droit de modifier les moteurs. Si vous gérez seulement les contenus, transmettez le message au responsable sans demander son mot de passe.
Notez le domaine, la racine documentaire et l’offre qui les héberge. La racine documentaire est le répertoire publié pour ce domaine. Une installation peut utiliser une version PHP différente de celle d’un autre site du compte, ou hériter d’un réglage commun.
Sur WordPress.com, les moteurs sont gérés par la plateforme et cPanel ne s’applique pas. Une option PHP peut néanmoins être disponible pour votre site. Préparez les sauvegardes et la copie avant ce parcours. Si l’option manque ou si le moteur de base est en cause, contactez l’assistance du site concerné.
En multisite, associez le responsable du réseau. Les fichiers, la configuration et les composants partagés peuvent rendre une modification utile pour un site mais problématique pour les autres.
- Ouvrez le tableau de bord d’hébergement WordPress.com et choisissez le titre du bon site.
- Ouvrez Settings, puis la section Server et la rubrique PHP. Relevez la version initiale.
- Choisissez une version disponible, maintenue et compatible avec vos thèmes et extensions ; utilisez d’abord la copie préparée.
- Cliquez sur Save, puis contrôlez le site et ses fonctions dans ce même environnement.
- En cas d’incompatibilité, revenez par le même chemin à la version initiale seulement si elle est encore proposée et supportée. Sinon, appliquez le retour préparé avec l’assistance.
Relever les versions réellement utilisées
Si WordPress fonctionne encore sur un site existant, ouvrez Outils, Santé du site, puis Informations. Les rubriques Serveur et Base de données aident à relever l’environnement. Conservez la version complète et le type de base, pas seulement « PHP 8 » ou « SQL ». Ces rubriques décrivent la configuration ; elles ne permettent pas de changer le moteur. Partagez seulement les valeurs utiles au diagnostic, sans publier un relevé complet de l’environnement.
Si l’installation ne démarre pas, consultez les informations du domaine dans le panneau d’hébergement et demandez au support les versions effectivement associées. La présence d’un moteur récent sur la machine ne garantit pas que votre domaine l’utilise.
Un résultat obtenu dans un terminal peut décrire une autre installation de PHP. De même, la version d’un outil d’administration de base n’est pas la version du serveur MySQL ou MariaDB auquel WordPress se connecte. Faites vérifier le bon contexte plutôt que de comparer des écrans qui ne décrivent pas la même chose.
Relevez aussi les modules PHP manquants cités par le message. N’ouvrez pas les fichiers de configuration par une adresse publique et ne créez pas une page phpinfo() accessible à tous pour obtenir ces informations. Le prestataire peut les confirmer dans ses outils privés.
La requête ci-dessous lit uniquement la version du moteur. Elle ne change aucune table et ne demande donc aucune restauration. La version de phpMyAdmin affichée ailleurs est distincte ; confirmez avec le prestataire un éventuel proxy ou serveur différent.
- Ouvrez phpMyAdmin depuis l’accès privé fourni par votre hébergeur, pour le serveur utilisé par WordPress.
- Vérifiez la connexion choisie et sélectionnez la base attendue, sans modifier
wp-config.php. - Ouvrez l’onglet SQL. Remplacez le contenu de sa zone par la seule requête présentée ci-dessous.
- Cliquez sur Exécuter et conservez la chaîne complète renvoyée, avec le type MySQL ou MariaDB.
- Comparez ce résultat au message initial et aux exigences de la version WordPress cible. Si le serveur ne correspond pas, arrêtez ici et faites confirmer l’association.
SELECT VERSION() AS version_serveur;Séparer minimum accepté, recommandation et support
Un contrôle d’installation vérifie les seuils de la version WordPress utilisée. Les recommandations d’hébergement visent un environnement plus adapté à l’exploitation actuelle. Enfin, le cycle de support du moteur détermine si sa branche reçoit encore des corrections. Satisfaire un minimum ancien ne répond pas automatiquement à ces trois besoins.
Au 3 novembre 2026, la page officielle des recommandations WordPress indique PHP 8.3 ou supérieur, MariaDB 10.11 ou supérieur, ou MySQL 8.0 ou supérieur, ainsi que HTTPS. Ces repères sont à recontrôler avant une évolution future. Ils ne constituent pas une garantie de compatibilité pour chaque extension.
Choisissez avec le prestataire une branche maintenue et compatible avec la version WordPress cible et vos composants. La version la plus élevée proposée n’est pas nécessairement le meilleur premier essai pour un ancien site. Une branche en correctifs de sécurité seuls ne possède pas le même horizon qu’une branche en support actif.
Gardez le minimum exact annoncé par votre installation pour expliquer le refus. Ne réutilisez pas les numéros d’un ancien tutoriel comme recommandation de déploiement.
Comparez aussi la ligne de votre version WordPress cible dans la matrice officielle PHP/WordPress. Une combinaison supportée par le cœur ne valide pas tous vos thèmes et extensions. Notez donc trois conclusions séparées dans votre relevé : seuil du refus, compatibilité de la version cible et durée de maintenance de la branche PHP retenue.
Choisir entre activation, évolution préparée et migration
La première approche convient lorsque l’offre possède déjà les versions et modules nécessaires, mais que le domaine utilise un ancien réglage. Elle peut répondre à une installation neuve après vérification du répertoire et de l’absence de données à préserver.
La deuxième prépare l’évolution d’un site existant ou du service de base. Elle demande une copie de test, des sauvegardes et un retour documenté. Elle est nécessaire lorsque les données et composants actuels doivent suivre le changement, même si le panneau offre un bouton très simple.
La troisième devient pertinente si le prestataire confirme que l’offre ne peut pas fournir un environnement compatible et maintenu. Il faut alors préparer un transfert ou une autre offre adaptée, sans changer les DNS avant de vérifier la destination.
Commencez sans installer de nouvelle extension WordPress. Un plugin ne met pas à niveau le serveur MySQL et ne remplace pas un module PHP absent au démarrage. Le panneau et l’assistance de l’hébergement sont les premiers moyens de correction.
Approche 1 : sélectionner le bon moteur pour le domaine
Cette manipulation convient si la bonne version est déjà disponible et si le site neuf ou la copie préparée peut l’utiliser. Le compte cPanel doit disposer des droits sur le domaine confirmé. Avant toute application, relevez la version initiale et l’héritage, puis vérifiez que leur rétablissement sera autorisé.
Ne sélectionnez pas tous les domaines du compte. Vérifiez les racines documentaires partagées et la portée avec le prestataire. Si la version nécessaire n’apparaît pas, elle n’est pas disponible pour ce compte ; ne remplacez pas cette sélection par une directive ajoutée dans le thème. MultiPHP Manager ne constitue pas non plus un écran universel d’installation de modules PHP. Relevez l’état PHP-FPM sans le changer pour cet essai ; le mode inherit ne permet pas d’activer PHP-FPM. Une intervention sur ce gestionnaire de processus peut affecter plusieurs domaines partageant la même racine.
Rouvrez le même contrôle d’installation ou Santé du site pour vérifier la version effective. Contrôlez ensuite l’accueil, une page intérieure et l’éditeur sur la copie. Si la version annoncée n’a pas changé, faites identifier le contexte avant une autre modification.
Pour annuler cet essai, revenez à la même ligne et rétablissez la version ou l’héritage initial noté, si ce choix est toujours autorisé, puis Apply et nouveau contrôle. Sinon, utilisez le retour préparé avec le prestataire ; le panneau ne garantit pas de rendre une ancienne branche disponible. Sur un site existant, le basculement en production suit seulement la préparation décrite plus loin. Ce retour PHP n’annule aucune mise à jour de fichiers ou de données effectuée en parallèle.
- Dans cPanel, ouvrez Software, ou Logiciel, puis MultiPHP Manager.
- Retrouvez le domaine exact. Notez la version PHP et l’éventuelle indication Inherited ; faites confirmer les racines partagées.
- Cochez seulement la ligne de ce domaine, puis choisissez la version validée dans PHP Version. Vérifiez une dernière fois la possibilité de retour.
- Cliquez sur Apply. Gardez l’état PHP-FPM relevé ; ne changez pas simultanément ce réglage pour cet essai.
- Rouvrez le contrôle d’installation ou Santé du site, puis vérifiez l’accueil, une page interne et l’éditeur. La version effective doit correspondre à la sélection.
- Si l’essai échoue, rétablissez la version ou l’héritage initial autorisé sur cette même ligne, puis Apply. Si ce choix a disparu, utilisez le retour prévu avec le prestataire.
Vérifier les modules PHP sans changer WordPress
Un message indiquant que le module MySQL manque peut viser mysqli, l’interface utilisée pour communiquer avec la base dans une installation WordPress habituelle. Cela ne signifie pas que vous devez installer une extension WordPress appelée MySQL ni recréer toutes les tables.
Faites confirmer les modules chargés pour la version PHP du domaine et ceux exigés par la version WordPress ou le composant concerné. Un module activé pour une autre version ou pour le terminal ne garantit pas sa présence dans le site web.
Le prestataire active uniquement les modules nécessaires et pris en charge par sa configuration, puis vérifie leur chargement dans le bon contexte. Si un panneau de sélection est fourni, suivez sa procédure pour cette offre plutôt qu’une liste de cases issue d’un autre hébergement. Notez les choix précédents et les dépendances avant validation.
Une bibliothèque de traitement d’images absente et un module indispensable à la connexion de base ne provoquent pas le même effet. Reprenez le message précis. Si le refus persiste, demandez le nouveau résultat du contrôle plutôt que d’activer tous les modules disponibles.
Approche 2 : préparer l’évolution d’un site existant
Créez avec le responsable une copie protégée qui reproduit les composants et les données utiles, puis préparez l’environnement cible. Vérifiez la base distincte et la neutralisation des effets externes avant de l’ouvrir. Une copie sur un moteur différent ne reproduit pas forcément toutes les conditions actuelles ; documentez ces différences.
Mettez les composants en conformité avec leurs exigences et leur procédure de mise à jour. Vérifiez la compatibilité de leurs versions avec PHP et WordPress prévus. Ne désactivez pas un composant essentiel puis ne considérez pas comme validé un site qui ne réalise plus sa fonction.
Testez d’abord le changement PHP isolément lorsqu’il est possible de le séparer. Une modification simultanée du thème, du moteur, de la base et des adresses empêcherait d’attribuer un échec à sa cause. Gardez une trace des étapes et du dernier état fonctionnel.
Si une incompatibilité apparaît, conservez son message et faites corriger ou remplacer le composant concerné dans ce contexte. Un ancien moteur non maintenu ne doit pas devenir une solution définitive simplement parce qu’il masque cette incompatibilité.
Confier la mise à niveau de la base au bon responsable
Le service MySQL ou MariaDB appartient souvent à l’infrastructure de l’hébergeur. Sur un compte partagé, sa mise à niveau peut dépasser votre seul site. Demandez la version cible, le chemin de mise à niveau prévu, la sauvegarde adaptée et la portée de l’intervention avant toute décision.
Changer la version de PHP ne met pas à niveau ce service de base. Inversement, migrer la base ne charge pas un module PHP absent. Gardez les deux vérifications séparées afin de savoir quel refus doit disparaître après chaque correction.
Une évolution de moteur de base peut modifier des structures internes et ne pas permettre un simple retour vers l’ancienne version. Le prestataire doit préparer une restauration ou un autre retour pris en charge. Ne vous contentez pas d’une promesse de « downgrade » sans explication des données préservées et de la fenêtre d’écriture.
MySQL et MariaDB sont deux produits distincts. Un passage de l’un à l’autre exige sa propre vérification de compatibilité et de transfert. Ne le traitez pas comme une modification de numéro dans le panneau, et n’exécutez pas une commande de conversion trouvée dans un forum.
Approche 3 : changer d’environnement si l’offre ne convient pas
Si le prestataire confirme qu’il ne peut pas fournir les versions ou modules nécessaires, demandez d’abord s’il peut déplacer le site vers un environnement compatible dans son service. Une autre offre ou un autre hébergement peut devenir nécessaire, mais la décision doit reposer sur la contrainte exacte.
Avant un achat ou un transfert, faites confirmer les moteurs réellement disponibles pour votre site, leur maintenance et les modules nécessaires. Vérifiez aussi les accès de migration, les sauvegardes, la capacité utile et la méthode de sortie. Une mention commerciale « compatible WordPress » ne décrit pas tous les besoins de vos composants.
Préparez la destination sans remplacer la production. Faites contrôler le site copié dans un accès protégé adapté, avec une base distincte et les effets externes neutralisés. Ne modifiez pas les DNS simplement pour découvrir si le transfert a réussi.
Gardez l’hébergement de départ et les sauvegardes jusqu’à validation. Si la nouvelle destination échoue, vous devez savoir comment revenir au service prévu et quelles données récentes risquent de manquer. Ne supprimez pas le compte d’origine dès que la première page s’affiche ailleurs.
Distinguer compatibilité et problèmes de transfert
Une destination aux bonnes versions peut encore présenter une erreur de connexion de base si les accès, la base sélectionnée ou son hôte ne correspondent pas. Utilisez alors le diagnostic de connexion à la base, en conservant les valeurs sensibles dans les outils privés du responsable.
Si l’assistant apparaît à la place d’anciens articles, arrêtez l’installation. Il faut confirmer les données et leur association, pas créer de nouvelles tables pour faire disparaître l’écran. Un prérequis satisfait ne prouve pas que la bonne base a été importée.
Si le navigateur télécharge un fichier PHP, faites contenir l’exposition possible par l’hébergeur et suivez le guide consacré à ce symptôme. La sélection d’une version récente ne garantit pas, à elle seule, que les demandes sont acheminées au moteur.
Après un transfert, vérifiez aussi les adresses et le certificat du domaine réellement utilisé. Une erreur de nom HTTPS et une exigence de version sont deux diagnostics différents. Ne désactivez pas la validation du certificat pour poursuivre la recette d’installation.
Valider les prérequis dans le bon environnement
Après modification, relevez de nouveau les versions complètes et les modules dans le contexte qui échouait. Vérifiez le domaine et le serveur de base utilisés. Un numéro récent dans le panneau ne suffit pas si WordPress continue à atteindre l’ancien service.
Pour une installation neuve confirmée comme telle, reprenez l’assistant prévu et vérifiez que le refus de prérequis a disparu avant de poursuivre la création du site. Pour un site existant, vérifiez son démarrage et ses données ; n’ouvrez pas une nouvelle installation pour prouver simplement que le moteur fonctionne.
Conservez les éventuels nouveaux messages. Une incompatibilité de composant ou une connexion de base refusée après le changement demande une analyse distincte, pas la suppression du contrôle initial. Le support doit pouvoir comparer l’avant et l’après à partir des mêmes informations.
Si le résultat n’est pas satisfaisant, appliquez le retour préparé. Ne présumez pas qu’une baisse de version de moteur restaurera les données ou qu’un changement de fichier de configuration annulera une mise à niveau déjà exécutée sur la base.
Contrôler les fonctions utiles avant la mise en service
Sur la copie ou dans le parcours de validation autorisé, ouvrez l’accueil, une page interne et l’administration habituelle. Vérifiez les ressources, les liens et la connexion. Un site qui charge sa page d’accueil peut encore échouer dans l’éditeur ou le traitement des médias.
Utilisez un brouillon de contrôle pour confirmer l’enregistrement, puis rouvrez-le. Si le projet nécessite une fonction spécialisée, préparez son essai dans un contexte qui neutralise les paiements et envois externes. Ne concluez pas à partir de la seule activation d’une extension.
Après une migration, le responsable doit contrôler les données attendues et les écritures récentes avant la bascule définitive. La méthode dépend de l’activité : une boutique ouverte ne se synchronise pas comme un site vitrine inchangé. Gardez un point de retour et les conditions de fermeture de l’ancien service.
Retirez les diagnostics temporaires et vérifiez que la copie ne reste pas exposée. Conservez les sauvegardes et le compte rendu jusqu’à validation du site et des opérations nécessaires.
Conserver les exigences du projet et les échéances
Votre dossier de support doit contenir le message exact, la version WordPress cible, les versions PHP et de base relevées, les modules concernés et le domaine. Ajoutez la portée du changement, les composants importants, les sauvegardes disponibles et les résultats du test sur copie.
Demandez au prestataire de distinguer ce qui est disponible immédiatement, ce qui exige une intervention et ce qui dépasse l’offre. Faites préciser les éventuels coûts avant un changement commercial, sans supposer qu’un achat remplace la résolution d’une mauvaise association de domaine.
Gardez les exigences documentées des composants et les dates de fin de support des moteurs retenus. Prévoyez une évolution avant leur expiration, avec un contrôle de compatibilité à chaque étape. Une installation qui fonctionne aujourd’hui sur une branche ancienne ne garantit pas sa maintenance future.
À la prochaine modification, vérifiez de nouveau les sources officielles et l’environnement réellement chargé. Les recommandations évoluent. Le repère durable reste un site compatible, maintenu et vérifié dans ses usages réels, avec une procédure de retour proportionnée aux changements effectués.
