Interdire la modification d’un article local après sa mise en ligne définitive

Publié n’est pas synonyme d’intangible : le statut natif publish de WordPress autorise sans restriction la modification ultérieure d’un contenu, contrairement à ce que suppose souvent un lecteur qui partage un article. Un rédacteur en chef d’un site d’actualités locales a mesuré cet écart après qu’un article avait été discrètement modifié plusieurs heures après sa publication, sans que personne n’ait de trace claire de ce changement ni de justification éditoriale.

Pour une rédaction locale, l’intégrité d’un article publié compte autant que son exactitude au moment de la mise en ligne : un lecteur qui partage un article doit pouvoir faire confiance à ce qu’il continuera d’y trouver. La réponse technique retenue introduit un statut de publication distinct, qui verrouille les champs de contenu une fois atteint.

Un second statut, au-delà du simple publié

Le statut natif publish reste utilisé pour la mise en ligne initiale, qui autorise encore des corrections rapides en cas d’erreur détectée dans l’heure suivant la publication. Un champ personnalisé publication_definitive, activé manuellement par le rédacteur en chef après cette fenêtre de correction, déclenche ensuite le verrouillage complet.

add_action( 'add_meta_boxes', function () {
    add_meta_box( 'ch_verrou_publication', 'Verrouillage éditorial', function ( $post ) {
        $verrouille = get_post_meta( $post->ID, 'publication_definitive', true );

        if ( $verrouille ) {
            echo '<p>Cet article est verrouillé : son contenu ne peut plus être modifié.</p>';
            return;
        }

        if ( ! current_user_can( 'manage_options' ) ) {
            echo '<p>Seul un rédacteur en chef peut verrouiller cet article.</p>';
            return;
        }

        echo '<label><input type="checkbox" name="publication_definitive" value="1" /> Verrouiller définitivement cet article</label>';
    }, 'post', 'side' );
} );

Empêcher toute modification une fois le verrou activé

Le verrouillage réel se joue au moment de l’enregistrement : si l’article est déjà marqué comme définitif, toute tentative de modification du titre ou du contenu est purement et simplement ignorée, quel que soit le rôle de la personne connectée, hors exception explicite décrite plus loin.

add_filter( 'wp_insert_post_data', function ( $data, $postarr ) {
    if ( 'post' !== $data['post_type'] || empty( $postarr['ID'] ) ) {
        return $data;
    }

    $verrouille = get_post_meta( $postarr['ID'], 'publication_definitive', true );

    if ( $verrouille && ! current_user_can( 'manage_options' ) ) {
        $data['post_title']   = get_the_title( $postarr['ID'] );
        $data['post_content'] = get_post_field( 'post_content', $postarr['ID'] );
    }

    return $data;
}, 10, 2 );

Cette écriture restaure silencieusement l’ancien titre et l’ancien contenu si une modification est tentée par un rôle non autorisé, plutôt que de bloquer l’enregistrement avec une erreur qui interromprait le travail de l’utilisateur sur d’autres champs légitimement modifiables, comme les catégories ou une note interne de suivi.

Réserver la levée du verrou à un rôle précis

Seul le rôle de rédacteur en chef, identifié par la capacité manage_options dans cet exemple simplifié, peut décocher le verrouillage en cas d’erreur avérée nécessitant une correction. Cette exception reste tracée, avec un champ historique_deverrouillage qui enregistre qui a levé le verrou, quand, et pourquoi.

add_action( 'save_post', function ( $post_id ) {
    $verrouille_avant = get_post_meta( $post_id, 'publication_definitive', true );
    $verrouille_apres = isset( $_POST['publication_definitive'] );

    if ( $verrouille_avant && ! $verrouille_apres && current_user_can( 'manage_options' ) ) {
        $historique = get_post_meta( $post_id, 'historique_deverrouillage', true ) ?: array();
        $historique[] = array(
            'utilisateur' => wp_get_current_user()->user_login,
            'date'        => current_time( 'mysql' ),
        );
        update_post_meta( $post_id, 'historique_deverrouillage', $historique );
    }

    update_post_meta( $post_id, 'publication_definitive', $verrouille_apres ? 1 : $verrouille_avant );
} );

Ce que cette organisation ne prétend pas résoudre

Ce mécanisme protège le contenu éditorial contre une modification discrète non justifiée, mais il ne traite volontairement pas la gestion des droits de rectification légale, qui répond à des obligations distinctes et peut nécessiter, selon la nature de l’erreur signalée par un lecteur ou une personne concernée, une procédure de correction encadrée différemment du simple verrouillage éditorial interne.

• Une correction typographique mineure peut passer par un encart signalé « mise à jour », ajouté sous l’article verrouillé, sans déverrouiller le corps du texte original.
• Une erreur factuelle plus grave justifie une procédure de déverrouillage tracée, suivie d’une nouvelle vérification avant reverrouillage.
• Le champ date de publication reste, lui, modifiable même après verrouillage, car il ne concerne pas le contenu éditorial proprement dit.

Verrouiller un article n’est pas un signe de rigidité : c’est la garantie que ce que le lecteur a lu reste ce qu’il retrouvera en revenant sur la page.

Pour aller plus loin

Ce mécanisme de verrouillage éditorial, une fois en place sur les articles, peut s’étendre aux commentaires associés ou aux métadonnées de référencement, avec la même logique de statut distinct et de capacité restreinte pour toute levée du verrou.