Identifier ce qui empêche réellement l’activation
WordPress refuse d’activer une extension parce que votre version de PHP ou de WordPress ne satisfait pas ses exigences. Ce contrôle évite de charger un composant dans un environnement déclaré incompatible. Le résultat recherché est une activation sur une combinaison prise en charge, suivie d’un contrôle de la fonction, pas le contournement du message.
Conservez le texte complet : il peut citer PHP, WordPress, les deux, ou une dépendance manquante. Un avertissement « non testée avec votre version » n’est pas identique à un minimum non atteint. Une erreur fatale pendant le chargement demande encore un autre diagnostic ; elle peut survenir même lorsque les minimums déclarés sont respectés.
Le guide vise un site autohébergé avec une extension identifiée. L’administrateur WordPress peut examiner ses versions et préparer une mise à jour du cœur ; la version de PHP dépend de l’hébergement. Sur un réseau multisite, le changement PHP concerne potentiellement tous les sites utilisant cette installation. Faites valider son périmètre avec l’administrateur du réseau avant de préparer la bascule.
Relever les versions effectivement utilisées par le site
Commencez dans Outils, Santé du site, Informations. Relevez la version de WordPress dans sa rubrique et la version de PHP dans Serveur. Ces données proviennent du contexte qui sert l’administration. Un chiffre vu dans une offre commerciale ou dans un autre site du même compte ne suffit pas.
Le panneau d’hébergement peut proposer plusieurs versions de PHP et plusieurs domaines. Certaines installations héritent d’un réglage commun. Notez donc le domaine et l’emplacement de la copie testée avec les deux versions relevées. Si vous utilisez un terminal, son PHP en ligne de commande peut différer de celui du site ; ne remplacez pas le relevé Web par ce seul constat.
- Ouvrez les informations du bon site et relevez WordPress, PHP et l’heure du contrôle.
- Dans Extensions installées, notez la version exacte du paquet refusé et son état actuel.
- Comparez ces valeurs au message d’activation. Si le panneau et le site affichent des versions différentes, faites clarifier le rattachement du domaine avant de modifier PHP.
- Gardez ce relevé comme point de comparaison après chaque changement. Cette observation n’active aucune extension.
Lire les exigences du paquet concerné
Consultez la fiche officielle et la documentation de la version précise de l’extension. Requires at least désigne son minimum WordPress et Requires PHP son minimum PHP. Tested up to indique la version WordPress déclarée comme testée ; ce champ ne constitue ni un minimum ni une garantie pour toutes les combinaisons possibles.
Les exigences du paquet installé peuvent différer de celles d’une autre version présentée sur le site de l’auteur. WordPress lit les indications du fichier PHP principal pour ses contrôles de prérequis. Si une copie locale et sa fiche semblent se contredire, vérifiez produit, édition et version auprès de l’auteur. Ne changez pas l’en-tête pour rendre le message plus favorable.
Exemple fictif : un paquet demande WordPress 7.0 et PHP 8.3, alors que le site utilise WordPress 6.9 et PHP 8.2. Deux exigences restent à satisfaire ; changer seulement PHP ne règle pas le minimum WordPress. Ce raisonnement sert à choisir les étapes, pas à recommander ces numéros pour tous les sites. La version cible doit aussi rester maintenue et compatible avec les autres composants.
Préparer une sauvegarde utilisable et une copie représentative
Avant une mise à niveau, sauvegardez les fichiers et la base, puis vérifiez leur disponibilité et le processus de restauration. Notez les versions, les extensions actives et les réglages propres à l’hébergement. Les fichiers d’une ancienne version ne suffisent pas toujours à annuler une migration de base.
Préparez une copie représentative du site, avec le même ensemble de composants. Neutralisez ses paiements, courriels et connexions externes avant les essais. Si cette copie utilise déjà un autre PHP, commencez par noter cette différence : un succès ne prouvera pas que la même combinaison fonctionne sur le serveur public.
Choisissez quelques contrôles utiles au projet : ouverture de session, édition d’un brouillon, affichage d’une page et fonction précise de l’extension. Pour les opérations sensibles, utilisez le mécanisme de test prévu et des données de contrôle. Ne déclenchez pas un achat ou un envoi réel pour prouver une compatibilité. La sauvegarde et cette liste de contrôles doivent être prêtes avant le premier remplacement.
Choisir l’ordre des changements selon la compatibilité commune
Si seule l’exigence WordPress manque et que le PHP actuel convient à la version cible du cœur, commencez par le parcours WordPress. Si seule l’exigence PHP manque, préparez la bascule PHP avec l’ensemble des thèmes et extensions concernés. Lorsque les deux manquent, cherchez une combinaison intermédiaire compatible avant d’imposer un ordre.
La matrice officielle WordPress aide à comparer les générations du cœur et de l’environnement ; elle ne certifie pas chaque extension. Consultez aussi les exigences des composants déjà actifs. Une nouvelle version PHP peut satisfaire le paquet refusé tout en révélant un problème dans un ancien thème. N’en déduisez pas que l’extension à activer est forcément responsable.
Pour un très ancien site sans version intermédiaire commune clairement prise en charge, faites préparer une migration sur copie par son responsable. Une succession de bascules au hasard rendrait le retour plus difficile. Gardez un changement identifié à chaque étape, avec son résultat, avant d’activer le nouveau composant. Ne combinez pas mise à jour globale, changement PHP et activation de plusieurs extensions dans un même essai.
Approche 1 : mettre WordPress à niveau depuis son écran natif
Ce parcours convient si le minimum WordPress du paquet n’est pas atteint et que l’environnement supporte la version cible choisie. Il demande les droits de mise à jour, une sauvegarde restaurable et un accès aux fichiers pour la récupération si nécessaire. Préparez d’abord l’opération sur la copie, puis planifiez-la sur le site actif.
Choisissez une version stable prise en charge, cohérente avec les composants du projet. Atteindre un ancien minimum ne justifie pas de s’y maintenir sans politique de support. Pour un grand saut entre versions, utilisez la procédure de mise à niveau étendue préparée avec le responsable du site plutôt qu’une simple répétition de clics.
- Ouvrez Tableau de bord, puis Mises à jour, et vérifiez la version proposée pour le cœur.
- Lancez la mise à jour préparée avec le bouton correspondant à cette version. Ne choisissez pas une réinstallation de la version actuelle pour modifier son minimum.
- Attendez la fin et suivez l’éventuelle mise à niveau de base proposée.
- Revenez dans Santé du site, Informations pour relever la version obtenue. En cas d’échec de téléchargement ou d’accès aux fichiers, conservez ce nouveau message et traitez cette étape avant de poursuivre.
Vérifier WordPress avant de reprendre l’activation
Après la mise à jour du cœur, contrôlez d’abord l’administration et les pages représentatives avec les composants déjà utilisés. Vous pourrez ainsi distinguer un problème de mise à niveau d’un problème révélé par la nouvelle activation. Si le site ne fonctionne plus à cette étape, gardez l’extension visée inactive et appliquez le plan de récupération.
Une fois ce contrôle réussi, ouvrez Extensions installées et retrouvez le paquet concerné. L’activation est une action réelle : le composant peut créer des tables, des réglages ou des tâches. Le mécanisme de contrôle d’erreurs de WordPress n’est pas une copie isolée de votre base et ne garantit pas l’annulation de tous ces effets.
- Vérifiez le nom et la version de l’extension, puis cliquez sur Activer pour elle seule.
- Lisez le résultat. Si PHP ou une dépendance reste insuffisant, conservez ce message et préparez le parcours correspondant.
- Si l’activation aboutit, vérifiez la fonction prévue avec les données de contrôle préparées.
- Si une erreur nouvelle apparaît, notez-la et désactivez ce seul nouveau composant depuis sa ligne lorsque l’administration reste accessible. Une désactivation ne supprime pas automatiquement les données déjà créées.
Approche 2 : choisir une version PHP encore maintenue
Ce parcours concerne une exigence PHP non satisfaite. PHP est le moteur qui exécute le code du site ; sa version se change dans l’hébergement, pas en modifiant un numéro dans WordPress. Choisissez une branche maintenue, compatible avec le cœur, le thème et les extensions, puis faites confirmer les modules PHP nécessaires.
WordPress recommande actuellement PHP 8.3 ou plus pour l’hébergement. Cette recommandation ne remplace pas l’exigence spécifique du paquet ni le calendrier officiel de PHP. Une branche peut ne plus recevoir de corrections ordinaires tout en recevant encore des correctifs de sécurité. À l’inverse, un vieux minimum accepté par une extension ne constitue pas une recommandation de maintien sur une branche abandonnée.
Avant la bascule, relevez la version précédente et vérifiez comment la rétablir si l’essai échoue. Assurez-vous que cette version restera autorisée pour votre compte pendant l’intervention ; son affichage initial ne garantit pas toutes les possibilités de retour. Si vous n’avez pas le droit de changer PHP ou si la version cible n’est pas proposée, faites préparer cette seule intervention par le prestataire.
Changer PHP pour le domaine concerné dans cPanel
Avec cPanel, utilisez Software puis MultiPHP Manager. Ce parcours demande que la cible ait été validée sur la copie avec les composants du site. Relevez le domaine, sa version et un éventuel état hérité avant de modifier quoi que ce soit. Les versions proposées dépendent du serveur et des droits du compte.
Ne sélectionnez pas tous les domaines pour corriger un seul site. Le réglage global du système et l’activation de PHP-FPM peuvent relever de l’administrateur WHM. Ils ne sont pas nécessaires à ce simple choix de version ; ne les modifiez pas en même temps pour essayer de rendre l’activation possible.
- Sélectionnez la case du domaine exact à modifier et vérifiez son nom.
- Dans PHP Version, choisissez la version maintenue et compatible préparée.
- Cliquez sur Apply et attendez le résultat du panneau.
- Revenez dans Outils, Santé du site, Informations, Serveur sur le site concerné et relevez le PHP effectivement utilisé.
- Si le résultat ne correspond pas au choix, faites vérifier l’association domaine, répertoire et processus PHP ; ne basculez pas d’autres domaines pour obtenir un chiffre différent.
Contrôler le site après la bascule PHP avant d’activer le paquet
Reprenez d’abord les contrôles avec les composants qui fonctionnaient avant l’incident. Ouvrez l’accueil, une page et l’administration ; vérifiez aussi une opération d’édition préparée. Comparez le résultat à la copie testée. Si une fonction déjà utilisée casse immédiatement après la bascule, gardez la nouvelle extension inactive pendant l’analyse.
Relevez une erreur précise et son heure dans les journaux privés disponibles. Une fonction PHP manquante peut renvoyer à un module de l’environnement ; une erreur de syntaxe peut révéler un composant incompatible avec la branche choisie. La version du moteur ne décrit pas tout son environnement. Faites comparer les modules et réglages pertinents par le responsable plutôt que changer plusieurs paramètres sans lien.
Lorsque le site est stable avec la version cible, retournez dans Extensions installées et activez le seul paquet concerné. Contrôlez la fonction prévue, puis les pages utiles. Le succès d’activation signifie que cette étape a abouti ; il ne prouve pas que toutes les interactions entre le composant, le thème et les extensions ont été couvertes.
Revenir à la version PHP précédente si le contrôle échoue
Le retour de PHP restaure un moteur, pas l’état de la base. Si une activation ou une mise à jour a déjà transformé des données, préparez la récupération correspondante avant d’écraser une sauvegarde. Conservez les ajouts récents. Ne présentez pas la remise d’un numéro comme un retour complet du site.
Si la nouvelle extension a été activée et exige le PHP cible, désactivez-la avant le retour lorsque l’administration reste accessible. Sinon elle pourrait ne plus se charger correctement sous l’ancienne branche. Si l’accès a disparu, faites préparer la désactivation du composant concerné et la récupération avec le responsable avant la bascule.
- Dans cPanel, revenez à Software, MultiPHP Manager et sélectionnez le même domaine.
- Choisissez la version précédente relevée, si elle est toujours autorisée, puis Apply.
- Vérifiez la version effective dans Santé du site et refaites les contrôles de base.
- Si le retour n’est pas proposé ou échoue, transmettez les valeurs initiale et cible au prestataire. Un retour temporaire sur une branche ancienne n’annule pas la nécessité de préparer une combinaison maintenue.
Distinguer dépendance manquante et erreur malgré les minimums
Un message peut nommer une autre extension requise, installée mais inactive ou absente. Traitez alors cette dépendance exacte selon la documentation du produit. Vérifiez son éditeur et sa version avant une installation, ses propres prérequis et les effets de son activation. Un nom approchant dans le répertoire n’est pas une preuve qu’il s’agit du bon composant.
Si les minimums de WordPress et PHP sont satisfaits mais qu’une erreur fatale apparaît, le contrôle déclaré n’a pas suffi à garantir l’exécution. Relevez le composant et le message précis dans le mécanisme de récupération ou le journal privé. Gardez les versions obtenues et l’ordre des changements pour distinguer conflit, module manquant et défaut du paquet.
Ne baissez pas Requires PHP ou Requires at least dans le fichier principal et ne contournez pas les contrôles par un autre outil d’activation. Cela ne rend pas le code compatible avec les fonctions absentes. Laissez le paquet inactif, préservez les observations et obtenez une correction ou une procédure validée de son auteur. Si l’administration reste accessible, désactivez ce seul nouveau composant avant de préparer la suite.
Séparer le refus de WordPress d’une erreur pendant le chargement
Ouvrez Outils > Santé du site > Informations > Serveur et relevez la version PHP affichée par le site qui refuse l’extension. Comparez-la au champ Requires PHP de la version précise du paquet. Le PHP du terminal peut différer de celui utilisé par le domaine. Si vous transmettez un relevé, indiquez comment chaque version a été obtenue et gardez le nom du domaine ou du sous-domaine de recette.
Lorsque WordPress affiche un minimum PHP non satisfait, il peut arrêter l’activation avant de charger le fichier principal. Relevez le texte exact et vérifiez que le module reste inactif dans Extensions. Lorsque le prérequis est accepté mais que l’activation produit une erreur critique, recherchez dans le journal PHP le premier message d’erreur, le fichier et la ligne. Un appel à une fonction absente, une erreur de syntaxe et une dépendance manquante ne demandent pas la même correction. Ne baissez pas l’exigence inscrite dans le paquet pour rendre le bouton accessible.
Après une bascule PHP sur la copie, rouvrez Santé du site pour vérifier que le changement concerne bien le domaine voulu. Testez la page publique et l’administration avant d’activer l’extension. Une activation réussie doit ensuite être suivie d’un contrôle de la fonction que vous comptez utiliser.
Observer les deux résultats sur une copie WordPress
La recette a utilisé une même installation WordPress 7.1.4 et deux petits paquets fictifs. Les deux appellent get_error_handler() pendant l’activation. Cette fonction est disponible à partir de PHP 8.5 dans le moteur. Le premier paquet déclare PHP 8.5 dans son en-tête. Servi par PHP 8.4.8, WordPress a renvoyé plugin_php_incompatible avant d’inclure le fichier. L’extension est restée inactive et son marqueur de démarrage était absent.
Le second paquet déclare volontairement PHP 8.4. WordPress a chargé le fichier, puis l’appel à la fonction absente a produit une erreur d’exécution. Le marqueur n’a pas été écrit et le paquet est resté inactif. Ce résultat permet de distinguer une exigence annoncée et le code réellement exécuté. Le même fichier a passé le contrôle de syntaxe de PHP 8.4.8. Un fichier syntaxiquement correct peut appeler une fonction que le moteur ne connaît pas encore.
Sur PHP 8.5.12, les deux activations ont produit le marqueur attendu, qui a été retrouvé dans une nouvelle requête. La recette a désactivé les deux témoins avant de relancer le site sous PHP 8.4.8. Les extensions étaient inactives et les marqueurs avaient disparu. Cet essai compare deux moteurs sur le même WordPress et le même contenu. Les deux numéros servent à reproduire le cas. Pour votre site, choisissez la version maintenue qui convient à l’ensemble des composants.
Vérifier la syntaxe et le contexte du terminal
Avec un accès technique, faites ce contrôle sur une copie du paquet et désignez l’exécutable PHP qui correspond à la version à vérifier. Utilisez le chemin du binaire confirmé par l’hébergeur. Remplacez aussi le chemin de l’extension par son fichier principal, celui qui porte l’en-tête. La commande lit ce fichier sans l’exécuter. Si elle annonce une erreur de syntaxe, rapprochez la version du binaire de la ligne signalée. Si elle réussit, reprenez l’activation sur une copie et contrôlez le journal d’exécution. La commande ne reproduit ni les bibliothèques du domaine ni les autres fichiers chargés à l’activation.
"/chemin/vers/php" -v
"/chemin/vers/php" -l "/chemin/recette/wp-content/plugins/exemple/exemple.php"Préparer la correction et son retrait
Si WordPress bloque avant chargement, comparez les exigences de cette version à la combinaison disponible sur la copie. Corrigez le moteur du domaine dans le panneau prévu, ou demandez à l’éditeur un paquet explicitement compatible et maintenu. Si les minimums sont satisfaits mais que le code échoue, gardez l’extension inactive et relevez le premier fichier d’extension ou de dépendance cité par l’erreur. Avec un paquet corrigé, rejouez le même parcours. Le résultat attendu est une activation qui reste valide après rechargement et une fonction utile qui répond correctement.
Avant de revenir à un PHP plus ancien, désactivez l’extension qui vient d’être activée sous la version plus récente, puis vérifiez son état dans Extensions. Si l’administration est inaccessible, faites isoler le seul dossier identifié à partir de la copie ou du gestionnaire de fichiers autorisé. Gardez son nom initial pour le remettre en place après correction. Un changement de PHP ne revient pas sur une migration de données déjà exécutée par un paquet. Si l’activation a modifié des données, rapprochez les opérations effectuées de la sauvegarde avant de décider du retour.
Si l’environnement ne peut pas encore être mis à niveau
Ne remplacez pas la version actuelle du paquet par une ancienne archive trouvée au hasard pour faire disparaître le refus. Une édition plus ancienne peut manquer de correctifs ou demander des migrations différentes. Son accessibilité dans une archive ne prouve pas qu’elle soit encore prise en charge par l’auteur.
Demandez à l’éditeur s’il existe une version maintenue compatible avec votre combinaison exacte, quelles limites elle comporte et comment ses données sont gérées. Conservez cette réponse avec la version du paquet. Si aucune solution prise en charge n’existe, gardez le composant inactif et préparez soit l’évolution de l’hébergement, soit une autre extension répondant au besoin.
Ce choix doit tenir compte de la fonction et des données, pas seulement d’un bouton Activer disponible. Pour un composant de paiement, d’accès membre ou de stockage, préparez la migration et le retour avec son responsable. Il est préférable de différer l’ajout d’une fonction que de maquiller les exigences d’un code dont l’environnement ne fournit pas les capacités nécessaires.
Valider la combinaison et conserver un relevé exploitable
Une fois les contrôles réussis sur la copie, reproduisez les changements préparés sur le site actif dans la fenêtre convenue. Notez WordPress, PHP, la version du paquet et ses dépendances effectivement actives. Vérifiez que le site public n’utilise pas un autre réglage d’hébergement que la copie. Contrôlez les mêmes fonctions avant de clore l’intervention.
Gardez séparément le minimum déclaré, les versions réellement utilisées et les résultats observés. Cela permet d’expliquer un éventuel nouvel incident sans attribuer une compatibilité universelle à un seul essai réussi. Pour l’aide de l’auteur ou du prestataire, joignez le message exact, l’heure, l’étape et les versions, sans mots de passe, clés ni export technique non relu.
Aucune extension de contournement n’est nécessaire à ces parcours. Les menus natifs donnent les versions et permettent la mise à jour du cœur ; le panneau d’hébergement gère PHP. L’issue attendue est une combinaison maintenue et vérifiée pour votre fonction, avec un état précédent documenté et une méthode de récupération adaptée aux changements déjà appliqués.
