# WP_POST_REVISIONS dans wp-config.php : ce qu’une extension doit respecter

> Cette constante définie dans wp-config.php encadre le nombre de révisions conservées. Une extension qui écrit ses propres routines de sauvegarde ne peut pas l'ignorer.

- Auteur : WordPress Développement
- Publié le : 2020-12-08
- Mis à jour le : 2020-12-08
- Catégorie : Extensions
- URL : https://www.wpmoderne.fr/extensions/wp-post-revisions-wp-config-extension-doit-respecter/

## L’essentiel

- La constante se lit, ne se contourne jamais en code
- wp_save_post_revision respecte déjà la limite
- Une routine maison doit vérifier avant d'insérer

« La documentation officielle du Codex précise que WP_POST_REVISIONS accepte trois formes : un booléen ou un entier », rappelle la page dédiée aux constantes de configuration. Cette formulation simple cache une constante dont le comportement exact mérite d'être compris avant d'écrire la moindre routine de sauvegarde personnalisée dans une extension.

Définie dans `wp-config.php`, cette constante contrôle combien de versions antérieures d'un contenu WordPress conserve automatiquement. Une extension qui enregistre ses propres versions d'un contenu, par exemple pour un système d'approbation éditoriale, doit composer avec cette limite plutôt que la contourner.

## Les trois valeurs possibles et leurs effets

- `true` (valeur par défaut si la constante n'est pas définie) : nombre de révisions illimité
- `false` : aucune révision n'est enregistrée, la fonctionnalité est désactivée
- Un entier positif, par exemple `5` : WordPress conserve au maximum ce nombre de révisions par contenu, en supprimant les plus anciennes

```
// Dans wp-config.php
define( 'WP_POST_REVISIONS', 5 );
```

## Comment WordPress applique la limite en interne

La fonction `wp_save_post_revision()`, appelée automatiquement à chaque enregistrement d'un contenu qui supporte les révisions, lit cette constante via `wp_revisions_to_keep()` avant de décider s'il faut créer une nouvelle révision et, le cas échéant, en supprimer une plus ancienne pour respecter la limite.

```
$nombre_max = wp_revisions_to_keep( $post );

if ( 0 === $nombre_max ) {
    return;
}
```

Ce filtre `wp_revisions_to_keep` constitue d'ailleurs le point d'extension officiel si une extension a besoin d'ajuster la limite pour un type de contenu précis, sans toucher à la constante globale qui s'applique à l'ensemble du site :

```
add_filter( 'wp_revisions_to_keep', function( $nombre, $post ) {
    if ( 'contrat' === $post->post_type ) {
        return 20;
    }
    return $nombre;
}, 10, 2 );
```

> L'essentiel à retenir : La constante se lit, ne se contourne jamais en code ; wp_save_post_revision respecte déjà la limite ; Une routine maison doit vérifier avant d'insérer

## Ce qu'une routine maison ne doit pas faire

Une extension qui construit son propre mécanisme de versionnage, par exemple pour horodater des snapshots d'un contenu avant une action métier particulière, tombe parfois dans le piège d'insérer directement des lignes dans la table `wp_posts` avec `post_type => 'revision'`, en ignorant la limite configurée. Cela crée deux problèmes distincts.

### Une incohérence entre deux sources de vérité

Si une extension insère ses propres révisions sans passer par `wp_save_post_revision()`, l'écran natif de comparaison des révisions affiche un mélange de versions générées par WordPress et par l'extension, sans que la limite configurée s'applique de façon homogène aux deux origines.

### Un nettoyage qui ne se déclenche jamais

Le nettoyage automatique des révisions excédentaires repose sur le passage par les fonctions natives. Des révisions insérées directement en base, en dehors de ce circuit, s'accumulent indéfiniment, même si la constante limite le nombre à cinq pour les révisions générées normalement.

## La bonne pratique : passer par wp_save_post_revision ou vérifier soi-même

```
$revision_id = wp_save_post_revision( $post_id );

if ( $revision_id ) {
    update_post_meta( $revision_id, 'wpm_declencheur', 'validation_editoriale' );
}
```

Réutiliser `wp_save_post_revision()` garantit que la limite configurée dans `wp-config.php`, ou ajustée via le filtre, s'applique de façon uniforme, tout en profitant de l'écran de comparaison natif pour retrouver ces versions plus tard.

| Approche | Respecte la limite | Visible dans l'écran natif |
| --- | --- | --- |
| wp_save_post_revision() | Oui | Oui |
| Insertion directe en base | Non, sauf code additionnel | Partiellement |
| Table personnalisée dédiée | Sans objet | Non, écran séparé requis |

> Avant d'écrire une ligne de code pour versionner un contenu, la première question à se poser est si le mécanisme natif de révisions, avec son filtre d'ajustement, ne couvre pas déjà le besoin.

## En résumé

WP_POST_REVISIONS n'est pas qu'un réglage de configuration à ignorer une fois défini : c'est une limite que toute routine de sauvegarde personnalisée doit respecter, soit en réutilisant les fonctions natives, soit en appliquant sa propre limite cohérente si une table dédiée est réellement justifiée par le besoin.