Identifier les options WordPress d’un plugin dans wp_options avec WP-CLI

Quand vous désinstallez une extension WordPress, elle ne nettoie pas toujours derrière elle. Certaines options restent dans la table wp_options, parfois pendant des années, comme de petits colocataires qui ne paient jamais le loyer.

Ces options peuvent stocker des réglages, des licences, des caches, des transients, des tableaux sérialisés ou des données d’intégration. Le problème n’est pas leur existence. Le problème commence lorsqu’elles deviennent inutiles, volumineuses ou chargées automatiquement à chaque requête.

Dans ce guide, nous allons voir comment identifier les options de base de données liées à un plugin WordPress avec WP-CLI, grep et quelques requêtes SQL propres. L’objectif : auditer avant de supprimer, exporter avant de modifier, et éviter le grand classique du “j’ai nettoyé la base, maintenant le site est blanc”.

Pourquoi identifier les options d’un plugin WordPress ?

La table wp_options contient les réglages globaux de WordPress. Elle stocke aussi beaucoup de données créées par les extensions et les thèmes.

Identifier les options d’un plugin sert notamment à :

• préparer la désinstallation propre d’une extension ;
• retrouver un réglage caché ou cassé ;
• diagnostiquer un problème de performance lié à l’autoload ;
• exporter la configuration d’un plugin avant migration ;
• comparer deux environnements, par exemple production et staging ;
• nettoyer les données orphelines après plusieurs années de plugins testés puis oubliés.

Cette méthode est particulièrement utile sur les sites WordPress anciens, les boutiques WooCommerce, les sites migrés plusieurs fois, ou les installations qui ont connu trop de builders, d’extensions SEO, de plugins sociaux et d’outils marketing.

Pré-requis

Pour suivre ce tutoriel, il vous faut :

• un accès SSH au serveur ;
• WP-CLI installé ;
• un accès à la racine WordPress ;
• un compte capable de lire la base de données ;
• une sauvegarde récente ;
• idéalement, un environnement de staging.

Les exemples utilisent addthis comme chaîne de recherche. Remplacez-la par le slug, le préfixe ou le nom technique du plugin que vous auditez.

Si vous devez d’abord mettre WP-CLI en place ou maintenir WordPress en ligne de commande, lisez aussi mettre à jour WordPress en SSH avec WP-CLI.

Toujours sauvegarder la base avant de toucher à wp_options

Avant toute inspection poussée ou suppression, exportez la base de données. Même si vous ne comptez “que regarder”. Les incidents arrivent rarement quand on les invite officiellement.

mkdir -p ~/backups

wp db export ~/backups/wordpress-$(date +%F-%H%M%S).sql

Vérifiez ensuite que le fichier existe :

ls -lh ~/backups/Code language: JavaScript (javascript)

Sur un site sensible, faites vos tests sur staging. C’est encore plus vrai si vous auditez WooCommerce, un site multilingue, un site membre ou une installation avec beaucoup de données sérialisées.

Vérifier le préfixe de table WordPress

Ne partez jamais du principe que la table s’appelle wp_options. Beaucoup de sites utilisent un préfixe personnalisé.

Affichez le préfixe avec WP-CLI :

wp db prefix

Vous pouvez ensuite utiliser ce préfixe dans vos requêtes :

wp db query "SELECT COUNT(*) FROM $(wp db prefix)options;"Code language: JavaScript (javascript)

Cette approche évite les requêtes fragiles avec wp_options codé en dur. Sur un site client, c’est une petite précaution qui évite de chercher au mauvais endroit pendant vingt minutes. Ambiance classique du vendredi soir.

Méthode 1 : chercher les options par option_name avec WP-CLI

La méthode la plus simple consiste à lister les noms d’options et à filtrer par chaîne.

wp option list --field=option_name | grep -i -- 'addthis'Code language: PHP (php)

Exemple de résultat :

addthis_settings
addthis_share
addthis_product
addthis_plugin_controls
widget_addthis-widget

Le drapeau -i rend la recherche insensible à la casse. Le -- protège aussi la commande si votre motif commence par un tiret. C’est discret, mais propre.

Vous pouvez aussi utiliser la recherche native de WP-CLI avec un wildcard :

wp option list --search='*addthis*' --fields=option_name,autoload,size_bytesCode language: PHP (php)

Cette version est souvent plus lisible, car elle affiche directement l’autoload et la taille de chaque option.

Méthode 2 : afficher les valeurs des options trouvées

Une fois les noms identifiés, vous pouvez lire chaque valeur avec wp option get.

wp option get addthis_settingsCode language: JavaScript (javascript)

Pour obtenir toutes les valeurs des options qui contiennent une chaîne donnée, utilisez une boucle plutôt qu’un xargs trop brutal :

while IFS= read -r option_name; do
  echo "### ${option_name}"
  wp option get "${option_name}"
  echo
done < <(wp option list --field=option_name | grep -i -- 'addthis')Code language: PHP (php)

Cette version gère mieux les noms d’options, évite les surprises de découpage, et reste simple à relire.

Méthode 3 : exporter les valeurs en JSON

Pour inspecter des tableaux sérialisés, le JSON est souvent plus agréable que la sortie brute.

wp option get addthis_settings --format=jsonCode language: JavaScript (javascript)

Vous pouvez exporter chaque option trouvée dans un dossier temporaire :

mkdir -p /tmp/wp-options-audit

while IFS= read -r option_name; do
  wp option get "${option_name}" --format=json > "/tmp/wp-options-audit/${option_name}.json"
done < <(wp option list --field=option_name | grep -i -- 'addthis')Code language: PHP (php)

Ensuite, inspectez les fichiers :

ls -lh /tmp/wp-options-audit/
cat /tmp/wp-options-audit/addthis_settings.json

Si jq est installé, vous pouvez aussi formater les données :

jq . /tmp/wp-options-audit/addthis_settings.json

Méthode 4 : chercher dans option_value

Parfois, le nom de l’option ne contient pas le nom du plugin. En revanche, la valeur stockée peut contenir un chemin, un slug, un nom de classe, une URL ou une ancienne licence.

Vous pouvez chercher dans les valeurs avec WP-CLI :

wp option list --field=option_value | grep -i -- 'addthis'Code language: PHP (php)

Mais cette méthode peut être verbeuse, surtout avec des valeurs sérialisées très longues. Pour un résultat plus exploitable, préférez wp db search.

Méthode 5 : rechercher dans wp_options avec wp db search

La commande wp db search peut chercher une chaîne dans une table précise. Ici, on cible uniquement la table des options.

wp db search "addthis" "$(wp db prefix)options"Code language: JavaScript (javascript)

Vous obtiendrez des correspondances dans option_name et option_value.

Si vous voulez chercher dans toute la base, utilisez :

wp db search "addthis" --all-tablesCode language: JavaScript (javascript)

Cette commande est utile si un plugin stocke aussi des données dans postmeta, usermeta, termmeta ou des tables personnalisées.

Pour une désinstallation complète, c’est souvent indispensable. Par exemple, un builder ou une extension multilingue ne se limite presque jamais à wp_options. J’ai détaillé ce cas dans le nettoyage complet d’Elementor après désinstallation et dans la désinstallation propre de WPML avec WP-CLI.

Méthode 6 : utiliser une requête SQL directe

Pour une recherche simple dans les noms d’options, une requête SQL reste très efficace.

wp db query "
SELECT option_name, autoload, ROUND(LENGTH(option_value) / 1024, 2) AS size_kb
FROM $(wp db prefix)options
WHERE option_name LIKE '%addthis%'
ORDER BY LENGTH(option_value) DESC;
"Code language: PHP (php)

Cette requête affiche :

• le nom de l’option ;
• sa valeur d’autoload ;
• sa taille approximative en Ko ;
• les plus grosses options en premier.

Pour compter les options correspondantes :

wp db query "
SELECT COUNT(*) AS matching_options
FROM $(wp db prefix)options
WHERE option_name LIKE '%addthis%';
"Code language: PHP (php)

Pour chercher dans les valeurs :

wp db query "
SELECT option_name, autoload, ROUND(LENGTH(option_value) / 1024, 2) AS size_kb
FROM $(wp db prefix)options
WHERE option_value LIKE '%addthis%'
ORDER BY LENGTH(option_value) DESC;
"Code language: PHP (php)

Attention toutefois : chercher dans option_value avec LIKE '%motif%' peut devenir coûteux sur une grosse table. À lancer calmement, pas pendant un pic de trafic sur une boutique en pleine promo.

Auditer les options autoloadées

L’autoload indique si WordPress charge une option automatiquement au démarrage, sur chaque requête. C’est pratique pour les réglages indispensables. C’est beaucoup moins drôle pour un cache énorme ou les restes d’un plugin supprimé en 2018.

Pour calculer la taille totale des options autoloadées avec WP-CLI :

wp option list --autoload=on --format=total_bytesCode language: PHP (php)

Pour lister les options autoloadées les plus lourdes :

wp option list \
  --autoload=on \
  --fields=option_name,autoload,size_bytes \
  --orderby=size_bytes \
  --order=descCode language: PHP (php)

Vous pouvez aussi utiliser SQL. Depuis les changements récents de WordPress, ne cherchez pas seulement autoload = 'yes'. Les valeurs à considérer comme autoloadées sont notamment yes, on, auto-on et auto.

wp db query "
SELECT
  ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb
FROM $(wp db prefix)options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');
"Code language: PHP (php)

Pour afficher les plus grosses options autoloadées :

wp db query "
SELECT
  option_name,
  autoload,
  ROUND(LENGTH(option_value) / 1024, 2) AS size_kb
FROM $(wp db prefix)options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY LENGTH(option_value) DESC
LIMIT 50;
"Code language: PHP (php)

Si un ancien plugin a laissé une grosse option autoloadée, vous pouvez parfois désactiver son autoload plutôt que supprimer directement la ligne. C’est moins destructif, donc souvent plus intelligent.

Modifier l’autoload d’une option sans supprimer sa valeur

WP-CLI permet de modifier l’autoload d’une option avec wp option set-autoload.

Avant modification, vérifiez la valeur actuelle :

wp option get-autoload addthis_settingsCode language: JavaScript (javascript)

Pour désactiver l’autoload :

wp option set-autoload addthis_settings offCode language: JavaScript (javascript)

Ou, pour les anciennes valeurs compatibles :

wp option set-autoload addthis_settings noCode language: JavaScript (javascript)

Je préfère off dans les nouveaux scripts. WordPress conserve la compatibilité avec yes et no, mais les valeurs modernes sont plus explicites.

Ne désactivez pas l’autoload au hasard. Certaines options doivent être disponibles très tôt dans le bootstrap WordPress. Si vous coupez l’autoload d’une option critique, vous pouvez créer un ralentissement, des requêtes répétées, ou un comportement étrange côté thème ou plugin.

Chercher les options utilisées dans le code du plugin

La base de données ne raconte pas toujours toute l’histoire. Le code du plugin révèle souvent les noms d’options via des appels comme get_option(), update_option(), add_option() ou delete_option().

Pour chercher les options dans le dossier d’un plugin :

grep -RHinE "get_option|update_option|add_option|delete_option" \
  wp-content/plugins/addthis/ \
  --include='*.php'Code language: PHP (php)

Pour ne remonter que les lignes qui mentionnent update_option :

grep -RHin "update_option" wp-content/plugins/addthis/ --include='*.php'Code language: PHP (php)

Exemple de sortie :

wp-content/plugins/addthis/backend/AddThisRegistrationFeature.php:765:update_option('addthis_settings', $configs);Code language: PHP (php)

Cette méthode est très utile quand le plugin utilise un nom d’option générique ou stocke plusieurs réglages dans une seule grosse option sérialisée.

Attention aux données sérialisées

WordPress stocke souvent des tableaux PHP sérialisés dans option_value. Exemple :

a:2:{s:7:"enabled";b:1;s:8:"position";s:6:"bottom";}Code language: CSS (css)

Ne modifiez pas ce genre de valeur à la main dans phpMyAdmin si vous ne maîtrisez pas la sérialisation PHP. La longueur des chaînes est encodée dans la valeur. Une simple modification de texte peut casser toute l’option.

Pour modifier une option sérialisée, utilisez plutôt :

• l’interface du plugin, si elle existe encore ;
• wp option patch pour modifier une partie précise ;
• un script PHP contrôlé ;
• ou une migration testée sur staging.

Afficher une valeur sérialisée au format JSON aide déjà beaucoup :

wp option get addthis_settings --format=jsonCode language: JavaScript (javascript)

Créer un inventaire CSV des options d’un plugin

Pour documenter un audit client, produire un CSV propre est souvent plus pratique qu’une sortie terminal.

wp option list \
  --search='*addthis*' \
  --fields=option_name,autoload,size_bytes \
  --format=csv \
  > addthis-options-audit.csvCode language: PHP (php)

Vous pouvez ensuite ouvrir le fichier dans LibreOffice, Numbers, Excel ou l’importer dans un outil d’audit.

Pour un audit global des options lourdes :

wp option list \
  --fields=option_name,autoload,size_bytes \
  --orderby=size_bytes \
  --order=desc \
  --format=csv \
  > wp-options-largest.csvCode language: PHP (php)

Supprimer une option : seulement après vérification

Avant de supprimer, comptez, exportez, puis testez.

Compter les options visées :

wp db query "
SELECT COUNT(*) AS matching_options
FROM $(wp db prefix)options
WHERE option_name LIKE '%addthis%';
"Code language: PHP (php)

Exporter les lignes concernées :

wp db query "
SELECT *
FROM $(wp db prefix)options
WHERE option_name LIKE '%addthis%';
" > addthis-options-before-delete.sql.txtCode language: PHP (php)

Supprimer une option précise avec WP-CLI :

wp option delete addthis_settingsCode language: JavaScript (javascript)

Supprimer plusieurs options par motif demande plus de prudence. Affichez d’abord les lignes :

wp db query "
SELECT option_name
FROM $(wp db prefix)options
WHERE option_name LIKE '%addthis%';
"Code language: PHP (php)

Puis seulement, si le résultat est correct :

wp db query "
DELETE FROM $(wp db prefix)options
WHERE option_name LIKE '%addthis%';
"Code language: PHP (php)

Sur un site en production, je recommande de privilégier la suppression explicite, option par option, surtout si le motif est large. Un LIKE '%seo%', par exemple, peut faire beaucoup plus de dégâts que prévu. Le SQL aussi a le sens de l’humour, mais il rit rarement avec vous.

Nettoyer les transients liés à un plugin

Les transients sont des caches stockés en base, souvent dans wp_options. Ils peuvent être nombreux, mais tous ne sont pas problématiques.

Pour lister les transients qui contiennent une chaîne :

wp option list --transients --search='*addthis*' --fields=option_name,autoload,size_bytesCode language: PHP (php)

Pour supprimer les transients expirés :

wp transient delete --expiredCode language: JavaScript (javascript)

Pour supprimer tous les transients, à utiliser avec discernement :

wp transient delete --allCode language: JavaScript (javascript)

La suppression des transients ne devrait pas casser le site. En revanche, elle peut provoquer une reconstruction de cache et donc une charge temporaire. Sur une grosse boutique, faites-le au bon moment.

Cas multisite : cibler le bon site

Sur un réseau multisite, chaque site possède ses propres tables d’options, sauf les réglages réseau. Vous devez donc cibler le bon site avec --url.

wp site list

wp option list --url=https://example.com --search='*addthis*'Code language: PHP (php)

Pour les options réseau, utilisez les commandes de site option :

wp site option list --search='*addthis*'Code language: PHP (php)

Ne confondez pas option locale et option réseau. Sur multisite, cette confusion peut vous faire nettoyer le mauvais endroit avec une confiance admirable et parfaitement inutile.

Script Bash : auditer les options d’un plugin

Voici un script réutilisable pour générer un petit audit des options liées à une chaîne donnée.

#!/usr/bin/env bash

set -euo pipefail

SEARCH_TERM="${1:-}"
WP_PATH="${2:-$(pwd)}"
OUTPUT_DIR="${3:-/tmp/wp-options-audit}"

if [[ -z "${SEARCH_TERM}" ]]; then
  echo "Usage: $0 <search-term> [wp-path] [output-dir]"
  exit 1
fi

mkdir -p "${OUTPUT_DIR}"

cd "${WP_PATH}"

echo "WordPress path: ${WP_PATH}"
echo "Search term: ${SEARCH_TERM}"
echo "Output dir: ${OUTPUT_DIR}"
echo

echo "Export de la base..."
wp db export "${OUTPUT_DIR}/database-before-options-audit-$(date +%F-%H%M%S).sql"

echo "Inventaire CSV..."
wp option list \
  --search="*${SEARCH_TERM}*" \
  --fields=option_name,autoload,size_bytes \
  --format=csv \
  > "${OUTPUT_DIR}/${SEARCH_TERM}-options.csv"

echo "Export JSON des valeurs..."
while IFS= read -r option_name; do
  safe_name="$(printf '%s' "${option_name}" | tr -c 'A-Za-z0-9._-' '_')"
  wp option get "${option_name}" --format=json > "${OUTPUT_DIR}/${safe_name}.json" || true
done < <(wp option list --search="*${SEARCH_TERM}*" --field=option_name)

echo "Options trouvées :"
cat "${OUTPUT_DIR}/${SEARCH_TERM}-options.csv"

echo
echo "Terminé."Code language: PHP (php)

Rendez-le exécutable :

chmod +x audit-plugin-options.shCode language: CSS (css)

Lancez-le depuis la racine WordPress :

./audit-plugin-options.sh addthis

Ou avec un chemin explicite :

./audit-plugin-options.sh addthis /var/www/example.com/public ~/audits/addthisCode language: JavaScript (javascript)

Méthode de décision : supprimer, désactiver l’autoload ou garder ?

Une fois les options identifiées, ne supprimez pas tout mécaniquement. Classez-les plutôt.

Situation	Action recommandée
Plugin encore actif	Ne supprimez pas. Vérifiez plutôt l’autoload et la taille.
Plugin désinstallé proprement	Exportez, puis supprimez les options clairement orphelines.
Option lourde mais encore utile	Gardez-la, mais envisagez de désactiver l’autoload.
Transient expiré	Supprimez avec wp transient delete --expired.
Option de licence ancienne	Supprimez seulement si le plugin n’est plus utilisé.
Option inconnue	Recherchez dans le code avant toute suppression.

Le bon nettoyage n’est pas celui qui supprime le plus de lignes. C’est celui qui supprime les bonnes lignes, sans casser le comportement applicatif.

Après nettoyage : vérifier le site

Après modification, vérifiez le site immédiatement.

wp cache flush
wp option list --autoload=on --format=total_bytes
wp cron event listCode language: PHP (php)

Contrôlez aussi :

• la page d’accueil ;
• l’administration WordPress ;
• les pages critiques ;
• le panier et le checkout WooCommerce ;
• les formulaires ;
• les logs PHP et serveur ;
• les tâches cron WordPress.

Si vous nettoyez une grosse extension, relisez aussi désinstaller Jetpack proprement avec WP-CLI. Le principe reste le même : identifier, sauvegarder, supprimer, vérifier.

Erreurs fréquentes à éviter

Chercher uniquement autoload = yes

C’est incomplet sur les versions modernes de WordPress. Incluez aussi on, auto-on et auto lorsque vous auditez les options autoloadées.

Supprimer par motif trop large

Une requête comme LIKE '%mail%' peut toucher beaucoup plus qu’un seul plugin. Prévisualisez toujours les lignes avant suppression.

Modifier une valeur sérialisée à la main

Évitez. Une chaîne sérialisée cassée peut rendre une option illisible. Utilisez WP-CLI, PHP ou l’interface du plugin.

Nettoyer directement en production

Sur un site critique, testez sur staging. Une base de données, ce n’est pas un brouillon Google Docs.

Oublier les autres tables

Un plugin peut stocker des données dans postmeta, usermeta, termmeta, posts ou ses propres tables. wp_options n’est qu’un point de départ.

Articles connexes utiles

Pour aller plus loin dans le nettoyage et l’audit de base WordPress, vous pouvez lire :

• Désinstaller proprement WPML et nettoyer la base de données avec WP-CLI ;
• Nettoyer complètement la base de données WordPress après la désinstallation d’Elementor ;
• WordPress : désinstaller Jetpack proprement avec WP-CLI ;
• Convertir des tables WordPress de MyISAM à InnoDB avec WP-CLI ;
• Résoudre le problème de la table wp_options sans colonne Unique ni Primary Key ;
• Migrer WordPress vers un nouveau serveur avec WP-CLI.

FAQ

Puis-je supprimer toutes les options d’un plugin désinstallé ?

Pas toujours. Vérifiez d’abord que le plugin n’est plus actif, exportez les lignes concernées, puis testez sur staging. Certaines options peuvent être partagées avec un add-on, un thème ou une intégration.

Une grosse option dans wp_options est-elle forcément mauvaise ?

Non. Une grosse option non autoloadée peut être acceptable si elle sert rarement. Une grosse option autoloadée mérite en revanche une vraie vérification.

Faut-il vider tous les transients ?

Pas systématiquement. Supprimer les transients expirés est raisonnable. Supprimer tous les transients peut provoquer une reconstruction de cache et une charge temporaire.

Pourquoi éviter phpMyAdmin pour modifier option_value ?

Parce que beaucoup d’options contiennent des données sérialisées. Une modification manuelle peut casser la structure. WP-CLI et le code PHP gèrent mieux ces valeurs.

Comment savoir si une option appartient vraiment à un plugin ?

Croisez plusieurs indices : préfixe du nom, valeur stockée, recherche dans le code du plugin, présence dans les logs, et comportement sur staging après désactivation ou suppression.

Dois-je désactiver l’autoload de toutes les options lourdes ?

Non. Désactivez l’autoload seulement si l’option n’est pas nécessaire sur chaque requête. Sinon, vous risquez de déplacer le problème au lieu de le résoudre.

Conclusion

Identifier les options WordPress liées à un plugin n’a rien de compliqué avec WP-CLI. La vraie difficulté consiste à décider quoi garder, quoi désactiver en autoload, et quoi supprimer sans casser le site.

Commencez par chercher dans option_name, inspectez option_value, vérifiez l’autoload, puis recherchez dans le code du plugin. Ensuite seulement, passez au nettoyage.

Une base WordPress propre ne vient pas d’un gros bouton “optimiser”. Elle vient d’un audit méthodique, d’une sauvegarde utilisable, et d’un peu de respect pour wp_options. Cette table a bonne mémoire. Parfois trop bonne.

Sources

• WP-CLI : wp option list
• WP-CLI : wp option get-autoload
• WP-CLI : wp option set-autoload
• WordPress Developer Resources : wp_autoload_values_to_autoload()
• WordPress Developer Resources : wp_determine_option_autoload_value()
• Make WordPress Core : Options API and autoload values

Report a typo