Chaque fois qu’un article est enregistré, que ce soit manuellement ou via l’enregistrement automatique de l’éditeur toutes les minutes, WordPress crée une révision : une copie complète du contenu à cet instant précis. C’est une fonctionnalité précieuse pour revenir en arrière après une erreur, comparer deux versions, ou retrouver un paragraphe supprimé par mégarde. Mais sans limite, ce mécanisme peut faire gonfler la table wp_posts de façon significative sur des contenus souvent retravaillés.
Cet article détaille comment limiter, affiner et nettoyer les révisions, sans jamais perdre le bénéfice réel de cette fonctionnalité.
Comprendre le coût réel des révisions
Une révision est stockée exactement comme un article, dans la même table wp_posts, avec un post_type à revision. Un article retravaillé pendant plusieurs semaines, avec de nombreux enregistrements automatiques, peut accumuler des dizaines de révisions. Sur un site avec des centaines de contenus dans ce cas, l’impact sur la taille de la base de données devient réel, avec un effet notable sur la vitesse des sauvegardes et des requêtes d’administration.
wp post list --post_type=revision --format=count
Cette commande WP-CLI donne rapidement une idée du volume de révisions accumulées sur un site, souvent bien plus élevé que ce à quoi on s’attend sur un site actif depuis plusieurs années.
Limiter le nombre de révisions conservées
La constante WP_POST_REVISIONS, à placer dans wp-config.php, fixe une limite globale au nombre de révisions conservées par contenu. Au-delà de cette limite, la révision la plus ancienne est supprimée automatiquement à chaque nouvel enregistrement :
define( 'WP_POST_REVISIONS', 10 );
Il est aussi possible de désactiver totalement les révisions, une option rarement recommandée tant elle prive d’un vrai filet de sécurité en cas d’erreur de manipulation :
define( 'WP_POST_REVISIONS', false );

Affiner la limite par type de contenu
Le filtre wp_revisions_to_keep permet un réglage plus fin que la constante globale, en fonction du type de contenu concerné. Utile par exemple pour conserver davantage d’historique sur des pages légales, régulièrement révisées, et moins sur de simples articles de blog :
add_filter( 'wp_revisions_to_keep', function( $nombre, $post ) {
if ( 'page' === $post->post_type && has_term( 'legal', 'page_category', $post ) ) {
return 30;
}
return $nombre;
}, 10, 2 );
Nettoyer les révisions existantes
Changer la constante WP_POST_REVISIONS n’a d’effet que sur les futurs enregistrements. Pour nettoyer les révisions déjà accumulées, une intervention explicite est nécessaire. WP-CLI permet de cibler précisément les contenus de type revision :
wp post list --post_type=revision --format=ids | xargs wp post delete --force
Cette commande supprime l’ensemble des révisions existantes sur le site. Elle doit être utilisée avec prudence : une sauvegarde de la base de données avant exécution reste une précaution élémentaire, en particulier sur un site où l’historique de certaines pages a une vraie valeur pour l’équipe éditoriale.
Comparer deux révisions dans l’administration
L’écran de comparaison de révisions, accessible depuis l’historique d’un article, reste sous-utilisé alors qu’il rend un vrai service : il affiche les différences ligne par ligne entre deux versions, avec le texte ajouté en surbrillance verte et le texte supprimé barré en rouge. Un réflexe utile avant de restaurer une ancienne version en urgence, pour vérifier précisément ce qui serait perdu par la restauration.
Le cas particulier de l’enregistrement automatique
L’éditeur de blocs enregistre automatiquement le contenu en brouillon local toutes les minutes environ, sans forcément créer de révision à chaque fois : WordPress espace ces créations pour éviter une accumulation excessive. Le comportement exact dépend de la fréquence de modification réelle du contenu et du délai AUTOSAVE_INTERVAL, personnalisable si besoin :
define( 'AUTOSAVE_INTERVAL', 120 ); // en secondes
Bonnes pratiques à retenir
- Fixer une limite raisonnable avec
WP_POST_REVISIONSdès le lancement d’un projet, plutôt que de nettoyer après coup - Affiner cette limite par type de contenu quand certains contenus méritent un historique plus long
- Nettoyer périodiquement les révisions existantes sur un site ancien, après sauvegarde
- Ne jamais désactiver totalement les révisions sur un site avec plusieurs rédacteurs
Sur un site avec plusieurs rédacteurs, les révisions ont déjà sauvé plus d’un article après une modification malheureuse : les désactiver complètement pour gagner quelques mégaoctets n’en vaut presque jamais la peine.
En résumé
Les révisions rendent un service réel, mais leur accumulation sans limite finit par peser sur la base de données d’un site actif depuis plusieurs années. Une limite raisonnable fixée dès le départ, éventuellement affinée par type de contenu, associée à un nettoyage ponctuel des révisions déjà accumulées, permet de garder le bénéfice de cette fonctionnalité sans en subir les inconvénients.