Reconnaître une commande qui réussit au mauvais endroit
Une commande WP-CLI peut afficher un résultat plausible alors qu’elle a chargé un autre WordPress. Vous cherchiez les extensions de la préproduction et retrouvez celles du site public, ou l’option affichée correspond à un autre sous-site. Même un message de succès ne confirme que l’exécution sur la cible effectivement chargée. Avant de recommencer une action qui modifie le site, établissez quelle installation a répondu.
Ce guide concerne WordPress autohébergé avec un terminal ou un outil d’exploitation déjà autorisé. Le compte WordPress utilisé dans le navigateur ne donne pas à lui seul accès au serveur. WP-CLI est un outil libre ; les conditions d’accès au terminal, au conteneur ou à un service distant dépendent de l’hébergeur. Aucune nouvelle extension WordPress n’est nécessaire.
Séparez trois questions : sur quelle machine ou dans quel conteneur la commande tourne, depuis quel dossier elle charge le cœur WordPress, et quel site elle sélectionne si ce dossier dessert un réseau multisite. Une erreur à l’un de ces niveaux peut produire la même impression. Le résultat attendu est une lecture reproductible de l’installation voulue avant toute écriture.
Établir la cible attendue à partir d’une source indépendante
Partez du panneau d’hébergement, du dossier de déploiement approuvé ou de la documentation de l’équipe. Il faut une référence connue avant de comparer la sortie du terminal. Si vous retenez comme preuve l’adresse renvoyée par la commande suspecte, vous risquez de confirmer le mauvais site par son propre résultat.
Sur une installation avec un répertoire public et un autre pour le cœur, notez le chemin où WordPress est installé. Il peut être différent du dossier racine de l’URL. Une plateforme peut aussi indiquer un chemin depuis son panneau qui diffère du chemin vu dans le conteneur. Demandez la correspondance lorsqu’elle n’est pas évidente. La présence de wp-admin et wp-includes aide à identifier le cœur, mais une copie de secours peut présenter la même structure.
- Notez l’environnement, le nom d’hôte ou du conteneur et le compte d’exploitation prévus.
- Relevez le chemin absolu du cœur et l’adresse publique de référence.
- En multisite, relevez aussi le nom et l’identifiant attendu du sous-site.
- Conservez la commande d’origine en masquant les paramètres privés. Relevez l’heure si elle a déjà modifié quelque chose.
Confirmer le répertoire avant de charger le site
Sur la session déjà identifiée, commencez par un chemin absolu. Remplacez /srv/sites/preprod/wordpress par le chemin autorisé sur cette machine ; ne reprenez pas un chemin trouvé dans un exemple ou deviné à partir de l’adresse publique. Cette commande affiche le chemin du fichier de configuration trouvé par WP-CLI avant le chargement normal de WordPress. Elle n’affiche pas les mots de passe contenus dans ce fichier.
Si le résultat pointe vers une autre livraison, une autre copie ou une configuration partagée inattendue, arrêtez-vous et vérifiez l’architecture. Le fichier peut être volontairement placé au-dessus du cœur ; la comparaison doit se faire avec la configuration prévue, pas avec une règle imposant qu’il se trouve à un emplacement unique. Si un lien de déploiement change de version, demandez quel dossier il désignait au moment de l’incident.
Le chemin obtenu est un premier contrôle, pas une preuve que la base est celle attendue. Si la commande ne trouve pas la configuration, corrigez d’abord la destination de la lecture. Ne lancez pas une installation et ne créez pas de fichier pour faire disparaître le message.
wp --path="/srv/sites/preprod/wordpress" config pathLire les adresses du WordPress sélectionné
Lorsque le chemin de configuration correspond, interrogez deux valeurs sans les changer. L’option home correspond à l’adresse publique attendue et siteurl à l’adresse où le cœur est accessible. Une différence entre les deux peut être volontaire, notamment si les fichiers WordPress sont dans un sous-dossier. Comparez chacune à sa valeur de référence plutôt que de les rendre identiques.
Dans l’exemple, remplacez le chemin sur les deux lignes. Les commandes chargent WordPress ; utilisez un environnement déjà identifié et n’exécutez pas cette lecture sur une copie inconnue. Si une erreur PHP empêche le chargement, le contrôle reste incomplet. Ne prenez pas le chemin de configuration comme substitut au résultat manquant.
Pour cette première lecture, évitez la commande d’origine si elle mélange lecture et écriture. Un résultat cohérent avec l’adresse publique constitue un indice de plus, mais certaines installations peuvent imposer leurs adresses depuis la configuration ou les modifier avec un filtre. Si les sorties surprennent, faites contrôler ces valeurs sans les remplacer pour que le test paraisse réussi.
wp --path="/srv/sites/preprod/wordpress" option get home
wp --path="/srv/sites/preprod/wordpress" option get siteurlDépartager deux copies qui affichent la même adresse
Une préproduction clonée peut conserver le domaine et le nom de la production. Deux réponses identiques ne suffisent donc pas à établir une erreur de dossier, ni à prouver qu’il s’agit de la bonne base. Demandez quel environnement, quelle ressource de base et quel préfixe de tables le déploiement devait associer à cette copie. Comparez ces informations dans le panneau privé ou avec le responsable. Le même nom de base ou préfixe peut exister sur deux serveurs ; vérifiez l’association entière.
L’étiquette d’environnement déclarée par WordPress peut compléter le contrôle si l’équipe la maintient, mais une valeur production peut simplement être celle par défaut. Ne réparez pas le diagnostic en changeant cette étiquette. Cherchez une différence qui existait déjà et que l’équipe peut confirmer : l’identifiant de la copie dans l’hébergement, la destination de déploiement ou un contenu de préproduction connu, lu sans le modifier.
Si la même base est associée aux deux copies alors qu’elles devraient être isolées, suspendez les écritures. Un autre dossier ne protège pas les données de production quand les commandes aboutissent aux mêmes tables. Faites rétablir l’association attendue avant de reprendre.
Choisir le sous-site voulu dans un réseau multisite
Un réseau partage généralement une installation WordPress pour plusieurs sites. Le chemin désigne le réseau, mais ne suffit pas à sélectionner le sous-site. Utilisez d’abord la liste des sites de ce réseau et trouvez l’URL complète qui correspond à l’identifiant attendu. Dans un réseau en sous-dossiers, conservez la partie située après le domaine ; dans un réseau avec domaines personnalisés, utilisez le nom exact prévu pour ce site.
L’exemple utilise une installation fictive et un sous-site boutique. Remplacez le chemin et l’URL par les valeurs confirmées, puis lisez home et l’identifiant courant. La dernière commande ne contient qu’une expression de lecture ; n’y placez pas du code reçu d’une source inconnue. Si le site manque dans la liste ou si l’identifiant renvoyé n’est pas celui attendu, vérifiez d’abord le réseau et le contexte.
L’option --url précise le contexte du site. Elle n’ouvre pas une session sur le serveur de l’URL et ne réduit pas automatiquement la portée d’une commande de réseau ou de base. Lisez l’aide de la commande que vous comptez employer avant de lui confier une écriture.
wp --path="/srv/sites/reseau" site list --fields=blog_id,url
wp --path="/srv/sites/reseau" --url="https://reseau.example/boutique/" option get home
wp --path="/srv/sites/reseau" --url="https://reseau.example/boutique/" eval 'echo get_current_blog_id(), PHP_EOL;'Remonter au fichier qui impose la mauvaise valeur
Si la commande fonctionne avec un chemin explicite mais se trompe sans lui, examinez la configuration du lanceur depuis le même dossier et avec le même compte que lors de l’incident. Les fichiers locaux ou de projet peuvent être trouvés en remontant les dossiers parents. Un fichier global propre au compte peut aussi fournir une valeur, et sa destination peut être changée par la variable WP_CLI_CONFIG_PATH.
La ligne de commande prime sur les valeurs de configuration ordinaires. Cela aide à confirmer une cible locale, mais ne transforme pas une commande distante en commande locale si un wrapper ou un réglage impose encore un transport. Lisez uniquement les entrées utiles dans les fichiers déjà identifiés. N’affichez pas leur contenu complet dans un ticket : ils peuvent contenir des chemins internes ou des références à des secrets.
- Depuis le dossier de départ, exécutez wp cli info pour relever les chemins de configuration dans votre session privée.
- Identifiez où sont définis path, url ou le mode de connexion concerné.
- Comparez la valeur à la référence indépendante, puis sauvegardez le fichier avant correction.
- Modifiez seulement l’entrée responsable et recommencez les lectures de contrôle. Restaurez le fichier sauvegardé si le résultat régresse.
Vérifier où mène un alias avant de le réutiliser
Un alias WP-CLI est un raccourci enregistré dans la configuration. Un nom comme @preprod peut conserver l’ancien serveur après une migration. Son libellé n’engage aucune propriété particulière : seule la destination configurée, puis confirmée, compte. Il existe aussi des alias définis dans le shell ou des scripts intermédiaires ; vérifiez que vous examinez le même mécanisme que celui utilisé par la commande.
La première ligne lit la définition d’un alias WP-CLI existant. Inspectez son résultat en privé, car des variables interpolées peuvent rendre des valeurs sensibles visibles. Ne partagez pas la sortie complète. Si l’hôte, le chemin et le transport ont été confirmés et sont autorisés, la deuxième ligne permet de vérifier la configuration WordPress trouvée via cet alias. Remplacez @preprod par le nom réel. Ne lancez pas de connexion quand la définition révèle une destination inconnue.
Corrigez la définition dans son fichier d’origine, après sauvegarde, plutôt que d’ajouter le même alias ailleurs et de laisser deux valeurs concurrentes. Vérifiez ensuite le chemin et les adresses avec l’alias corrigé. En cas d’écart, restaurez la définition sauvegardée et continuez avec le ciblage explicite depuis une session connue.
wp cli alias get @preprod
wp @preprod config pathCorriger un script qui part d’un autre contexte
Lorsque la commande manuelle vise correctement le site, mais que le résultat d’un script diffère, comparez les deux modes d’exécution. Une tâche planifiée ou une chaîne de déploiement peut partir d’un autre dossier, utiliser un autre utilisateur ou ouvrir un conteneur différent. Elle peut aussi lire une configuration globale distincte. Corriger votre profil personnel ne corrigera pas une tâche lancée sous un autre compte.
Relisez la définition du script concerné et la dernière trace disponible. Préparez la correction dans une copie de son fichier, en fixant l’hôte ou le conteneur prévu et le chemin exact ; en multisite, ajoutez le contexte de l’URL là où la commande en tient compte. Pour une tâche récurrente, demandez à son responsable de valider une lecture seule avec le même compte et le même répertoire de départ avant de reprendre les écritures.
Si ce test reproduit l’erreur, comparez ses paramètres et les configurations chargées, une différence à la fois. Gardez l’ancienne définition pour revenir à une version connue. Si l’ancienne version envoyait déjà des opérations vers le mauvais site, son retour ne doit pas réactiver la tâche en l’état. Reprenez seulement lorsque la cible et le périmètre sont confirmés.
Si une commande a déjà modifié le mauvais site
Ne relancez pas la même action sur le bon site avant d’avoir compris les effets sur le premier. Relevez la commande exacte, le début et la fin, les paramètres de cible et les messages affichés. Certaines opérations agissent sur des fichiers, d’autres sur la base ou le réseau entier. Une sortie partielle ne prouve ni que tout a réussi, ni que rien n’a été changé.
Avec l’exploitant, comparez l’état de la cible touchée à une sauvegarde ou à un relevé antérieur. Si une seule option a changé et que sa valeur d’origine est établie, une réparation ciblée est généralement plus facile à vérifier qu’une restauration complète. Une base active peut avoir reçu d’autres écritures entre la sauvegarde et l’incident. Restaurer toutes ses tables pour un seul réglage peut effacer des données récentes.
- Identifiez le site réellement touché et le type d’écriture à partir des traces.
- Sauvegardez son état actuel avant toute réparation, puis comparez les changements.
- Faites choisir une remise en état proportionnée à l’opération.
- Contrôlez séparément le site touché et la cible initialement prévue. Consignez les effets qui ne peuvent pas être annulés localement.
Valider le périmètre propre à la commande finale
Une cible reconnue ne dit pas quelles données une commande traite. Une lecture d’option peut être propre à un sous-site, alors qu’une opération de base peut viser des tables partagées ou des tables explicitement incluses par ses options. Consultez l’aide de cette commande pour lister le périmètre et les modes de simulation éventuellement disponibles. Un paramètre --dry-run n’est pas universel ; ne le supposez pas pris en charge.
Si une simulation est documentée, comparez les objets annoncés au périmètre prévu. Si elle manque, utilisez une copie isolée pour éprouver une opération risquée, avec le même ensemble de composants et de réglages utiles. Une commande de lecture peut confirmer l’identité du site sans valider les conséquences d’une autre commande. Faites ces deux contrôles séparément.
La validation est satisfaisante lorsque la session, le chemin de configuration et les lectures de site convergent, et que la portée de l’action est connue. Si un seul de ces éléments diverge, revenez au contrôle correspondant. Pour un doute sur le moteur PHP ou le fichier INI du terminal, examinez ce sujet séparément : changer de binaire n’est utile ici que s’il empêche les lectures de démarrer correctement.
Faire de la vérification de cible une étape réutilisable
Documentez les commandes de lecture pour chaque environnement dans le guide privé de l’équipe. Notez qui tient à jour le chemin lors d’une migration, quels sous-sites sont concernés et où sont définis les alias. Un accès provisoire ou une copie déplacée doit être retiré de la documentation dès qu’il cesse d’être la référence.
Pour une équipe qui agit souvent, utilisez des libellés clairs pour les environnements et associez chaque alias à des informations vérifiables. Un nom parlant reste utile pour éviter une faute de frappe, mais il ne remplace pas le contrôle du résultat. Après un changement de serveur, vérifiez les anciens raccourcis, y compris ceux du compte qui exécute les tâches récurrentes.
Pour une opération exceptionnelle, conservez avec la trace le nom attendu du site, le chemin et la lecture qui a confirmé le contexte. N’enregistrez pas la sortie brute si elle contient des valeurs privées. Si l’hébergement ne propose pas de terminal, utilisez ses propres fonctions de gestion ou demandez à l’exploitant le relevé ciblé. Le résultat à obtenir reste le même : relier chaque action au bon environnement et à la bonne portée avant qu’elle ne modifie des données.
