Maîtriser WP-CLI pour administrer WordPress en terminal

by | WordPress

Si vous avez déjà attendu qu’un back-office charge une page “Extensions” pendant 30 secondes, WP-CLI devient vite votre raccourci préféré. Sur WordPress 6.9.4 (avril 2026), l’outillage CLI est suffisamment mature pour gérer 90% des opérations de maintenance, sans navigateur, avec des logs exploitables et une meilleure reproductibilité.

Ce qu’on va construire

Vous allez mettre en place une “boîte à outils” WP-CLI orientée production, composée :

  • d’un socle de commandes essentielles (core, plugins, thèmes, DB, utilisateurs, cron),
  • d’un flux de diagnostic et de mise à jour reproductible,
  • d’un script Bash réutilisable pour opérer plusieurs sites,
  • et d’un exemple de commande WP-CLI personnalisée (plugin mu-plugin) pour standardiser vos opérations.

C’est destiné aux sites WordPress “réels” : blogs à fort trafic, sites vitrines avec page builders (Divi 5, Elementor, Avada), multisites, environnements staging/production.

À la fin, vous saurez :

  • cibler la bonne instance WordPress depuis le terminal (et éviter l’erreur classique “je suis dans le mauvais dossier”),
  • mettre à jour en limitant les risques (mode maintenance, vérifications, rollback pragmatique),
  • auditer rapidement un site (versions, thèmes actifs, cron, options sensibles),
  • automatiser vos routines, et créer vos propres commandes.

Résumé rapide

  • Vérifiez d’abord : wp --info, puis wp core version et wp plugin list.
  • Ciblez explicitement le site : --path, --url, et évitez les “wp dans le vide”.
  • Avant une mise à jour : export DB + liste des versions, puis MAJ, puis smoke tests.
  • Search-replace : toujours avec --dry-run et attention aux données sérialisées (WP-CLI gère, mais vos options peuvent être piégeuses).
  • Automatisez : scripts Bash + codes de retour, et centralisez vos commandes dans un mu-plugin WP-CLI.
  • Sécurité : pas de secrets dans l’historique shell, pas de --allow-root par habitude, et journalisez vos opérations.

Quand utiliser cette solution

  • Quand vous gérez plusieurs sites et que le back-office est trop lent (ou indisponible).
  • Quand vous devez industrialiser : mises à jour hebdo, contrôles de versions, exports DB, purge transients.
  • Quand vous opérez sur des environnements headless/CI/CD (GitHub Actions, GitLab CI, etc.).
  • Quand vous devez diagnostiquer un site cassé (fatal error en admin) : WP-CLI reste souvent utilisable.

Quand ne PAS utiliser cette solution

  • Si vous n’avez pas d’accès SSH fiable (hébergement mutualisé verrouillé). Dans ce cas, voyez la section “Variante / alternative”.
  • Si vous ne pouvez pas tester sur staging : exécuter un search-replace ou une MAJ majeure “en direct” sans filet est une mauvaise idée.
  • Si votre hébergeur force un wrapper propriétaire (certains panels) qui masque l’environnement PHP : WP-CLI peut alors exécuter avec une version PHP différente de celle du site.

Avant de commencer (prérequis)

Sauvegarde : avant toute commande destructive (db import, search-replace, MAJ), faites une sauvegarde DB et, si possible, un snapshot du répertoire wp-content.

  • WordPress cible : 6.9.4 (ou plus récent).
  • PHP recommandé : 8.1+ (8.2/8.3 sont courants en 2026). Vérifiez que WP-CLI utilise la même version PHP que votre FPM/Apache.
  • Accès : SSH + droits en écriture sur le site (ou au moins sur wp-content et la DB).

Outils utiles :

  • Un environnement staging (même base, mêmes plugins, même thème) ;
  • Un gestionnaire de versions (Git) ;
  • Un outil de diff pour comparer exports (par exemple diff, jq si vous parsez du JSON).

Précautions sécurité (je le répète parce que je vois souvent l’erreur) :

  • Évitez de coller des mots de passe en clair dans le terminal (historique shell).
  • N’utilisez pas --allow-root “par réflexe”. Si vous devez, documentez pourquoi.
  • Préférez des comptes SSH nominatif + sudo, et journalisez les commandes.

Docs officielles utiles :

Étape 1 : Installer WP-CLI proprement et vérifier l’environnement

Sur la plupart des serveurs Linux, l’installation “phar” reste la plus simple. L’objectif : un binaire wp disponible, et une exécution avec le bon PHP.

1.1 Installer WP-CLI (phar)

Connectez-vous en SSH, puis :

# Téléchargement du phar
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

# Vérification basique : le fichier doit répondre
php wp-cli.phar --info

# Rendre exécutable et installer globalement
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

# Vérifier la commande
wp --info

Résultat attendu : wp --info affiche la version WP-CLI, le PHP utilisé, et quelques chemins.

1.2 Vérifier que WP-CLI utilise le bon PHP

Le piège classique : votre site tourne en PHP 8.2 via FPM, mais WP-CLI appelle un PHP 8.1 (ou pire). Comparez :

php -v
wp --info

Si les versions divergent, corrigez via un alias explicite ou un chemin vers le bon binaire PHP (selon votre distro). Exemple (à adapter) :

# Exemple : forcer PHP 8.2 pour WP-CLI
alias wp='php8.2 /usr/local/bin/wp'

Je vois souvent ce problème sur des serveurs avec plusieurs PHP installés (Plesk, cPanel, images Docker “multi”).

1.3 Installer l’autocomplétion (optionnel, mais rentable)

WP-CLI propose une complétion shell. Référez-vous à la documentation de WP-CLI (selon bash/zsh). Côté productivité, c’est un gros gain.

Étape 2 : Cibler la bonne installation WordPress (et éviter de casser la prod)

WP-CLI fonctionne “par contexte”. Il faut être dans le bon répertoire (celui qui contient wp-config.php) ou donner un --path.

2.1 Détecter si vous êtes au bon endroit

# Depuis un dossier supposé être la racine du site
wp core is-installed

# Si ça échoue, vérifiez le chemin
pwd
ls -la

Résultat attendu : un code retour 0 (succès). Si WP-CLI répond qu’il ne trouve pas WordPress, c’est presque toujours un mauvais dossier.

2.2 Utiliser –path et –url (recommandé en multi-sites / multi-instances)

# Exemple : cibler explicitement une instance
wp --path=/var/www/site1/public core version

# Exemple : cibler une URL (utile si WP_HOME/WP_SITEURL diffèrent)
wp --path=/var/www/site1/public --url=https://example.com option get home

2.3 Créer un fichier wp-cli.yml par projet

Créez wp-cli.yml à la racine du projet (même niveau que wp-config.php). Cela évite de répéter --path.

# À la racine de votre site
cat > wp-cli.yml <<'YAML'
path: public
# url: https://example.com
YAML

Résultat attendu : depuis le dossier parent, wp core version fonctionne.

Étape 3 : Diagnostic express (core, PHP, extensions, santé du site)

Avant de toucher quoi que ce soit, je fais toujours un “snapshot logique” : versions, plugins actifs, thème, et quelques options critiques.

3.1 Versions et contexte

wp --info
wp core version
wp core verify-checksums

verify-checksums compare les fichiers core avec les checksums officiels. Très utile après un incident (fichiers modifiés, malware basique, déploiement incomplet). Sur des sites “customisés” à tort dans wp-includes, ça remonte immédiatement.

3.2 Plugins et thèmes (inventaire exploitable)

wp plugin list --status=active
wp plugin list --format=csv > /tmp/plugins.csv

wp theme list
wp theme list --status=active

3.3 Santé du site via WP-CLI

Le module “Site Health” est exposé via WP-CLI sur les installations standards. Testez :

wp site health status
wp site health info --format=json > /tmp/site-health.json

Si votre hébergement ou votre build WP ne fournit pas cette commande, vous aurez un message d’erreur. Dans ce cas, contentez-vous des commandes de versions, et inspectez logs PHP/nginx.

3.4 Tableau de diagnostic rapide (symptômes fréquents)

Symptôme Cause probable Vérification Solution
Erreur “This does not seem to be a WordPress installation” Mauvais dossier / mauvais --path ls (présence de wp-config.php) Utiliser --path ou un wp-cli.yml
WP-CLI marche, mais le site casse après MAJ Incompatibilité plugin/thème + PHP wp plugin list + logs Désactiver plugin fautif via WP-CLI, rollback version
Commandes lentes Object cache / DB saturée / DNS wp profile stage (si dispo), monitoring Limiter autoload, vérifier cache, optimiser DB
Différence de comportement CLI vs web PHP différent, variables d’env, user système php -v vs wp --info Forcer le bon PHP, aligner env

Étape 4 : Mises à jour fiables (core, plugins, thèmes) + rollback pragmatique

La mise à jour “au clic” est pratique, mais difficile à auditer. En CLI, vous pouvez journaliser, ordonner, et vérifier.

4.1 Préparer : maintenance + sauvegarde DB

# Activer le mode maintenance
wp maintenance-mode activate

# Export DB horodaté (à stocker hors serveur si possible)
wp db export "/tmp/db-$(date +%F-%H%M).sql"

# Capturer l'état des plugins/thèmes
wp plugin list --format=json > "/tmp/plugins-$(date +%F-%H%M).json"
wp theme list --format=json > "/tmp/themes-$(date +%F-%H%M).json"

Résultat attendu : un fichier SQL exporté, et deux inventaires JSON.

4.2 Mettre à jour WordPress core

# Vérifier les mises à jour disponibles
wp core check-update

# Mettre à jour vers la dernière version stable
wp core update

# Mettre à jour la base si nécessaire
wp core update-db

Sur WordPress 6.9.4, update-db doit généralement être no-op, mais sur des sites qui ont sauté plusieurs versions, ça compte.

4.3 Mettre à jour plugins et thèmes

wp plugin update --all
wp theme update --all

Si vous gérez des sites avec Divi 5 / Elementor / Avada, je recommande souvent de mettre à jour dans cet ordre :

  • plugins “infrastructure” (cache, sécurité, SEO),
  • page builder (Elementor / Divi / Fusion),
  • thème (Avada / Divi),
  • addons du builder.

Ça réduit les scénarios où un addon attend une API builder plus récente.

4.4 Désactiver rapidement un plugin qui casse le site

Quand l’admin est inaccessible (fatal error), WP-CLI est votre bouton “désamorçage” :

# Désactiver un plugin précis
wp plugin deactivate nom-du-plugin

# Désactiver tous les plugins (utile pour isoler)
wp plugin deactivate --all

4.5 Rollback pragmatique

WP-CLI ne gère pas “rollback” universellement pour tous plugins. En pratique, le rollback fiable passe par :

  • votre sauvegarde (DB + fichiers),
  • ou Git + déploiement,
  • ou la réinstallation d’une version précise quand le plugin le permet.
# Réinstaller WordPress core (même version) si fichiers corrompus
wp core download --force

# Installer une version précise d'un plugin (si disponible sur .org)
wp plugin install woocommerce --version=9.1.0 --force

Note : si le plugin vient d’un marketplace (Divi, Avada) ou d’un zip privé, vous devrez fournir le zip ou repasser par leur mécanisme.

4.6 Sortir de maintenance

wp maintenance-mode deactivate

Étape 5 : Gérer utilisateurs et rôles sans passer par l’admin

Je m’en sers surtout pour : créer un compte admin temporaire sur staging, corriger un email, forcer un reset de mot de passe, ou auditer qui a des droits élevés.

5.1 Lister et filtrer

wp user list --fields=ID,user_login,user_email,roles,registered
wp user list --role=administrator --fields=ID,user_login,user_email

5.2 Créer un admin temporaire (staging uniquement)

wp user create admin-temp [email protected] --role=administrator --user_pass="$(openssl rand -base64 24)"

Évitez de faire ça en production sans ticket/traçabilité. Et supprimez le compte ensuite.

5.3 Réinitialiser un mot de passe

wp user update monlogin --user_pass="NouveauMotDePasseFortIci"

Piège réel : coller le mot de passe en clair dans votre shell laisse une trace dans l’historique. Préférez une saisie interactive (ou un gestionnaire de secrets) selon vos contraintes.

Étape 6 : Gérer contenu, révisions, médias et nettoyage

WP-CLI est très efficace pour nettoyer sans plugin “one shot”, surtout quand vous voulez un résultat reproductible.

6.1 Compter et lister les contenus

wp post list --post_type=post --posts_per_page=10 --fields=ID,post_title,post_date,post_status
wp post list --post_type=page --post_status=publish --fields=ID,post_title

6.2 Nettoyer des révisions en masse

Sur des sites avec page builders, les révisions peuvent exploser (chaque sauvegarde du builder crée une révision). Avant de supprimer, mesurez.

# Compter les révisions
wp post list --post_type=revision --format=count

# Supprimer les révisions (irréversible sans backup)
wp post delete $(wp post list --post_type=revision --format=ids) --force

Piège classique : sur un très gros site, la substitution $(...) peut dépasser la limite de longueur de commande. Dans ce cas, supprimez par lots (voir “Pièges”).

6.3 Régénérer les miniatures (selon votre stack)

WP-CLI fournit des commandes médias, mais la régénération complète dépend souvent de plugins. Si vous utilisez un plugin de régénération qui expose des commandes WP-CLI, utilisez-le. Sinon, la commande suivante peut aider sur des cas simples :

# Lister quelques attachements
wp media list --posts_per_page=5 --fields=ID,post_title,guid

# Exemple : régénération basique (selon version/commandes disponibles)
wp media regenerate --yes

Si wp media regenerate n’est pas disponible dans votre installation WP-CLI, ne forcez pas : installez un outil compatible ou passez par un plugin dédié.

Étape 7 : Base de données : export, search-replace, optimisations et pièges

La DB est l’endroit où les erreurs coûtent cher. Le pattern : export → dry-run → exécution → vérifications.

7.1 Export / import

# Export
wp db export /tmp/backup.sql

# Import (dangereux en production)
wp db import /tmp/backup.sql

7.2 Search-replace (migration http→https, changement de domaine)

WP-CLI gère correctement beaucoup de données sérialisées. Mais vous devez quand même faire un --dry-run et exclure ce qui ne doit pas bouger (GUID, parfois).

# Simulation
wp search-replace 'http://ancien.tld' 'https://nouveau.tld' --dry-run

# Exécution
wp search-replace 'http://ancien.tld' 'https://nouveau.tld' --skip-columns=guid --report-changed-only

J’ai souvent vu le remplacement du guid casser des flux RSS ou des logiques d’import. D’où --skip-columns=guid dans la majorité des migrations.

7.3 Diagnostiquer l’autoload (cause fréquente de lenteur)

Quand la page d’accueil met 2 secondes sans raison, je regarde presque toujours les options autoload trop lourdes.

# Lister les plus grosses options autoload (nécessite MySQL/MariaDB accessible)
wp db query "
SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY bytes DESC
LIMIT 20;
"

Adaptez le préfixe wp_ si nécessaire (ou récupérez-le via wp config get table_prefix).

7.4 Optimiser (avec prudence)

wp db optimize

Sur certains hébergements managés, cette commande est interdite ou inutile (optimisation gérée côté infra). Si elle échoue, ce n’est pas forcément un problème.

Étape 8 : wp-config, cache, cron et tâches planifiées

Cette étape couvre les opérations qui résolvent des incidents “bizarres” : options incohérentes, cron bloqué, cache qui masque une correction.

8.1 Lire/écrire dans wp-config.php

# Lire une constante
wp config get WP_DEBUG

# Activer WP_DEBUG (à faire sur staging ou temporairement)
wp config set WP_DEBUG true --raw

# Désactiver l'édition de fichiers via l'admin
wp config set DISALLOW_FILE_EDIT true --raw

Piège réel : oublier --raw écrit une chaîne au lieu d’un booléen. Vous vous retrouvez avec 'true' au lieu de true. Ça peut sembler “marcher”, puis casser un comportement plus tard.

8.2 Vider certains caches WordPress

# Purger les transients expirés
wp transient delete --expired

# Purger les caches d'objets (si object cache actif)
wp cache flush

Avec des plugins de cache (WP Rocket, LiteSpeed Cache, etc.), la purge complète dépend du plugin. Beaucoup exposent une commande WP-CLI, mais ce n’est pas standard. Vérifiez la doc de votre plugin.

8.3 Cron : lister, exécuter, déboguer

# Lister les événements cron
wp cron event list

# Exécuter tous les événements dus
wp cron event run --due-now

# Exécuter un hook précis
wp cron event run action_scheduler_run_queue

Sur des sites WooCommerce, l’écosystème Action Scheduler est souvent la source de “tâches en attente”. Le hook exact peut varier selon versions/plugins, donc commencez par wp cron event list.

Étape 9 : Audit sécurité minimaliste (sans fausses promesses)

WP-CLI ne remplace pas un scanner de sécurité, mais vous pouvez faire un audit “hygiène” très concret.

9.1 Vérifier l’intégrité core

wp core verify-checksums

9.2 Lister les admins et leurs emails

wp user list --role=administrator --fields=ID,user_login,user_email,registered

9.3 Repérer les plugins “mu-plugins” et drop-ins

wp plugin list --field=name
wp plugin list --status=must-use
wp config get WP_CACHE

Les drop-ins (object-cache.php, advanced-cache.php) et mu-plugins sont des endroits fréquents où vivent des customisations critiques… ou des surprises.

9.4 Vérifier les clés de sécurité (sans les afficher)

Vous ne voulez pas afficher vos salts en terminal partagé. À la place, vérifiez juste que les constantes existent :

wp config has AUTH_KEY
wp config has SECURE_AUTH_KEY
wp config has LOGGED_IN_KEY
wp config has NONCE_KEY

Étape 10 : Automatiser avec des scripts Bash + commandes WP-CLI personnalisées

Deux niveaux : un script Bash (simple, portable), puis une commande WP-CLI custom (standardisation côté WordPress).

10.1 Script Bash : routine de mise à jour “safe-ish”

Créez un fichier wp-update-routine.sh sur votre machine (ou sur le serveur), puis rendez-le exécutable.

#!/usr/bin/env bash
set -euo pipefail

# --- Configuration ---
WP_PATH="${WP_PATH:-/var/www/site/public}"
WP_URL="${WP_URL:-https://example.com}"
BACKUP_DIR="${BACKUP_DIR:-/tmp}"

timestamp="$(date +%F-%H%M%S)"
db_backup="${BACKUP_DIR}/db-${timestamp}.sql"
plugins_snapshot="${BACKUP_DIR}/plugins-${timestamp}.json"
themes_snapshot="${BACKUP_DIR}/themes-${timestamp}.json"

# --- Vérifications ---
wp --path="$WP_PATH" --url="$WP_URL" core is-installed >/dev/null

echo "[1/7] Activation maintenance"
wp --path="$WP_PATH" maintenance-mode activate

echo "[2/7] Backup DB: $db_backup"
wp --path="$WP_PATH" db export "$db_backup"

echo "[3/7] Snapshots plugins/thèmes"
wp --path="$WP_PATH" plugin list --format=json > "$plugins_snapshot"
wp --path="$WP_PATH" theme list --format=json > "$themes_snapshot"

echo "[4/7] MAJ core + DB"
wp --path="$WP_PATH" core update
wp --path="$WP_PATH" core update-db

echo "[5/7] MAJ plugins + thèmes"
wp --path="$WP_PATH" plugin update --all
wp --path="$WP_PATH" theme update --all

echo "[6/7] Flush caches"
wp --path="$WP_PATH" cache flush || true
wp --path="$WP_PATH" transient delete --expired || true

echo "[7/7] Désactivation maintenance"
wp --path="$WP_PATH" maintenance-mode deactivate

echo "OK: sauvegarde DB = $db_backup"

Exécution :

chmod +x wp-update-routine.sh
WP_PATH=/var/www/site/public WP_URL=https://example.com ./wp-update-routine.sh

Résultat attendu : une mise à jour complète avec sauvegarde DB et snapshots. En cas d’échec, le script stoppe (grâce à set -e) et vous savez à quelle étape.

10.2 Commande WP-CLI personnalisée (mu-plugin) : “bp audit”

Créez un fichier wp-content/mu-plugins/bp-cli-audit.php. Si le dossier mu-plugins n’existe pas, créez-le. Les mu-plugins sont chargés automatiquement.

<?php
/**
 * Plugin Name: BP CLI Audit
 * Description: Commandes WP-CLI internes pour auditer rapidement un site.
 * Author: Votre équipe
 * Version: 1.0.0
 */

declare(strict_types=1);

if ( ! defined('WP_CLI') || ! WP_CLI ) {
	// Sécurité : ne rien exécuter en contexte web.
	return;
}

/**
 * Petite commande d'audit orientée ops.
 *
 * Usage:
 *   wp bp audit
 */
final class BP_CLI_Audit_Command {

	/**
	 * Affiche un audit synthétique (versions, thème, plugins actifs, autoload top).
	 *
	 * ## EXAMPLES
	 *     wp bp audit
	 *
	 * @when after_wp_load
	 */
	public function audit( array $args, array $assoc_args ): void {

		// 1) Versions
		WP_CLI::log('--- Versions ---');
		WP_CLI::log('WordPress: ' . get_bloginfo('version'));
		WP_CLI::log('PHP: ' . PHP_VERSION);

		// 2) Thème actif
		$theme = wp_get_theme();
		WP_CLI::log('--- Thème actif ---');
		WP_CLI::log($theme->get('Name') . ' ' . $theme->get('Version'));

		// 3) Plugins actifs
		WP_CLI::log('--- Plugins actifs ---');
		$active = (array) get_option('active_plugins', []);
		if (empty($active)) {
			WP_CLI::log('(aucun plugin actif)');
		} else {
			foreach ($active as $plugin_file) {
				WP_CLI::log('- ' . $plugin_file);
			}
		}

		// 4) Options autoload les plus lourdes (top 10)
		global $wpdb;
		WP_CLI::log('--- Autoload (top 10) ---');

		// Attention : requête volontairement simple ; sur très gros sites, adaptez (index, LIMIT).
		$results = $wpdb->get_results(
			"SELECT option_name, LENGTH(option_value) AS bytes
			 FROM {$wpdb->options}
			 WHERE autoload = 'yes'
			 ORDER BY bytes DESC
			 LIMIT 10",
			ARRAY_A
		);

		if (empty($results)) {
			WP_CLI::log('(aucune donnée)');
			return;
		}

		foreach ($results as $row) {
			WP_CLI::log(sprintf('- %s : %d bytes', $row['option_name'], (int) $row['bytes']));
		}
	}
}

WP_CLI::add_command('bp audit', BP_CLI_Audit_Command::class);

Test :

wp bp audit

Résultat attendu : un audit lisible, utile en incident. Vous pouvez ensuite enrichir (cron, constantes, etc.).

Le résultat complet

À ce stade, vous avez :

  • WP-CLI installé et aligné sur votre PHP,
  • un ciblage propre via --path/--url ou wp-cli.yml,
  • une routine de mise à jour scriptée avec sauvegarde,
  • un mu-plugin qui ajoute une commande d’audit.

Personnalisation rapide

  • Ajoutez un verrou de sécurité au script : n’autoriser l’exécution que sur staging (ex: vérifier WP_ENVIRONMENT_TYPE via wp option get ou une constante).
  • Journalisez dans un fichier : redirigez stdout/stderr vers /var/log/wp-cli-ops.log.
  • Sur multisite : ajoutez --network aux mises à jour plugins quand nécessaire.

Adapter pour Divi 5 / Elementor / Avada

WP-CLI n’est pas “spécifique” aux page builders, mais ils changent vos priorités de maintenance.

Divi 5

  • Les mises à jour Divi (thème/plugin) viennent souvent d’un canal premium. En CLI, vous pouvez activer/désactiver, lister les versions, mais l’installation/rollback dépend de votre mécanisme (zip, API, gestionnaire Elegant Themes).
  • Sur les sites Divi, je surveille particulièrement la taille des révisions et l’autoload (options builder).
wp post list --post_type=revision --format=count
wp bp audit

Elementor

  • Elementor + addons = risque d’incompatibilité en cascade. Faites un snapshot des versions (déjà couvert) et mettez à jour Elementor avant certains addons.
  • En cas d’écran blanc, désactivez d’abord les addons, puis Elementor si nécessaire.
wp plugin list | grep -i elementor
wp plugin deactivate elementor-pro
wp plugin deactivate elementor

Avada (Fusion Builder)

  • Avada est souvent couplé à Fusion Core / Fusion Builder. Même logique : mettez à jour le “cœur” Avada en cohérence avec ses plugins.
  • Sur Avada, j’ai souvent vu des caches agressifs masquer une correction : purge plugin cache + wp cache flush.
wp cache flush
wp transient delete --expired

Vérification finale

  1. WP-CLI voit bien le site : 
    wp core is-installed
wp core version
  2. Pas de maintenance mode bloqué : 
    wp maintenance-mode status
  3. Plugins/thème cohérents : 
    wp plugin list --status=active
wp theme list --status=active
  4. Cron opérationnel : 
    wp cron event list --fields=hook,next_run
wp cron event run --due-now
  5. Smoke tests web (manuel) :
    • page d’accueil,
    • une page builder (Divi/Elementor/Avada),
    • connexion admin,
    • publication d’un brouillon (si possible sur staging).

Si le résultat n’est pas celui attendu

  • Vous avez une erreur “Could not open input file: wp”
    Vérifiez que /usr/local/bin est dans votre PATH, ou appelez /usr/local/bin/wp --info.
  • WP-CLI dit que WordPress n’est pas installé
    Vous êtes dans le mauvais dossier. Utilisez --path ou créez wp-cli.yml. Vérifiez aussi les droits de lecture sur wp-config.php.
  • Après MAJ, le site a une fatal error
    Désactivez le plugin fautif : wp plugin deactivate nom-du-plugin. Regardez les logs PHP. Si vous avez mis à jour sans snapshot, vous allez perdre du temps.
  • Search-replace a “cassé” des URLs
    Vous avez probablement remplacé trop large (ex: inclure guid, ou remplacer une sous-chaîne présente dans des données JSON). Restaurez la DB depuis l’export, puis recommencez avec --dry-run et des patterns plus stricts.
  • Les changements ne se voient pas
    Cache : purgez plugin cache/CDN, puis wp cache flush. Côté navigateur, testez en navigation privée.

Pièges et erreurs courantes

Erreur Cause Solution
Exécuter wp search-replace sur la prod “pour aller vite” Absence de staging + pas de backup Export DB avant, --dry-run, fenêtre de maintenance, validation
Utiliser --allow-root partout Mauvaise habitude / scripts copiés Corriger les permissions, utiliser un user dédié, documenter l’exception
Suppression de révisions en une seule commande qui échoue Limite longueur de commande shell Supprimer par lots (voir ci-dessous)
WP_DEBUG défini en chaîne Oubli de --raw wp config set WP_DEBUG true --raw
Commandes WP-CLI lentes Autoload énorme / DB lente / DNS Auditer autoload, optimiser DB, vérifier réseau

Supprimer des révisions par lots (pattern robuste)

# Supprimer 500 révisions à la fois
while true; do
  ids="$(wp post list --post_type=revision --posts_per_page=500 --format=ids)"
  if [ -z "$ids" ]; then
    break
  fi
  wp post delete $ids --force
done

Variante / alternative

Alternative sans SSH : plugin “WP Crontrol” + outils d’admin

Si vous n’avez pas SSH, vous pouvez approcher une partie des tâches via l’admin :

  • gestion du cron via un plugin (ex: WP Crontrol),
  • gestion des plugins/thèmes via l’interface,
  • export DB via l’hébergeur (phpMyAdmin, outils managés).

Vous perdez la reproductibilité et la journalisation fine. Pour des sites avancés, c’est souvent un compromis temporaire.

Alternative plus avancée : exécuter WP-CLI en conteneur (Docker) au plus près de la prod

Si vous avez un stack containerisé, exécutez WP-CLI dans le même conteneur PHP (même extensions, même ini). C’est la meilleure façon d’éviter les divergences CLI/web.

Conseils sécurité, performance et maintenance

  • Journalisez : redirigez vos sorties vers un log, et gardez les exports DB hors du serveur quand c’est possible.
  • Évitez les secrets : pas de mots de passe en clair dans scripts. Préférez variables d’environnement injectées par un gestionnaire de secrets.
  • Standardisez : un wp-cli.yml par projet + un mu-plugin de commandes internes = moins d’erreurs humaines.
  • Testez en staging : les page builders et leurs addons ont des compatibilités parfois surprenantes ; une MAJ “mineure” peut casser un module.
  • Surveillez l’autoload : c’est une source de lenteur sous-estimée, surtout avec des plugins qui stockent des blobs JSON.

Pour aller plus loin

  • Ajoutez une commande wp bp preflight qui vérifie : espace disque, version PHP, plugins critiques, et bloque si une condition n’est pas remplie.
  • Intégrez WP-CLI dans votre CI : lint PHP, tests, puis wp core verify-checksums sur un environnement éphémère.
  • Créez une routine “incident” : désactivation plugins en cascade, réactivation progressive, export des logs, capture site health info.
  • Pour multisite : commandes réseau (wp site list, wp plugin activate --network) et scripts d’audit par site.

Ressources

FAQ

WP-CLI est-il “compatible” avec WordPress 6.9.4 ?

Oui, à condition d’utiliser une version WP-CLI récente et un PHP compatible. Le point critique n’est pas WordPress, c’est l’alignement PHP CLI vs PHP web. Commencez par wp --info.

Comment éviter d’exécuter des commandes sur le mauvais site ?

Utilisez systématiquement --path et --url dans vos scripts, ou un wp-cli.yml. Sur des serveurs multi-sites, c’est la différence entre une routine propre et un incident.

Est-ce que wp search-replace est sûr pour les données sérialisées ?

WP-CLI gère correctement beaucoup de cas, mais “sûr” dépend de ce que vous remplacez. Faites toujours --dry-run, évitez guid la plupart du temps, et gardez un export DB prêt à restaurer.

Comment désactiver un plugin si l’admin est inaccessible ?

wp plugin deactivate nom-du-plugin. Si vous ne savez pas lequel, désactivez tout (--all), puis réactivez progressivement.

Peut-on mettre à jour Divi/Avada via WP-CLI ?

Vous pouvez gérer l’activation/désactivation et l’inventaire. Pour la mise à jour, tout dépend de leur canal (premium, zip, API). En pratique, vous automatisez souvent via téléchargement du zip + wp theme install/wp plugin install avec --force.

Comment lister les tâches cron qui saturent ?

Commencez par wp cron event list, triez par prochaine exécution, et exécutez wp cron event run --due-now. Sur WooCommerce, surveillez les hooks liés à Action Scheduler.

Pourquoi wp cache flush ne change rien ?

Parce que votre cache principal est peut-être un cache de page (plugin) ou un CDN. wp cache flush cible surtout l’object cache. Purgez aussi le cache du plugin et du CDN.

Comment exécuter WP-CLI sur un multisite ?

Utilisez --url pour cibler un site, et --network pour certaines opérations réseau (ex: activation réseau de plugins). Vérifiez avec wp site list si la commande est disponible dans votre contexte.

WP-CLI peut-il corriger une “boucle de redirection” après migration ?

Souvent oui : vérifiez home et siteurl (wp option get home, wp option get siteurl), puis corrigez. Les redirections peuvent aussi venir du proxy/CDN (headers) ou du plugin de cache.

Quelle est la meilleure pratique pour partager des scripts WP-CLI en équipe ?

Un dépôt Git “ops” + variables d’environnement + un mu-plugin de commandes internes. Vous obtenez des routines versionnées, reviewables, et cohérentes entre sites.

Articles connexes

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.