Sauvegarder, archiver et installer des extensions WordPress par lots avec WP-CLI

Lors d’un audit WordPress, d’une migration, d’un nettoyage malware ou d’un diagnostic de performance, il faut parfois désactiver, archiver, réinstaller ou activer plusieurs extensions d’un coup.

Le faire à la main depuis l’administration WordPress fonctionne pour deux plugins. Au-delà, cela devient vite pénible. Et quand le site est cassé, lent, infecté ou inaccessible, l’interface graphique n’est pas toujours votre meilleure amie. Elle sourit, puis elle affiche une erreur 500.

Dans ce guide, nous allons voir comment sauvegarder, archiver et installer des extensions WordPress par lots avec WP-CLI. L’objectif : travailler vite, proprement, avec des sauvegardes exploitables et des scripts Bash réutilisables.

Pourquoi gérer les extensions WordPress avec WP-CLI ?

WP-CLI permet d’administrer WordPress en ligne de commande. Pour les extensions, il peut lister, installer, activer, désactiver, supprimer, mettre à jour et réinstaller des plugins sans passer par le tableau de bord.

C’est particulièrement utile pour :

• réinstaller proprement des extensions après une infection ;
• archiver les extensions installées avant une intervention ;
• préparer une migration serveur ;
• documenter l’état d’un site client ;
• désactiver plusieurs extensions pendant un diagnostic ;
• réinstaller les plugins du dépôt WordPress.org depuis leurs slugs ;
• installer plusieurs fichiers ZIP premium ou locaux ;
• automatiser une procédure sur staging.

La bonne méthode consiste à sauvegarder d’abord, inventorier ensuite, puis agir. Dans cet ordre. Le terminal récompense les gens méthodiques. Il punit les touristes.

Pré-requis

Pour suivre ce guide, il vous faut :

• un accès SSH au serveur ;
• WP-CLI installé ;
• un accès à la racine WordPress ;
• la commande zip ou tar installée ;
• un dossier de sauvegarde hors du webroot ;
• une sauvegarde complète avant toute action risquée.

Placez-vous d’abord à la racine de votre installation WordPress :

cd /home/www/example.com/public_html

Vérifiez que WP-CLI voit bien le site :

wp core version
wp option get homeLangage du code : JavaScript (javascript)

Si vous lancez les commandes depuis un autre dossier, utilisez --path avec la racine WordPress, pas avec wp-content/plugins.

wp plugin list --path=/home/www/example.com/public_htmlLangage du code : JavaScript (javascript)

Sauvegarder la base avant toute intervention

Avant de désactiver, supprimer, remplacer ou réinstaller des extensions, exportez la base de données.

mkdir -p ~/backups/wordpress-plugins

wp db export ~/backups/wordpress-plugins/db-before-plugins-$(date +%F-%H%M%S).sql --add-drop-tableLangage du code : JavaScript (javascript)

Vérifiez que le fichier existe :

ls -lh ~/backups/wordpress-plugins/Langage du code : JavaScript (javascript)

Évitez de stocker les sauvegardes SQL dans un dossier public du site. Un fichier .sql accessible depuis le web, c’est une fuite de données emballée dans du papier cadeau.

Créer un inventaire des extensions installées

Avant de toucher aux plugins, exportez l’état actuel. Cela permet de savoir quelles extensions étaient actives, inactives, en mise à jour, ou installées depuis le dépôt WordPress.org.

mkdir -p ~/backups/wordpress-plugins

wp plugin list \
  --fields=name,status,version,update,update_version,auto_update,wporg_status,wporg_last_updated \
  --format=csv \
  > ~/backups/wordpress-plugins/plugins-inventory-$(date +%F-%H%M%S).csvLangage du code : JavaScript (javascript)

Pour lister uniquement les slugs des extensions actives :

wp plugin list --status=active --field=nameLangage du code : PHP (php)

Pour créer un fichier de réactivation :

wp plugin list --status=active --field=name > ~/backups/wordpress-plugins/active-plugins.txtLangage du code : JavaScript (javascript)

Ce fichier devient très pratique après un diagnostic où vous avez désactivé toutes les extensions.

Désactiver toutes les extensions, avec exclusions

Pour désactiver toutes les extensions classiques :

wp plugin deactivate --all

Pour exclure certaines extensions critiques :

wp plugin deactivate --all --exclude=woocommerce,query-monitor

Sur un multisite, distinguez bien activation locale et activation réseau. Pour désactiver au niveau réseau :

wp plugin deactivate --all --network

Attention : les MU-plugins et les drop-ins ne se désactivent pas comme des plugins classiques. WP-CLI peut les lister, mais ils vivent dans d’autres chemins ou fichiers spéciaux.

wp plugin list --status=must-use
wp plugin list --status=dropinLangage du code : PHP (php)

Réactiver les extensions actives avant diagnostic

Si vous avez sauvegardé la liste des plugins actifs, vous pouvez les réactiver ensuite :

xargs wp plugin activate < ~/backups/wordpress-plugins/active-plugins.txtLangage du code : JavaScript (javascript)

Pour une version plus robuste, utilisez une boucle Bash :

while IFS= read -r plugin; do
  [ -n "$plugin" ] || continue
  wp plugin activate "$plugin"
done < ~/backups/wordpress-plugins/active-plugins.txtLangage du code : JavaScript (javascript)

Cette version évite quelques surprises si le fichier contient des lignes vides.

Archiver chaque extension dans un fichier ZIP séparé

Pour conserver une copie exacte des extensions présentes sur le serveur, vous pouvez archiver chaque dossier de plugin dans un ZIP distinct.

Installez zip si nécessaire :

sudo apt update
sudo apt install zip

Puis lancez ce script depuis la racine WordPress :

#!/usr/bin/env bash

set -euo pipefail

readonly WP_ROOT="$(pwd)"
readonly PLUGINS_DIR="${WP_ROOT}/wp-content/plugins"
readonly BACKUP_DIR="${HOME}/backups/wordpress-plugins/plugin-zips-$(date +%F-%H%M%S)"

mkdir -p "${BACKUP_DIR}"

if [[ ! -d "${PLUGINS_DIR}" ]]; then
  echo "Dossier plugins introuvable : ${PLUGINS_DIR}" >&2
  exit 1
fi

find "${PLUGINS_DIR}" -mindepth 1 -maxdepth 1 -type d -print0 | while IFS= read -r -d '' plugin_dir; do
  plugin_slug="$(basename "${plugin_dir}")"
  echo "Archivage de ${plugin_slug}..."
  (
    cd "${PLUGINS_DIR}"
    zip -rq "${BACKUP_DIR}/${plugin_slug}.zip" "${plugin_slug}"
  )
done

echo "Archives créées dans : ${BACKUP_DIR}"Langage du code : PHP (php)

Vous pouvez l’enregistrer dans un fichier :

nano archive-plugin-zips.sh
chmod +x archive-plugin-zips.sh
./archive-plugin-zips.sh

Ce script corrige les pièges classiques : il parcourt les vrais dossiers d’extensions, gère les espaces via -print0, crée un dossier horodaté, et stocke les ZIP hors du webroot.

Archiver tout le dossier plugins en une seule archive

Si vous voulez une archive complète du dossier plugins, utilisez plutôt tar. C’est souvent plus adapté sur Linux pour conserver proprement l’arborescence.

mkdir -p ~/backups/wordpress-plugins

tar -czf ~/backups/wordpress-plugins/plugins-full-$(date +%F-%H%M%S).tar.gz wp-content/pluginsLangage du code : JavaScript (javascript)

Cette archive ne remplace pas l’inventaire WP-CLI, car elle ne dit pas quelles extensions étaient actives. Gardez les deux : l’état applicatif en CSV, les fichiers en archive.

Installer plusieurs extensions depuis le dépôt WordPress.org

WP-CLI peut installer plusieurs extensions en une seule commande avec leurs slugs WordPress.org.

wp plugin install query-monitor health-check wordpress-seo

Pour les installer et les activer immédiatement :

wp plugin install query-monitor health-check wordpress-seo --activate

Pour forcer la réinstallation depuis le dépôt :

wp plugin install query-monitor health-check wordpress-seo --force

Utilisez --force avec prudence. La commande écrase les fichiers de l’extension installée. C’est utile après une infection ou une corruption de fichiers, mais à éviter si l’extension a été modifiée à la main. Bon, modifier un plugin à la main est déjà une mauvaise idée. Mais les sites hérités aiment les surprises.

Installer une liste d’extensions depuis un fichier

Créez un fichier plugins.txt avec un slug par ligne :

query-monitor
health-check
wordpress-seo

Puis installez tout :

while IFS= read -r plugin; do
  [ -n "$plugin" ] || continue
  wp plugin install "$plugin"
done < plugins.txtLangage du code : JavaScript (javascript)

Pour installer et activer :

while IFS= read -r plugin; do
  [ -n "$plugin" ] || continue
  wp plugin install "$plugin" --activate
done < plugins.txtLangage du code : JavaScript (javascript)

Cette approche est plus lisible qu’une très longue ligne de commande. Elle facilite aussi le versioning d’un socle d’extensions pour vos sites clients ou vos environnements de staging.

Réinstaller toutes les extensions issues du dépôt WordPress.org

Pour réinstaller les extensions connues du dépôt WordPress.org, commencez par les lister :

wp plugin list \
  --fields=name,wporg_status \
  --format=csvLangage du code : PHP (php)

Ensuite, créez une liste des extensions actives sur WordPress.org :

wp plugin list \
  --fields=name,wporg_status \
  --format=csv \
  | awk -F, 'NR > 1 && $2 == "active" {print $1}' \
  > wporg-plugins.txtLangage du code : PHP (php)

Réinstallez-les avec --force :

while IFS= read -r plugin; do
  [ -n "$plugin" ] || continue
  wp plugin install "$plugin" --force
done < wporg-plugins.txtLangage du code : JavaScript (javascript)

Cette méthode évite de tenter une réinstallation depuis WordPress.org pour des extensions premium, privées ou abandonnées. Elle est plus sûre que wp plugin install $(wp plugin list --field=name) --force, qui peut échouer ou écraser des choses inattendues.

Installer plusieurs plugins ZIP locaux

WP-CLI accepte aussi les fichiers ZIP locaux. C’est pratique pour les extensions premium, les plugins privés ou les sauvegardes d’extensions archivées.

Placez vos ZIP dans un dossier hors du webroot, puis lancez :

cd ~/backups/wordpress-plugins/plugin-zips-2026-06-03-120000

for plugin_zip in ./*.zip; do
  [ -f "$plugin_zip" ] || continue
  wp plugin install "$plugin_zip" --force --path=/home/www/example.com/public_html
doneLangage du code : JavaScript (javascript)

Pour installer et activer directement :

for plugin_zip in ./*.zip; do
  [ -f "$plugin_zip" ] || continue
  wp plugin install "$plugin_zip" --force --activate --path=/home/www/example.com/public_html
done

Le point crucial : --path doit pointer vers la racine WordPress, pas vers wp-content/plugins.

Mettre à jour toutes les extensions

Pour lister les mises à jour disponibles :

wp plugin list --update=availableLangage du code : PHP (php)

Pour simuler les mises à jour avant de les appliquer :

wp plugin update --all --dry-run

Pour tout mettre à jour :

wp plugin update --all

Pour exclure WooCommerce ou une extension sensible :

wp plugin update --all --exclude=woocommerce

Sur une boutique WooCommerce ou un site métier, testez les mises à jour critiques sur staging. Le bouton “tout mettre à jour” est rapide. La réparation d’un checkout cassé l’est rarement.

Script complet : inventaire, sauvegarde DB, archive ZIP et installation par lots

Voici un script Bash réutilisable. Par défaut, il crée un inventaire, sauvegarde la base, archive chaque plugin dans un ZIP séparé, puis peut installer une liste de plugins si vous fournissez un fichier.

#!/usr/bin/env bash

set -euo pipefail

WP_ROOT="${WP_ROOT:-$(pwd)}"
PLUGINS_FILE="${1:-}"
DATE="$(date +%F-%H%M%S)"
BACKUP_ROOT="${BACKUP_ROOT:-${HOME}/backups/wordpress-plugins/${DATE}}"
PLUGIN_ZIP_DIR="${BACKUP_ROOT}/plugin-zips"

cd "${WP_ROOT}"

if ! command -v wp >/dev/null 2>&1; then
  echo "WP-CLI est introuvable dans le PATH." >&2
  exit 1
fi

if ! wp core is-installed >/dev/null 2>&1; then
  echo "WordPress n'est pas détecté dans : ${WP_ROOT}" >&2
  exit 1
fi

mkdir -p "${PLUGIN_ZIP_DIR}"

echo "Racine WordPress : ${WP_ROOT}"
echo "Dossier de sauvegarde : ${BACKUP_ROOT}"
echo

echo "Export de la base..."
wp db export "${BACKUP_ROOT}/database.sql" --add-drop-table

echo "Inventaire des extensions..."
wp plugin list \
  --fields=name,status,version,update,update_version,auto_update,wporg_status,wporg_last_updated \
  --format=csv \
  > "${BACKUP_ROOT}/plugins-inventory.csv"

echo "Liste des extensions actives..."
wp plugin list --status=active --field=name > "${BACKUP_ROOT}/active-plugins.txt"

echo "Archivage des dossiers d'extensions..."
find "${WP_ROOT}/wp-content/plugins" -mindepth 1 -maxdepth 1 -type d -print0 | while IFS= read -r -d '' plugin_dir; do
  plugin_slug="$(basename "${plugin_dir}")"
  echo " - ${plugin_slug}"
  (
    cd "${WP_ROOT}/wp-content/plugins"
    zip -rq "${PLUGIN_ZIP_DIR}/${plugin_slug}.zip" "${plugin_slug}"
  )
done

if [[ -n "${PLUGINS_FILE}" ]]; then
  if [[ ! -f "${PLUGINS_FILE}" ]]; then
    echo "Fichier de plugins introuvable : ${PLUGINS_FILE}" >&2
    exit 1
  fi

  echo
  echo "Installation des extensions listées dans ${PLUGINS_FILE}..."
  while IFS= read -r plugin; do
    [ -n "${plugin}" ] || continue
    [[ "${plugin}" =~ ^# ]] && continue
    wp plugin install "${plugin}" --activate
  done < "${PLUGINS_FILE}"
fi

echo
echo "Terminé."
echo "Sauvegardes disponibles dans : ${BACKUP_ROOT}"Langage du code : PHP (php)

Créez le fichier :

nano manage-wordpress-plugins.shLangage du code : CSS (css)

Rendez-le exécutable :

chmod +x manage-wordpress-plugins.shLangage du code : CSS (css)

Lancez seulement l’inventaire et l’archivage :

./manage-wordpress-plugins.sh

Ou lancez l’inventaire, l’archivage et l’installation depuis une liste :

./manage-wordpress-plugins.sh plugins.txt

Pour exécuter depuis un autre dossier :

WP_ROOT=/home/www/example.com/public_html ./manage-wordpress-plugins.sh plugins.txtLangage du code : JavaScript (javascript)

Cas des extensions premium et privées

Les extensions premium ne sont pas toujours réinstallables depuis un slug WordPress.org. Elementor Pro, WP Rocket, ACF Pro, Gravity Forms ou des plugins privés demandent souvent un ZIP local, une licence ou un dépôt privé.

Pour ces plugins, archivez les fichiers avant toute suppression :

tar -czf ~/backups/wordpress-plugins/premium-plugins-$(date +%F-%H%M%S).tar.gz \
  wp-content/plugins/elementor-pro \
  wp-content/plugins/wp-rocket \
  wp-content/plugins/advanced-custom-fields-proLangage du code : JavaScript (javascript)

Adaptez les dossiers à votre site. Ensuite, conservez les ZIP officiels et les licences dans un coffre ou un espace sécurisé. Pas dans wp-content/uploads, évidemment. Les uploads sont déjà assez occupés à collectionner des images de 4 Mo.

Cas des MU-plugins et drop-ins

Les MU-plugins vivent dans wp-content/mu-plugins. Les drop-ins sont des fichiers spéciaux comme object-cache.php, advanced-cache.php, db.php ou sunrise.php. Ils peuvent avoir un impact énorme sur le comportement du site.

Listez-les avec :

wp plugin list --status=must-use
wp plugin list --status=dropinLangage du code : PHP (php)

Archivez-les séparément :

mkdir -p ~/backups/wordpress-plugins/special

tar -czf ~/backups/wordpress-plugins/special/mu-plugins-$(date +%F-%H%M%S).tar.gz wp-content/mu-plugins 2>/dev/null || true

tar -czf ~/backups/wordpress-plugins/special/dropins-$(date +%F-%H%M%S).tar.gz \
  wp-content/advanced-cache.php \
  wp-content/object-cache.php \
  wp-content/db.php \
  wp-content/sunrise.php \
  2>/dev/null || trueLangage du code : JavaScript (javascript)

Ne supprimez pas un drop-in au hasard. Un object-cache.php peut gérer Redis. Un advanced-cache.php peut appartenir à WP Rocket ou à un cache hébergeur. Un db.php peut modifier toute la couche base de données. Bref, ce ne sont pas des bibelots.

Vérifier le site après installation ou réactivation

Après une installation ou une réactivation par lots, vérifiez l’état général :

wp plugin list
wp core verify-checksums
wp cache flush
wp cron event list | headLangage du code : PHP (php)

Pour WooCommerce, vérifiez aussi le checkout, les emails, les moyens de paiement, les webhooks et les actions planifiées :

wp action-scheduler action list --status=pending --per-page=20Langage du code : PHP (php)

La commande Action Scheduler dépend de WooCommerce ou du package Action Scheduler. Si elle n’existe pas, ce n’est pas forcément une erreur.

Erreurs fréquentes à éviter

Utiliser –path avec le dossier plugins

--path doit pointer vers la racine WordPress. Pas vers wp-content/plugins.

wp plugin install plugin.zip --path=/home/www/example.com/public_htmlLangage du code : JavaScript (javascript)

Installer tous les slugs sans distinguer les plugins premium

Un slug ne suffit pas toujours. Les plugins premium ou privés doivent souvent être restaurés depuis un ZIP officiel ou une archive locale.

Réinstaller avec –force sans sauvegarde

--force écrase les fichiers existants. Utilisez-le après sauvegarde, et surtout quand vous savez d’où vient l’extension.

Oublier les MU-plugins et drop-ins

Ils ne sont pas gérés comme les plugins classiques, mais ils peuvent être essentiels. Listez-les et archivez-les séparément.

Laisser des archives dans le webroot

Ne laissez pas de ZIP ou de SQL dans un dossier public. Déplacez-les hors du site ou supprimez-les après transfert sécurisé.

Pour aller plus loin avec WP-CLI et la maintenance WordPress

Si vous automatisez la gestion des extensions, ces guides complètent bien l’audit, la sauvegarde, la migration et le nettoyage de votre site WordPress.

• Mettre à jour WordPress en SSH avec WP-CLI
• Identifier les options de base de données liées à un plugin WordPress
• Désinstaller WPML proprement et nettoyer la base WordPress
• Nettoyer complètement la base WordPress après désinstallation d’Elementor
• Migrer WordPress avec WP-CLI vers un nouveau serveur

FAQ

Puis-je réinstaller toutes les extensions avec WP-CLI ?

Oui, mais seulement si vous savez d’où viennent les extensions. Les plugins du dépôt WordPress.org peuvent être réinstallés par slug. Les plugins premium ou privés doivent souvent être restaurés depuis un ZIP local ou un dépôt privé.

Est-ce que wp plugin install écrase les fichiers existants ?

Seulement avec --force. Sans cette option, WP-CLI refusera généralement d’écraser une extension déjà installée.

Faut-il activer les plugins immédiatement après installation ?

Pas toujours. Sur un site sensible, installez d’abord, puis activez progressivement. Cela facilite le diagnostic si une extension casse le site.

Comment sauvegarder les plugins premium ?

Archivez leurs dossiers avec tar ou zip, puis gardez aussi les ZIP officiels et licences dans un emplacement sécurisé. Ne dépendez pas uniquement du site en production.

Les MU-plugins sont-ils inclus dans wp plugin deactivate –all ?

Non. Les MU-plugins sont chargés automatiquement depuis wp-content/mu-plugins. Ils doivent être audités et archivés séparément.

Puis-je laisser les archives ZIP sur le serveur ?

Oui, mais hors du webroot et avec des permissions strictes. Les archives contenant des plugins premium, des fichiers sensibles ou du code client ne doivent pas être accessibles publiquement.

Conclusion

WP-CLI simplifie énormément la gestion des extensions WordPress par lots. Vous pouvez lister les plugins, sauvegarder leur état, archiver leurs fichiers, les désactiver, les réinstaller, les mettre à jour et les réactiver sans cliquer partout dans l’administration.

La méthode propre reste toujours la même : sauvegarder la base, inventorier les extensions, archiver les fichiers, distinguer les plugins WordPress.org des plugins premium, puis agir progressivement.

Avec quelques scripts bien pensés, vous gagnez du temps et vous réduisez les risques. Et surtout, vous évitez de découvrir trop tard que “réinstaller les plugins” ne veut pas dire grand-chose quand trois d’entre eux étaient premium, modifiés à la main et jamais documentés. Le patrimoine applicatif, quel poème.

Sources

• WP-CLI : wp plugin install
• WP-CLI : wp plugin list
• WP-CLI : wp plugin activate
• WP-CLI : wp plugin deactivate
• WP-CLI : wp plugin update
• WP-CLI : wp db export

Report a typo