WP-CLI échoue avec un autre PHP : corriger le contexte du terminal

Comprendre pourquoi le site Web et WP-CLI divergent

Le site s’affiche normalement, mais une commande WP-CLI annonce un PHP trop ancien, un module manquant ou une erreur de syntaxe incompatible avec la version indiquée dans l’hébergement. Les deux observations peuvent être exactes : le serveur Web et le terminal ne sont pas obligés d’utiliser le même exécutable PHP ni la même configuration.

WP-CLI est un outil de maintenance en ligne de commande. Son lanceur doit d’abord trouver un moteur PHP, puis ce moteur charge sa configuration et les composants nécessaires à l’opération. Changer la version PHP d’un domaine dans un panneau ne modifie pas forcément le programme appelé par votre session SSH ou par un planificateur.

L’objectif est de faire utiliser au terminal un environnement compatible et identifié, sans dégrader celui du site qui fonctionne. Nous allons comparer les contextes, choisir le bon exécutable pour un essai limité, puis vérifier les fichiers INI et les modules. Une mise à jour générale du système, une réinstallation de WordPress ou une désactivation massive d’extensions ne constitue pas le premier contrôle adapté à ce symptôme.

Confirmer le compte, le serveur et l’installation

Le parcours suppose un accès terminal autorisé à l’hébergement et WP-CLI déjà disponible. Les exemples de lancement concernent un shell de type Unix, souvent utilisé par SSH sous Linux. Ils ne doivent pas être collés tels quels dans PowerShell ou dans un champ de code PHP. Si l’hébergeur fournit un lanceur spécifique, conservez son circuit prévu et faites confirmer ses paramètres.

Avant de tester, notez l’hôte, le compte technique et le chemin de l’installation. Un terminal ouvert sur une copie ne décrit pas automatiquement la production. Dans un réseau multisite, le choix du sous-site est encore un contexte distinct ; changer PHP ne sélectionne ni la bonne base ni le bon sous-site.

Sur WordPress.com ou un hébergement géré, vérifiez que votre site dispose réellement de l’accès terminal prévu par la plateforme. Si cet accès ou le choix du binaire n’est pas disponible, demandez le contexte CLI pris en charge ; ne modifiez pas le PHP Web pour compenser un terminal auquel vous n’avez pas accès.

1. Conservez le message exact de la commande en échec et l’heure de son exécution.
2. Vérifiez le serveur et le chemin des fichiers concernés avec votre procédure d’hébergement.
3. Identifiez le mode d’installation de WP-CLI : Phar, Composer, dépôt ou lanceur géré.
4. Réservez les premiers essais aux informations de contexte. Ne relancez pas immédiatement une mise à jour, une restauration ou un traitement susceptible d’avoir déjà produit un effet.

Lire le PHP réellement employé par WP-CLI

Commencez par wp --info, qui fournit des informations avant le chargement normal de WordPress. Relevez le chemin du binaire PHP, sa version, la limite mémoire, le fichier INI utilisé et les chemins de configuration WP-CLI. Ce relevé est plus utile qu’un simple numéro de version affiché dans le panneau du domaine.

La commande décrit le contexte du lanceur appelé à cet instant. Elle ne teste pas toutes les fonctions du site et ne garantit pas qu’une opération métier réussira. Sur un environnement personnalisé, les configurations du lanceur et ses composants doivent rester connus et de confiance. Gardez le relevé privé, car il expose des chemins internes.

Si même cet affichage échoue avec une erreur d’interpréteur, conservez ce message et passez à l’identification du lanceur. Si l’information s’affiche et indique un PHP différent de celui du Web, la divergence est confirmée ; ne modifiez pas encore la configuration globale. Le résultat attendu de cette première étape est de savoir quel programme et quel INI sont réellement en cause, avant de choisir comment les corriger.

wp --info

Comparer avec le PHP du domaine et le PHP de la session

Dans WordPress, si vous disposez des droits nécessaires, ouvrez Outils > Santé du site > Informations > Serveur. Relevez la version PHP et les informations disponibles pour le domaine. Complétez avec le réglage privé de l’hébergement lorsque le mode d’exécution ou la configuration active doivent être confirmés.

Dans le terminal, les commandes ci-dessous décrivent le PHP trouvé sous le nom php dans cette session : version, fichiers INI et modules chargés. Lancez-les séparément. Leurs résultats peuvent encore différer de wp --info si le lanceur WP-CLI choisit explicitement un autre exécutable. Cette différence est une information de diagnostic, pas une incohérence à masquer.

Comparez les versions complètes et les chemins. Une même version principale peut utiliser d’autres modules ou d’autres réglages selon le contexte. N’affichez pas toute la configuration ou toutes les variables d’environnement dans un ticket public. Les chemins et les modules pertinents suffisent pour demander un exécutable CLI compatible au prestataire.

php --version
php --ini
php -m

Identifier le lanceur avant de choisir la commande de correction

Le nom wp peut désigner un fichier Phar, un script de lancement, un lien ou un outil fourni par l’hébergeur. Le shell peut aussi utiliser un alias. Il faut identifier ce qui est réellement appelé avant de passer ce chemin à PHP. Un script shell ne devient pas un programme PHP parce qu’il porte le nom wp.

Dans le shell de type Unix concerné, les commandes ci-dessous indiquent ce que les noms résolvent dans cette session. Conservez le résultat en privé et faites vérifier le lanceur si son contenu ou son origine est inconnu. Ne recherchez pas récursivement tous les fichiers du serveur pour deviner une autre installation.

Un fichier Phar est une archive exécutable par PHP ; le chemin de ce fichier de confiance peut être utilisé directement avec le bon binaire. Pour une installation Composer ou issue du dépôt, le lanceur officiel peut gérer le choix de PHP autrement. Un lanceur propriétaire peut imposer un conteneur ou des paramètres supplémentaires. Dans ce dernier cas, utilisez sa procédure au lieu de contourner son environnement en pointant vers un fichier trouvé au hasard.

command -v wp
command -v php

Lancer un Phar connu avec un PHP explicitement choisi

Cette voie convient lorsque vous connaissez le fichier wp-cli.phar installé et de confiance, ainsi que le chemin d’un exécutable PHP CLI compatible fourni par l’hébergement. Les chemins ci-dessous sont des exemples à remplacer ; ne téléchargez pas une nouvelle archive pour résoudre une simple sélection d’exécutable.

Commencez par la version et l’INI du binaire choisi. Appelez ensuite le même binaire avec le Phar et --info. Les guillemets conservent un éventuel espace dans chaque chemin. Ce lancement ne change pas le PHP global du compte ni celui du domaine ; il sélectionne le programme pour cet appel précis.

1. Faites confirmer le chemin du PHP CLI prévu pour cette installation et ses modules nécessaires.
2. Vérifiez sa version puis ses fichiers de configuration avec les deux premières lignes.
3. Remplacez le chemin du Phar par celui du fichier de confiance déjà identifié.
4. Lancez la troisième ligne et comparez son résultat avec le relevé initial.
5. Si ce PHP ne démarre pas ou charge des modules incompatibles, conservez l’erreur et revenez au contexte initial sans modifier le site.

'/chemin/vers/php' --version
'/chemin/vers/php' --ini
'/chemin/vers/php' '/chemin/vers/wp-cli.phar' --info

Choisir PHP pour un appel non-Phar compatible

Pour une installation non-Phar utilisant le lanceur officiel compatible, la variable WP_CLI_PHP permet de désigner le binaire voulu. Elle ne constitue pas une solution universelle pour tout fichier nommé wp, et la documentation ne la présente pas comme un choix d’interpréteur pour un Phar exécuté directement.

L’exemple ci-dessous définit cette variable pour un seul appel dans un shell de type Unix. Remplacez le chemin de PHP et celui du lanceur par les chemins confirmés. Il ne modifie pas durablement le profil de votre session ni celui des autres utilisateurs. Le résultat attendu est que --info annonce le binaire et la configuration prévus.

Si le lanceur ignore ce choix ou produit une erreur, ne répétez pas la définition dans plusieurs fichiers. Revenez à son mode d’installation et à sa documentation. Un outil géré par l’hébergeur peut demander une autre commande. Gardez aussi les arguments PHP existants qui sont nécessaires au fonctionnement prévu ; n’en ajoutez pas pour désactiver une protection ou masquer un module manquant. La correction durable pourra être préparée après cet essai limité, avec un retour arrière clair.

WP_CLI_PHP='/chemin/vers/php' '/chemin/installation/wp-cli/bin/wp' --info

Corriger uniquement la configuration CLI concernée

Si le bon exécutable est utilisé mais que le défaut persiste, comparez ses fichiers INI. Avec le chemin absolu du PHP retenu, l’option --ini indique le fichier chargé et les fichiers supplémentaires analysés. Une version correcte avec une configuration CLI incomplète peut manquer d’un module ou utiliser une limite différente de celle du Web.

La configuration .user.ini d’un dossier Web ne s’applique pas de la même manière au PHP CLI : elle concerne les modes CGI et FastCGI qui la prennent en charge. Modifier ce fichier pour résoudre une commande en terminal peut donc ne rien changer. À l’inverse, copier aveuglément le fichier INI de PHP-FPM vers le terminal peut introduire des chemins ou modules inadaptés.

Conservez une copie privée du fichier CLI avant une correction autorisée. Faites identifier la directive ou le module nécessaire pour le binaire exact, puis modifiez uniquement sa configuration selon le mécanisme de l’hébergement. Une nouvelle invocation PHP reprend normalement son contexte de démarrage ; il n’est pas nécessaire de redémarrer le serveur Web pour chaque lecture CLI. Vérifiez de nouveau les informations et gardez l’état antérieur pour annuler si un autre outil du même compte est affecté.

À partir de cette étape, remplacez le nom court php des contrôles précédents par le chemin absolu validé. Sinon, vous pourriez examiner de nouveau l’ancien moteur trouvé dans la session et modifier le mauvais INI. Faites de même pour -m lorsque vous comparez les modules du PHP choisi.

Traiter un module absent et une limite différente séparément

Si l’erreur cite une fonction MySQL manquante, une extension PHP désactivée ou une bibliothèque incompatible, comparez les modules du binaire choisi. Une extension PHP est un composant du moteur ; installer une extension WordPress ne fournit pas automatiquement ce module au terminal.

Faites activer le module compatible dans la configuration du PHP CLI prévu, ou utilisez l’exécutable complet fourni pour cet usage. Ne copiez pas une bibliothèque d’une autre version de PHP et ne chargez pas tous les modules disponibles pour chercher celui qui ferait disparaître le message. Le diagnostic doit relier la fonction absente à son module et à sa version.

Une erreur mémoire réclame aussi un examen distinct. Une limite CLI différente peut expliquer l’écart avec le Web, mais une hausse sans borne ne corrige pas un traitement qui grossit anormalement. Vérifiez d’abord le besoin et le périmètre de la commande, puis utilisez un réglage adapté et documenté si nécessaire. Après correction, relisez le message actuel : la disparition du refus de version peut révéler un autre échec, qui ne se résout pas en choisissant encore un nouvel exécutable.

Reproduire le contexte d’une tâche planifiée

Une commande peut fonctionner dans votre session interactive et échouer dans un planificateur. Le compte, le répertoire courant, les chemins de programmes et les fichiers de profil chargés peuvent différer. Le succès manuel ne valide donc pas automatiquement l’environnement de la tâche existante.

Dans le planificateur réellement utilisé, relevez la commande, son compte et son répertoire de travail, sans publier de secret. Faites préparer une version de contrôle qui affiche seulement les informations de contexte avec les chemins absolus confirmés. Ne remplacez pas immédiatement une tâche de paiement, d’import ou d’envoi par plusieurs essais concurrents.

Si le choix explicite de PHP et du lanceur résout le problème, appliquez cette correction au seul job concerné selon sa procédure de gestion. Conservez la définition précédente et vérifiez le prochain passage contrôlé. Un alias ajouté à votre terminal personnel ne sera pas forcément connu du planificateur. Pour une tâche qui peut créer ou modifier des données, vérifiez également l’état laissé par l’échec précédent avant de reprendre son exécution métier. La preuve recherchée reste le même contexte PHP, pas seulement l’absence d’un message dans votre session.

Valider progressivement sans relancer la commande sensible

Après sélection du bon environnement, commencez par comparer --info. Vérifiez ensuite une lecture simple des fichiers WordPress avec la version du cœur, sur le chemin confirmé. L’exemple ci-dessous reprend la voie Phar ; si vous utilisez un autre mode, conservez son lanceur validé au lieu de mélanger les deux formes.

Cette lecture de version ne charge pas toutes les fonctions de WordPress et ne prouve pas la réussite de la commande initiale. Elle vérifie néanmoins que le programme peut lire les fichiers de la bonne installation avec le PHP choisi. Si la version affichée ne correspond pas au site attendu, arrêtez la progression et corrigez la cible.

1. Confirmez le binaire, la version et l’INI annoncés dans le contexte corrigé.
2. Remplacez le chemin WordPress de l’exemple par celui de la copie ou du site autorisé.
3. Lisez la version et comparez-la à la livraison attendue.
4. Préparez ensuite une lecture ou une simulation réellement proposée par la commande initiale, sur la copie si son chargement a des effets externes.
5. Reprenez l’opération métier uniquement après vérification de son état, de sa sauvegarde et de son périmètre.

'/chemin/vers/php' '/chemin/vers/wp-cli.phar' core version --path='/chemin/vers/wordpress'

Changer de piste si les environnements concordent

Si le PHP, la configuration et les modules sont cohérents, le défaut peut venir de l’étape suivante : mauvais chemin, accès à la base, code chargé ou composant du lanceur. Conservez le premier message significatif plutôt que de continuer à modifier le moteur alors que l’écart initial est corrigé.

Une erreur dans une extension indispensable peut encore survenir même lorsqu’un lancement demande de sauter les extensions ordinaires. Les options de chargement ont des limites ; elles ne rendent pas tous les environnements équivalents et ne suppriment pas tous les fichiers de démarrage. Faites identifier le fichier cité et son propriétaire avant de le déplacer ou de le modifier.

Aucune nouvelle extension WordPress n’est nécessaire pour choisir le PHP de WP-CLI. Une extension installée dans le tableau de bord ne remplace pas l’exécutable du terminal. Utilisez les informations du lanceur et les outils PHP natifs, puis le parcours propre au nouvel échec si les indices l’exigent. Si l’hébergement impose son environnement CLI, transmettez les différences relevées et demandez le lanceur compatible prévu, sans changer les liens système ni les profils de tous les comptes.

Annuler le test et conserver un lanceur documenté

Un appel explicite ou une variable limitée à une invocation ne change pas durablement le système : pour revenir au contexte initial, cessez d’utiliser cette forme et conservez le relevé comparatif. Si un fichier INI, un profil ou une tâche a été modifié ensuite, restaurez seulement son réglage précédent, en tenant compte des autres changements intervenus depuis.

Vérifiez que les fonctions Web qui marchaient avant l’intervention fonctionnent encore. Ne remplacez pas globalement le binaire php ou un lien système pour régler un seul site sans évaluer les autres utilisateurs. Une correction locale au lanceur ou au job est plus facile à vérifier et à annuler lorsqu’elle répond au besoin confirmé.

Documentez les chemins du PHP et de WP-CLI, le mode d’installation, la configuration CLI et la procédure de contrôle. Ajoutez qui maintient ces composants et comment ils évolueront avec le site. Pour un défaut restant, transmettez le message expurgé, les versions complètes et les différences entre le Web, la session et le planificateur. Ce dossier permet de corriger le contexte réel sans demander une nouvelle fois de changer la version PHP du domaine alors que celui-ci fonctionne déjà.