SiteGround ou alwaysdata pour corriger une sortie JSON WP-CLI illisible

Une commande réussit et son fichier JSON reste illisible

Une tâche WordPress lance une commande WP-CLI, écrit sa sortie dans un fichier JSON et transmet ce fichier à un autre traitement. La tâche relève un code de sortie nul. L’étape suivante échoue pourtant dès le début du document. En ouvrant la sortie brute, vous trouvez un avertissement PHP avant le premier caractère du JSON. La commande a terminé et produit ses données, mais le fichier transmis mélange le résultat avec un diagnostic.

Le cas se reproduit avec une vraie commande de lecture, `wp cli info --format=json`. Cette commande s’exécute avant le chargement de WordPress et permet d’examiner le contexte de WP-CLI. Dans la recette, un avertissement volontaire au démarrage de PHP se retrouve dans la sortie standard. WP-CLI poursuit son exécution et retourne zéro. Si le consommateur vérifie seulement ce code, il accepte un fichier qu’il ne peut pas analyser. Les deux contrôles doivent donc être faits avant de publier ou de transmettre le résultat.

SiteGround et alwaysdata documentent des parcours pour retrouver l’exécutable PHP, la commande et la tâche planifiée. Le comparatif montre où relever ces informations et comment isoler un problème de démarrage PHP d’un mélange créé par le lanceur. Le test s’exécute dans un dossier local isolé, avec un avertissement fictif et sans accès à une installation WordPress.

Relever la commande, le code et les deux flux séparément

Reprenez la commande exacte de la tâche autorisée, avec son répertoire de travail, l’utilisateur de lancement et le chemin de l’exécutable PHP si la tâche le fixe. Pour un premier test, choisissez une commande de lecture, par exemple `wp cli info --format=json`. Si le problème arrive seulement avec une commande qui charge WordPress, gardez le même site de recette et notez les extensions ou fichiers chargés par cette commande. Le témoin simple indique si le démarrage suffit déjà à reproduire le problème.

Sur un terminal SSH utilisant un shell de type POSIX, `wp cli info --format=json > info.json 2> diagnostic.log` crée deux fichiers distincts dans le dossier de travail choisi. Relevez ensuite le code de sortie avec `printf '%s\n' "$?"`, avant de lancer une autre commande. Analysez le document entier avec le parseur employé par l’automatisation. Vérifiez également les clés attendues, puisque du JSON valide peut tout de même représenter un résultat incomplet ou d’une autre commande.

Si un avertissement figure dans le fichier JSON, notez s’il apparaît avant ou après le document. Si le journal d’erreur contient déjà le diagnostic, recherchez une fusion des flux dans la commande, le script de lancement ou le système qui capture les sorties. Les outils de planification peuvent afficher les deux flux dans un seul écran sans modifier les fichiers. Le point à vérifier est le flux effectivement remis au consommateur du JSON.

• Isoler la sortie standard et la sortie d’erreur, puis relever le code de sortie.
• Analyser tout le fichier JSON et contrôler la forme attendue du résultat.

Identifier la couche qui écrit le diagnostic

Si le diagnostic apparaît également au lancement d’une commande PHP de lecture qui ne charge pas WordPress, examinez la configuration de l’interpréteur utilisé. `php --ini` aide à repérer les fichiers de configuration lus en ligne de commande. `wp cli info` indique aussi le PHP qui exécute WP-CLI et le fichier de configuration qu’il voit. Comparez le contexte du terminal à celui de la tâche. Ils peuvent appeler deux versions de PHP ou charger des fichiers différents.

Si la commande de lecture produit un document propre et que seule la commande du site échoue, recherchez le moment où elle charge l’application, une extension ou un fichier additionnel. Un avertissement PHP, un message imprimé par le code et une fusion des flux exigent des corrections différentes. Un `echo` écrit directement dans la sortie standard. Modifier le réglage d’affichage des erreurs PHP ne déplace pas cette écriture. Le mainteneur doit alors déplacer le diagnostic vers le mécanisme de journalisation adapté ou corriger la sortie de la commande.

Ne filtrez pas le document en supprimant arbitrairement tout ce qui précède le premier caractère ouvrant. Cette méthode peut masquer un autre échec, prendre une mauvaise ligne pour le début du document ou laisser un diagnostic après le résultat. Gardez la sortie brute pour la recette, vérifiez le code de sortie et confiez au parseur le document complet. Les diagnostics restent consultables séparément.

SiteGround StartUp, retrouver la commande dans Site Tools

Dans Site Tools, sélectionnez le site qui exécute la tâche. SiteGround documente l’usage de WP-CLI via SSH et le parcours de gestion des tâches dans Devs → Cron Jobs. Relevez la commande existante, son intervalle et le dossier depuis lequel elle est lancée. En SSH, comparez le résultat de `wp cli info` au résultat produit par la tâche. La commande de test doit utiliser le même exécutable et les mêmes paramètres que le traitement réel pour expliquer une différence de sortie.

L’aide de SiteGround indique qu’un courriel de tâche peut contenir la sortie de la commande lorsqu’elle en produit. Pour un fichier destiné à un parseur, utilisez ce canal pour le suivi de l’exécution, puis vérifiez séparément le fichier écrit par la tâche. Identifiez la redirection qui le crée et le flux qu’elle capture. Un relevé reçu par courriel peut montrer un diagnostic utile tout en laissant le fichier JSON intact. À l’inverse, une redirection commune peut écrire ce diagnostic dans le fichier transmis.

Avant de changer la tâche sur la copie, conservez la commande précédente et son répertoire de travail. Si la vérification montre qu’un exécutable précis produit un avertissement au démarrage, relevez sa configuration et corrigez la cause dans le périmètre concerné. Après modification, vérifiez la commande de lecture, puis le traitement qui consomme sa sortie. Revenez à la commande précédente si la modification change le site ciblé ou le résultat métier.

alwaysdata Plus Small, comparer le PHP de la tâche à celui du site

Dans l’administration alwaysdata, ouvrez Avancé → Tâches planifiées et sélectionnez la commande qui produit le fichier. La documentation décrit l’environnement de lancement et les journaux de début et de fin. Elle indique aussi que les tâches de type Commande utilisent les versions de langages définies pour le compte, sauf réglage prévu dans la tâche. Pour PHP, relevez Environnement → PHP et comparez la version effective de la commande au réglage du site si ce dernier a été personnalisé.

Vérifiez le journal de la tâche et les redirections de la commande. Le journal de début et de fin indique qu’un processus a été lancé et s’est arrêté. Pour vérifier le fichier remis à l’autre traitement, capturez la sortie standard séparément, puis contrôlez le code de sortie et le JSON entier. Le journal d’erreur doit rester consultable même lorsque le fichier passe le contrôle. Il peut signaler une configuration PHP à corriger avant un prochain changement de version.

Sur le compte de recette, testez la commande avec le même contexte que la tâche planifiée. Si vous changez un paramètre PHP, choisissez le périmètre adapté et notez la valeur à remettre. Une configuration au niveau du compte peut concerner d’autres commandes. Relisez ensuite la sortie dans le traitement qui l’exploite. En cas d’écart, restaurez la configuration ou la commande de départ et reprenez le diagnostic à partir des deux flux conservés.

Tarifs, conditions et limites au 11 novembre 2026

La page française de SiteGround affiche StartUp à 1,99 € HT par mois en équivalent sur douze mois, soit 23,88 € HT au tarif relevé. Elle indique un renouvellement de 15,99 € HT par mois sur douze mois, soit 191,88 € HT à ce taux. Le forfait couvre un site et annonce 10 Go de stockage. Confirmez le total TTC, les conditions de l’offre et l’échéance de reconduction dans le récapitulatif de votre commande. Le stockage sert aussi à accueillir les fichiers de résultat et les journaux si la tâche les conserve localement.

alwaysdata Cloud Public Plus Small affiche 5 € HT par mois avec facturation annuelle, soit 60 € HT sur douze mois. Le cycle mensuel est affiché à 6 € HT par mois, soit 72 € HT sur douze mois au même tarif. La grille indique 50 Go au niveau du compte, 1 Go de RAM et 1 CPU. Confirmez au dossier le cycle, le prix de reconduction et le total fiscal. L’aide alwaysdata indique que le contrat validé se trouve dans Abonnements → Contrats.

Comparez le coût du premier cycle, puis celui de la période suivante, en gardant les durées et les montants hors taxes explicites. Pour cette tâche, repérez surtout l’accès au contexte PHP, aux réglages du lanceur et aux journaux. Un prix ou une capacité de stockage ne montre pas si le fichier de résultat contient seulement la sortie attendue. La validation passe par la commande effectivement utilisée et son consommateur.

Séparer les diagnostics et corriger l’avertissement à sa source

Si le problème vient d’un avertissement PHP, identifiez sa cause dans le contexte de la tâche. Pour le reproduire, l’exercice demande un module fictif absent à PHP. Dans un environnement réel, vérifiez si une directive charge une extension indisponible pour cette version ou si le fichier de configuration appartient à un autre environnement. Corrigez la directive ou le chemin pour le périmètre voulu, puis rejouez la commande de lecture. Le traitement doit produire son JSON et le journal doit permettre de constater si l’avertissement a disparu.

Pour isoler le comportement dans une recette de ligne de commande, si vous utilisez directement le fichier PHAR, la forme testée est `php -d display_errors=stderr wp-cli.phar cli info --format=json`. Adaptez le chemin du PHP et du PHAR à la copie autorisée. Capturez ensuite les flux séparément. Le manuel PHP décrit cette valeur pour CLI. Elle permet de garder l’avertissement hors de la sortie standard lors du diagnostic. Sur le site public, conservez la politique habituelle de journalisation des erreurs.

Si la commande émet déjà son diagnostic sur la sortie d’erreur, vérifiez le lanceur. Une redirection `2>&1` ou un réglage de l’outil de capture peut réinjecter ce diagnostic dans le fichier. Dans l’exercice, la fusion rend de nouveau le document illisible sans changer le code de sortie. Donnez un nom distinct à chaque fichier et vérifiez que le traitement suivant lit uniquement la sortie standard. Si le fichier reste illisible, examinez les lignes ajoutées par le code de la commande lui-même.

• Comparer les deux flux après la correction du réglage PHP ou du lanceur.
• Rejouer le traitement qui lit le JSON et garder le diagnostic dans un journal séparé.

Contrôler le document avant de le transmettre

Dans une automatisation, laissez la commande terminer, puis vérifiez son code de sortie et le document complet. Si un contrôle échoue, signalez l’échec de l’étape et conservez le dernier document validé pour l’usage prévu. Pour un résultat qui doit être récent, indiquez aussi son âge avant de le réutiliser. Évitez d’écraser le fichier accepté à chaque tentative. Préparez le nouveau résultat dans un fichier de travail et remettez-le au consommateur après les contrôles. Écrivez le fichier temporaire dans le même dossier que le résultat final pour pouvoir le remplacer après validation.

Vérifiez les champs que la suite utilise réellement. Pour `wp cli info`, le témoin attend un objet avec une version WP-CLI. Pour une liste de contenus, le contrôle peut porter sur un tableau et les identifiants attendus. Le parseur doit traiter l’ensemble de la sortie, y compris les octets après le dernier objet. Si la commande échoue, gardez son code de sortie et le journal pour distinguer un problème de format d’un échec du traitement.

En recette, conservez la configuration et le lanceur précédents. Si une modification du PHP, de WP-CLI ou de la tâche produit un autre résultat, restaurez le lanceur et les paramètres sauvegardés, puis rejouez le témoin. Gardez les journaux à l’emplacement prévu pour votre équipe. Le rapport partagé peut se limiter à la version, au code de sortie, au résultat du parseur et à la présence d’un diagnostic. Les chemins et réglages détaillés restent utiles dans le contexte privé.

Sept contrôles sur une vraie commande WP-CLI

L’exercice local exécute WP-CLI 2.12.0 sous PHP 8.4.8. Le témoin donne un JSON valide et le code 0. Lorsque PHP imprime l’avertissement dans la sortie standard, la commande garde le code 0 et le parseur rejette le document. Lorsque le diagnostic passe sur la sortie d’erreur, le JSON est de nouveau exploitable et l’avertissement reste consultable. La fusion des deux flux fait échouer de nouveau le parseur. Le dernier témoin, une commande inconnue, retourne un code non nul.

Les sept contrôles ont réussi avec Python 3.14.4 depuis le ZIP extrait. L’exercice utilise le fichier PHAR et une configuration isolée. Il vérifie la commande `wp cli info` avant chargement de WordPress. Pour une automatisation qui charge le site, utilisez le même protocole de capture sur la copie concernée. Le rapport local conserve les versions et les états observés sans publier les chemins et réglages renvoyés par la commande.

SiteGround StartUp convient à l’équipe qui retrouve la commande dans Site Tools et suit son exécution en SSH. alwaysdata Plus Small convient si l’équipe peut comparer la configuration du compte et celle de la tâche, avec le journal de lancement. Dans les deux cas, la validation repose sur le code de sortie, le document JSON complet et le diagnostic accessible dans un flux distinct.

• Extraire le ZIP et lancer `python recette.py --wp-cli CHEMIN_DU_PHAR` en remplaçant le chemin.
• Comparer le code, la validation du document et la présence du diagnostic dans chacun des cinq cas.

Pour aller plus loin

• Lire la fiche SiteGround
• Lire la fiche alwaysdata
• Comparer deux outils de contrôle de WP-Cron
• Télécharger la recette de sortie JSON WP-CLI (ZIP)