# Purger les révisions d’articles en base pour libérer de l’espace disque sur un mutualisé

> Une purge sûre des révisions d'articles WordPress avec WP-CLI, complétée par un cron de maintenance régulier, pour reprendre de l'espace sur un mutualisé limité.

- Auteur : WordPress Développement
- Publié le : 2020-12-03
- Mis à jour le : 2020-12-03
- Catégorie : Hébergement & serveurs
- URL : https://www.wpmoderne.fr/hebergement/purger-revisions-wp-cli-espace-disque-mutualise/

## L’essentiel

- Chaque enregistrement compte les révisions comme des lignes de wp_posts
- wp post list filtre précisément par type révision
- Un cron régulier évite de revivre la même saturation

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.

> L'essentiel à retenir : Chaque enregistrement compte les révisions comme des lignes de wp_posts ; wp post list filtre précisément par type révision ; Un cron régulier évite de revivre la même saturation

## 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 -n` pour 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.