WP Eval : commande CLI sous-cotée pour diagnostiquer WordPress plus vite

Mis à jour en 2026

Dans mon quotidien de développeur WordPress, la maîtrise de WP-CLI est ce qui me permet de passer d’une intervention laborieuse à une exécution chirurgicale. Pourtant, au milieu des commandes classiques comme wp search-replace ou wp db export, je constate souvent qu’un outil d’une puissance redoutable reste dans l’ombre : wp eval.

Pour un CTO, c’est utile pour réduire le temps de diagnostic. Pour un recruteur technique, c’est un bon signal de maturité opérationnelle. Pour un développeur, c’est un levier pragmatique pour aller du symptôme à la cause racine.

Que ce soit pour tester un fragment de code PHP sans créer de fichier temporaire ou pour manipuler des données complexes en une seule ligne, j’ai fini par faire de wp eval mon couteau suisse ultime. Je te propose ici de découvrir pourquoi, selon moi, elle mérite une place centrale dans ta boîte à outils.

Quand utiliser WP Eval (et quand éviter)

WP Eval est pertinent quand tu dois valider une hypothèse précise, rapidement, sans modifier le code applicatif.

Généralement, c’est le bon outil si :

• tu veux lire une donnée WordPress en condition réelle,
• tu veux vérifier un comportement d’API WordPress,
• tu investigues un incident en staging ou en prod avec un protocole strict.

Ce n’est pas le bon outil si :

• la logique dépasse quelques lignes et mérite relecture,
• tu dois exécuter la même action plusieurs fois,
• l’action modifie beaucoup de données sans filet de sécurité.

Dans ces cas, mieux vaut passer à WP Eval File, voire à une commande WP-CLI custom versionnée.

Préparer un cadre safe en 5 minutes

Avant toute commande, pose un cadre minimal :

1. Définis la question exacte
   Exemple : “Est-ce que les options autoload dépassent un volume raisonnable ?”
2. Choisis l’environnement
   Local ou staging d’abord. En production, seulement si nécessaire et traçable.
3. Précise si lecture seule ou écriture
   Commence presque toujours en lecture seule.
4. Journalise la commande et la sortie
   Ticket incident, canal équipe, ou runbook.
   Ce réflexe est important pour les CTOs : il transforme une action ponctuelle en connaissance partageable.

Référence utile : WP-CLI recommande une approche explicite sur le contexte d’exécution et les commandes sensibles.
Source : https://make.wordpress.org/cli/handbook/

4 mises en situation avec commandes et sorties

Situation 1 : vérifier une option incohérente

Contexte : un client voit un slogan différent entre front et admin, sans changement récent côté thème.

Objectif : lire la valeur brute d’une option, sans dépendre de l’interface.

Commande :

wp eval "echo get_option('blogdescription');"

Sortie typique :

Le site des projets internes

Interprétation :

• Si la valeur est déjà inattendue ici, le souci est probablement en base ou via un hook qui filtre l’affichage ailleurs.
• Si la valeur est correcte, le problème est peut-être côté template/cache.

Variante utile en multisite :

wp eval "echo get_option('blogdescription');" --url=https://staging.exemple.fr

Sortie typique :

7.4 MB

Interprétation :

• En pratique, un volume autoload élevé peut contribuer à ralentir certaines pages, selon l’hébergement et les plugins actifs.
• Cette mesure ne prouve pas seule la cause racine, mais elle donne un signal fort pour prioriser un audit d’options.

Référence complémentaire côté performance WordPress :
https://developer.wordpress.org/advanced-administration/performance/

Situation 3 : confirmer un problème de transient expiré

Contexte : comportements intermittents, données “fantômes” en front.

Objectif : estimer le volume de transients expirés encore présents.

Commande :

wp eval 'global $wpdb; echo (int)$wpdb->get_var("SELECT COUNT(*) FROM {$wpdb->options} WHERE option_name LIKE \"transient_timeout%\" AND option_value < UNIX_TIMESTAMP()");'

Sortie typique :

183

Interprétation :

• Un nombre élevé peut indiquer une hygiène cache perfectible ou un cron qui ne passe pas régulièrement.
• Ce n’est pas systématiquement critique, mais c’est une piste robuste d’investigation.

Action prudente possible (après validation) :

wp transient delete --expired

Sortie typique :

Success: 183 expired transients deleted.

Référence officielle transients API :
https://developer.wordpress.org/apis/transients/

Situation 4 : tester une hypothèse sur un utilisateur/capacité

Contexte : un rôle “éditeur” ne voit plus une action attendue dans l’admin.

Objectif : confirmer une capacité effective côté WordPress, sans naviguer manuellement dans l’UI.

Commande :

wp eval '$u=get_user_by("email","editor@exemple.fr"); wp_set_current_user($u->ID); echo current_user_can("edit_others_posts") ? "yes" : "no";'

Sortie typique :

no

Interprétation :

• Si la capacité est absente, l’anomalie n’est pas seulement visuelle.
• Tu peux ensuite auditer un plugin de rôles/capacités, ou une régression de code sur les hooks de permissions.

Référence capacités et rôles WordPress :
https://wordpress.org/documentation/article/roles-and-capabilities/

Tableau récapitulatif décisionnel

Situation	Commande	Sortie attendue	Décision technique
Option incohérente	get_option	Valeur texte	Vérifier hooks/cache/template
Site lent	SUM autoload	Taille en MB	Prioriser audit options/plugins
Cache instable	Count timeouts expirés	Entier	Contrôler cron/transients
Droits admin étranges	current_user_can	yes/no	Auditer rôles et filtres de capacité

WP Eval vs WP Eval File : règle simple

Règle pragmatique :

• 1 à 3 lignes, test ponctuel, lecture rapide : WP Eval
• Plus de 3 lignes, besoin de partage/revue : WP Eval File
• Routine récurrente d’équipe : commande custom WP-CLI

Cette transition est généralement ce qui évite la dérive “scripts jetables”.

Checklist opérationnelle avant exécution

À valider systématiquement :

• Question de diagnostic formulée en une phrase.
• Environnement explicite (local, staging, production).
• Commande relue si impact potentiel sur données.
• Sortie attendue définie à l’avance.
• Résultat documenté dans ticket ou runbook.
• Correctif durable planifié si anomalie confirmée.

Si tu veux voir comment cette approche s’intègre dans une collaboration projet plus large, tu peux consulter cette page de présentation.

WP Eval est-il dangereux ?

Il peut l’être si utilisé sans cadre. En pratique, en lecture seule, sur un environnement maîtrisé et avec traçabilité, le risque est généralement limité.

Peut-on utiliser WP Eval en production ?

Oui, dans certains contextes d’incident, mais avec prudence : commande ciblée, impact compris, et préférence pour staging dès que possible.

Quelle est la différence clé entre WP Eval et un script temporaire ?

WP Eval évite de déposer du code ad hoc dans le thème ou un plugin. Tu testes vite dans le contexte WordPress, puis tu formalises le correctif proprement.

Références sérieuses externes

• WP-CLI eval : https://developer.wordpress.org/cli/commands/eval/
• WP-CLI handbook : https://make.wordpress.org/cli/handbook/
• WordPress Performance (docs) : https://developer.wordpress.org/advanced-administration/performance/
• WordPress Transients API : https://developer.wordpress.org/apis/transients/
• Roles and capabilities : https://wordpress.org/documentation/article/roles-and-capabilities/