Une association de défense des consommateurs publiait régulièrement des articles nommant des entreprises mises en cause dans des litiges. Une fois, un article encore en cours de vérification juridique était parti en ligne par erreur, un membre de l’équipe ayant cliqué sur « Publier » en pensant enregistrer un simple brouillon. Aucun blocage technique n’existait pour distinguer un contenu sensible d’un article ordinaire.
La solution retenue : un panneau ajouté à l’étape de pré-publication de l’éditeur de blocs, avec une case à cocher explicite obligeant la personne à confirmer consciemment qu’elle a vérifié les points sensibles, avant que le bouton de publication ne devienne actif.
Le panneau de pré-publication, une extension native de l’éditeur
L’éditeur de blocs propose un composant dédié pour ce cas d’usage exact : PluginPrePublishPanel, du module @wordpress/edit-post. Il insère un bloc de contenu personnalisé directement dans le panneau qui s’affiche juste avant la confirmation finale de publication, là où l’utilisateur porte déjà toute son attention :
const { registerPlugin } = wp.plugins;
const { PluginPrePublishPanel } = wp.editPost;
const { useState } = wp.element;
const { useDispatch, useSelect } = wp.data;
function PanneauConfirmationSensible() {
const [ confirme, setConfirme ] = useState( false );
const { lockPostSaving, unlockPostSaving } = useDispatch( 'core/editor' );
const estSensible = useSelect( ( select ) =>
select( 'core/editor' ).getEditedPostAttribute( 'meta' )?.contenu_sensible
, [] );
if ( ! estSensible ) {
return null;
}
return wp.element.createElement(
PluginPrePublishPanel,
{ title: 'Vérification obligatoire', initialOpen: true },
wp.element.createElement( 'label', null,
wp.element.createElement( 'input', {
type: 'checkbox',
checked: confirme,
onChange: ( evenement ) => {
const coche = evenement.target.checked;
setConfirme( coche );
if ( coche ) {
unlockPostSaving( 'confirmation-sensible' );
} else {
lockPostSaving( 'confirmation-sensible' );
}
}
} ),
' Je confirme avoir vérifié les éléments juridiques de cet article avec le service concerné.'
)
);
}
registerPlugin( 'confirmation-sensible', { render: PanneauConfirmationSensible } );
Verrouiller la publication tant que la case n’est pas cochée
Le cœur du mécanisme repose sur lockPostSaving() et unlockPostSaving(), deux actions du store core/editor qui permettent d’imposer, ou de lever, un verrou nommé sur l’enregistrement de l’article. Tant qu’un seul verrou actif existe, quel que soit son nom, le bouton de publication reste désactivé dans toute l’interface. Il faut cependant poser ce verrou dès le chargement initial si le contenu est marqué sensible, pas seulement en réaction à un décochage :
wp.domReady( function () {
const estSensible = wp.data.select( 'core/editor' ).getEditedPostAttribute( 'meta' )?.contenu_sensible;
if ( estSensible ) {
wp.data.dispatch( 'core/editor' ).lockPostSaving( 'confirmation-sensible' );
}
} );
Marquer un article comme sensible
Le marquage repose sur une meta booléenne classique, ajoutée via un panneau de document standard ou une simple case dans une métabox PHP existante, enregistrée avec register_post_meta() et exposée à l’éditeur via show_in_rest :
add_action( 'init', function () {
register_post_meta( 'post', 'contenu_sensible', array(
'type' => 'boolean',
'single' => true,
'show_in_rest' => true,
'auth_callback' => function () {
return current_user_can( 'edit_posts' );
},
) );
} );
Un rappel textuel, pas seulement un blocage muet
Un blocage sans explication frustre plus qu’il ne protège : si le bouton de publication reste grisé sans qu’aucun message n’indique pourquoi, l’équipe risque de contourner la fonctionnalité en cherchant une autre voie de publication (planification immédiate, par exemple). Le texte de la case à cocher doit donc être explicite sur ce qui est réellement attendu — ici, une vérification juridique précise, pas une simple relecture orthographique.
Compléter avec une vérification côté serveur
Le verrou JavaScript protège l’interface, mais un appel direct à l’API REST (via un script externe ou une intégration tierce) pourrait le contourner. Une vérification complémentaire côté serveur, sur le hook save_post, reste recommandée pour les cas où la sensibilité du contenu justifie une garantie plus stricte que le seul confort d’interface :
add_filter( 'wp_insert_post_data', function ( $donnees, $postarr ) {
if ( 'publish' !== $donnees['post_status'] ) {
return $donnees;
}
$sensible = get_post_meta( $postarr['ID'], 'contenu_sensible', true );
$confirme = get_post_meta( $postarr['ID'], '_confirmation_juridique', true );
if ( $sensible && ! $confirme ) {
$donnees['post_status'] = 'pending';
}
return $donnees;
}, 10, 2 );
- Réservez ce mécanisme aux contenus réellement à risque : un verrou systématique sur tous les articles finirait par être ignoré par habitude.
- Testez le comportement avec la publication programmée, pas uniquement avec le bouton de publication immédiate.
- Documentez clairement, dans le texte de la case, ce qui doit être vérifié avant de cocher.
Sur les contenus à risque juridique ou d’image, je recommande toujours de doubler le confort d’interface (le verrou JavaScript) d’une vérification côté serveur : l’un protège l’expérience de rédaction, l’autre protège réellement contre une publication accidentelle par un autre canal.
Pour aller plus loin
Ce mécanisme de verrouillage conditionnel, basé sur lockPostSaving() et unlockPostSaving(), peut s’appliquer à d’autres cas de figure : vérification d’une traduction avant publication multilingue, validation d’un embargo de date, ou contrôle qu’une image dispose bien de ses droits d’utilisation confirmés. Le principe reste identique dans tous les cas : rendre visible, au bon moment, une vérification qui ne doit jamais être sautée.
