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
zipoutarinstallé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.
Vos sauvegardes sont-elles vraiment fiables ?
Une sauvegarde que vous n'avez jamais testée n'est pas une sauvegarde — c'est une illusion de sécurité. Je mets en place des backups automatisés, hors-site, vérifiés, avec procédure de restauration documentée.
Mettons en place une vraie stratégie de backup →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
Besoin de fiabiliser vos extensions WordPress ?
Je peux auditer vos extensions, nettoyer les plugins inutiles, sécuriser vos sauvegardes et mettre en place une maintenance WP-CLI propre pour vos sites WordPress ou WooCommerce.
- Audit des extensions, MU-plugins, drop-ins, dépendances et risques de compatibilité.
- Sauvegarde, archivage et restauration contrôlée des plugins WordPress.
- Automatisation WP-CLI pour installations, mises à jour, staging et migrations.
- Nettoyage des restes de plugins dans
wp_options, métadonnées et tables personnalisées. - Maintenance WooCommerce, sécurité, performance, monitoring et procédures de rollback.
Pour remettre votre maintenance WordPress d’équerre, contactez-moi ici.
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
Vos sauvegardes sont-elles vraiment fiables ?
Une sauvegarde que vous n'avez jamais testée n'est pas une sauvegarde — c'est une illusion de sécurité. Je mets en place des backups automatisés, hors-site, vérifiés, avec procédure de restauration documentée.
Mettons en place une vraie stratégie de backup →
