# Les révisions de contenu gonflent wp_posts : l’impact sur une sauvegarde > Sur un site à plusieurs dizaines d'auteurs, mesurer précisément ce que des révisions illimitées coûtent en taille de table et en temps de sauvegarde complète. - Auteur : Clément Hadrot - Publié le : 2022-10-09 - Mis à jour le : 2022-10-09 - Catégorie : Performance - URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/revisions-contenu-gonflent-wp-posts-sauvegarde/ ## L’essentiel - Chaque enregistrement d'un brouillon crée une nouvelle ligne de révision - Sans limite, ce nombre croît indéfiniment tant que l'article est modifié - WP_POST_REVISIONS et wp cli post delete-orphaned-revisions permettent de reprendre le contrôle 41 révisions accumulées pour un seul article de blog interne, rédigé collectivement par plusieurs contributeurs sur plusieurs semaines : c'est le chiffre relevé lors d'un audit de la table `wp_posts` sur un site d'entreprise regroupant les publications d'une cinquantaine de rédacteurs internes, sans limite de révisions configurée depuis l'installation initiale du site. Chaque révision correspond à une ligne complète dans `wp_posts`, avec `post_type` réglé sur `revision`, stockant une copie intégrale du contenu de l'article à un instant donné. Ce mécanisme, activé par défaut sans limite depuis les débuts de WordPress, protège efficacement contre la perte de contenu, mais son coût cumulé reste rarement mesuré tant qu'un incident de sauvegarde ne le rend pas visible. ## Mesurer le volume réel occupé par les révisions ``` SELECT COUNT(*) AS nb_revisions, ROUND(SUM(LENGTH(post_content)) / 1024 / 1024, 2) AS taille_mo FROM wp_posts WHERE post_type = 'revision'; ``` Sur ce site, la requête a révélé plus de 38 000 lignes de révisions, représentant à elles seules près de 620 mégaoctets de contenu textuel brut, sur une base de données totale d'environ 900 mégaoctets. Les révisions représentaient donc plus des deux tiers du volume total de la base, pour un contenu qui n'est jamais consulté en dehors d'un besoin ponctuel de restauration d'une version antérieure. ## L'impact concret sur la sauvegarde Le temps d'exécution d'une sauvegarde complète via `mysqldump` était directement proportionnel à ce volume : sur ce projet, la sauvegarde quotidienne automatisée dépassait régulièrement 12 minutes, contre moins de 4 minutes après nettoyage des révisions orphelines, un facteur trois qui affectait directement la fenêtre de maintenance nocturne réservée à cette tâche. > L'essentiel à retenir : Chaque enregistrement d'un brouillon crée une nouvelle ligne de révision ; Sans limite, ce nombre croît indéfiniment tant que l'article est modifié ; WP_POST_REVISIONS et wp cli post delete-orphaned-revisions permettent de reprendre le contrôle ## Reprendre le contrôle sans perdre l'historique récent ### Limiter le nombre de révisions conservées pour l'avenir ``` // À placer dans wp-config.php, avant la ligne "That's all, stop editing!" define('WP_POST_REVISIONS', 10); ``` Cette constante limite, pour chaque article, le nombre de révisions conservées à dix, les plus anciennes étant automatiquement supprimées à mesure que de nouvelles sont créées. Elle ne s'applique qu'aux futures révisions : les 38 000 lignes déjà accumulées restent en base tant qu'aucun nettoyage explicite n'est effectué. ### Nettoyer l'historique existant via WP-CLI ``` wp post list --post_type=revision --format=count wp post delete $(wp post list --post_type=revision --field=ID) --force ``` Sur un volume important, cette suppression doit être effectuée par lots plutôt qu'en une seule commande géante, pour éviter de saturer la mémoire du processus WP-CLI et pour pouvoir suivre la progression réelle du nettoyage sur un site en production. ## Ce qu'il faut garder en tête après le nettoyage - Une limite de dix révisions reste généreuse pour la majorité des flux de rédaction, tout en réduisant considérablement le volume accumulé. - Un contenu particulièrement sensible, contractuel par exemple, peut justifier une limite plus haute ou une exportation manuelle périodique avant nettoyage. - Réexécuter l'audit de volume tous les six mois permet de vérifier que la limite choisie reste adaptée à l'usage réel constaté. ## Automatiser une surveillance régulière Pour éviter de revivre la même surprise, une tâche planifiée hebdomadaire a été mise en place, exécutant la requête de mesure de volume et envoyant une alerte par courriel interne si le nombre de révisions dépasse un seuil défini. Cette surveillance légère permet d'agir avant que le volume ne redevienne problématique, plutôt que d'attendre qu'un ralentissement de sauvegarde ne le signale à nouveau de façon indirecte. ``` wp cron event schedule verifier_volume_revisions now weekly ``` ### Un point de vigilance sur les articles collaboratifs Sur les contenus rédigés à plusieurs mains, une limite de révisions trop basse peut effacer des versions intermédiaires qu'un contributeur souhaitait encore pouvoir consulter quelques jours plus tard. La limite de dix retenue ici correspond à un compromis jugé raisonnable pour ce site précis, mais elle mérite d'être ajustée selon le rythme réel de collaboration observé sur chaque projet plutôt que copiée telle quelle. ## En résumé Les révisions de contenu, invisibles au quotidien, peuvent représenter une part majoritaire du volume d'une base de données WordPress active depuis plusieurs années sans limite configurée. Le signal le plus fiable pour s'en rendre compte reste le temps de sauvegarde complète, qui croît silencieusement tant que personne ne va vérifier ce que contient réellement la table `wp_posts`.