Sur un hébergement mutualisé, où le quota d’espace disque alloué à la base de données est souvent bien plus serré que l’espace fichiers, une table wp_posts jamais purgée peut représenter une part surprenante du volume total : chaque modification enregistrée d’un article génère une nouvelle ligne de révision, indéfiniment, tant que la fonctionnalité n’est pas limitée.
Cette situation devient un vrai problème quand le quota de la base de données approche sa limite, en particulier sur un mutualisé associatif ou un compte d’entrée de gamme où l’espace attribué à MySQL est compté en centaines de mégaoctets plutôt qu’en gigaoctets. WP-CLI permet de purger ces révisions de façon ciblée, sans toucher au contenu réel des articles.
Comprendre ce qu’une révision représente en base
Chaque révision est un enregistrement à part entière dans la table wp_posts, avec le type revision et un post_parent qui pointe vers l’article original. Un article modifié cinquante fois génère cinquante lignes de révision, chacune stockant le contenu complet du texte à l’instant de la sauvegarde, pas seulement la différence avec la version précédente.
Pour mesurer l’ampleur du problème avant d’agir, WP-CLI permet de compter précisément les révisions présentes en base :
wp post list --post_type=revision --format=count
Sur un site actif depuis plusieurs années sans limitation des révisions, ce chiffre peut atteindre plusieurs dizaines de milliers d’enregistrements, pour un contenu éditorial qui, lui, ne représente qu’une fraction de cet espace.
Purger les révisions existantes avec WP-CLI
La purge se fait en listant précisément les identifiants des révisions, puis en les supprimant un par un via la commande de suppression de contenu, avec l’option --force pour un effacement définitif plutôt qu’une simple mise à la corbeille :
wp post list --post_type=revision --format=ids | xargs -n 20 wp post delete --force
Le paramètre -n 20 découpe la liste des identifiants en lots de vingt, ce qui évite de lancer une commande unique avec des dizaines de milliers d’arguments et limite la charge instantanée sur la base de données. Sur un mutualisé, cette précaution évite de saturer brutalement les connexions MySQL disponibles.
Vérifier le gain obtenu
Après la purge, un OPTIMIZE TABLE sur la table wp_posts permet de récupérer physiquement l’espace libéré, MySQL ne restituant pas automatiquement l’espace disque après une suppression massive de lignes :
wp db optimize
Cette commande WP-CLI encapsule l’optimisation de l’ensemble des tables de la base, révisions comprises. Sur un mutualisé, il est utile de vérifier ensuite l’espace réellement consommé par la base depuis le panneau d’hébergement, l’affichage pouvant mettre quelques minutes à se mettre à jour selon l’hébergeur.
Mettre en place un cron de maintenance régulier
Purger une fois ne suffit pas : sans limitation en amont, les révisions recommencent à s’accumuler dès la prochaine modification d’article. Un cron mensuel, exécuté via WP-CLI, permet d’automatiser la purge sans intervention manuelle :
0 3 15 * * wp post list --post_type=revision --format=ids --path=/var/www/monsite | xargs -n 20 wp post delete --force --path=/var/www/monsite
Ce cron s’exécute le quinzième jour de chaque mois à trois heures du matin, une plage horaire à faible trafic sur la plupart des sites. Le paramètre --path indique à WP-CLI où trouver l’installation WordPress concernée, ce qui est nécessaire lorsque la commande est lancée depuis un cron système plutôt que depuis le répertoire du site.
- Compter les révisions existantes avant toute purge
- Supprimer par lots avec
xargs -npour ne pas saturer la base - Optimiser les tables après une purge massive
- Planifier un cron régulier pour éviter la récidive
Sur les mutualisés associatifs que nous suivons, cette purge mensuelle a suffi, à elle seule, à repousser de plusieurs mois la nécessité de changer de formule d’hébergement.
En résumé
Les révisions d’articles, invisibles au quotidien, peuvent représenter une part significative du quota de base de données sur un hébergement mutualisé. WP-CLI permet de les compter, de les purger par lots sans saturer la base, puis de planifier un cron mensuel qui évite d’avoir à répéter l’opération à la main à chaque alerte de quota.
