WP-CLI et Ops

Quand utiliser

Utilise cette skill quand la tâche implique du travail opérationnel WordPress via WP-CLI, notamment :

• wp search-replace (changements d'URL, migrations de domaine, changement de protocole)
• Export/import de DB, réinitialisations et inspections (wp db *)
• installation/activation/mise à jour de plugin/thème, packs de langue
• listage/exécution d'événements cron
• vidage de cache/réécriture
• opérations multisite (wp site *, --url, --network)
• construction de scripts réutilisables (wp-cli.yml, scripts shell, jobs CI)

Entrées requises

• Où WP-CLI s'exécutera (dev local, staging, production) et si c'est sûr de l'exécuter.
• Comment cibler la bonne racine site :
  • --path=<wordpress-root> et (multisite) --url=<site-url>
• Si c'est multisite et si les commandes doivent s'exécuter au niveau réseau.
• Toute contrainte (pas de downtime, pas d'écritures DB, fenêtre de maintenance).

Procédure

0) Garde-fous : confirmer l'environnement et le rayon d'impact

Les commandes WP-CLI peuvent être destructrices. Avant d'exécuter quoi que ce soit en écriture :

1. Confirme l'environnement (dev/staging/prod).
2. Confirme le ciblage (path/url) pour ne pas frapper le mauvais site.
3. Fais une sauvegarde lors d'opérations risquées.

Consulte :

• references/safety.md

1) Inspecter WP-CLI et le ciblage du site (déterministe)

Lance l'inspecteur :

• node skills/wp-wpcli-and-ops/scripts/wpcli_inspect.mjs --path=<path> [--url=<url>]

Si WP-CLI n'est pas disponible, reviens à l'installation via l'outillage documenté du projet (Composer, conteneur ou package système), ou demande l'environnement d'exécution attendu.

2) Choisir le bon workflow

A) Migration d'URL/domaine sûre (search-replace)

Suis une séquence sûre :

1. wp db export (sauvegarde)
2. wp search-replace --dry-run (vérifier l'impact)
3. Exécute le remplacement réel avec les flags appropriés
4. Vide les caches/réécriture si nécessaire

Consulte :

• references/search-replace.md

B) Opérations plugin/thème

Utilise wp plugin * / wp theme * et confirme que tu agis sur le site prévu (et réseau) d'abord.

Consulte :

• references/packages-and-updates.md

C) Cron et files

Inspecte l'état cron et exécute les événements individuels pour déboguer plutôt que « tout exécuter les yeux fermés ».

Consulte :

• references/cron-and-cache.md

D) Opérations multisite

Les changements multisite peuvent affecter plusieurs sites. Décide toujours si tu opères :

• sur un seul site (--url=), ou
• au niveau réseau (--network / itération des sites)

Consulte :

• references/multisite.md

3) Modèles d'automatisation (scripts + wp-cli.yml)

Pour des ops répétables, préfère :

• wp-cli.yml pour les défauts (path/url, limites de mémoire PHP)
• scripts shell qui enregistrent les commandes et s'arrêtent en cas d'erreur
• jobs CI qui exécutent des vérifications en lecture seule par défaut

Consulte :

• references/automation.md

Vérification

• Réexécute wpcli_inspect après les changements qui pourraient affecter le ciblage ou la config.
• Confirme les effets secondaires prévus :
  • les bonnes URLs ont été mises à jour
  • les plugins/thèmes sont dans l'état attendu
  • cron/caches vidés où nécessaire
• S'il y a un endpoint de vérification de santé ou une suite de smoke test, exécute-la après les changements d'ops.

Modes de défaillance / débogage

• « Error: This does not seem to be a WordPress installation. »
  • mauvais --path, mauvais conteneur, ou wp-config.php manquant
• Les commandes multisite affectent le mauvais site
  • --url manquant ou URL incorrecte
• Search-replace cause des problèmes de sérialisation inattendus
  • mauvais flags ou modification de données sérialisées de manière non sûre

Consulte :

• references/debugging.md

Escalade

• Si tu ne peux pas confirmer la sécurité de l'environnement, n'exécute pas d'opérations en écriture.
• Si le repo utilise un outillage conteneurisé (Docker/wp-env) mais que tu n'y as pas accès, demande le runner de commandes prévu ou le job CI.