Sur un site associatif où les contributeurs rédigent des comptes rendus d’activité sans droit de publication directe, l’un d’eux m’a écrit, un peu perplexe : « J’ai cliqué sur Publier, mais mon article dit toujours En attente de relecture, c’est normal ? » C’est parfaitement normal : un contributeur ne peut pas publier directement, WordPress place son contenu en statut « en attente de relecture » (pending). Le problème, c’est que le bouton affichait quand même le mot « Publier », ce qui créait une confusion légitime.
La correction ne nécessite pas de reconstruire l’écran d’édition : le libellé du bouton est une simple chaîne traduisible, interceptable avec le filtre gettext, à condition de cibler la bonne chaîne et de vérifier le rôle réel de la personne connectée.
Repérer la chaîne exacte à remplacer
Le bouton de l’éditeur de blocs affiche « Publier… » pour un utilisateur autorisé à publier, et bascule normalement lui-même sur un libellé différent pour les rôles inférieurs selon le thème d’administration utilisé — mais ce comportement natif n’est pas toujours suffisamment explicite. Sur ce projet, le libellé restait « Publier… » même pour les contributeurs, ce qui laissait penser à une publication effective immédiate.
Le filtre gettext ciblé
add_filter( 'gettext', function ( $traduction, $texte, $domaine ) {
if ( 'default' !== $domaine || 'Publish' !== $texte ) {
return $traduction;
}
$ecran = function_exists( 'get_current_screen' ) ? get_current_screen() : null;
if ( ! $ecran || 'post' !== $ecran->post_type ) {
return $traduction;
}
if ( ! current_user_can( 'publish_posts' ) ) {
return 'Soumettre à validation';
}
return $traduction;
}, 10, 3 );
Comparer sur le texte source anglais 'Publish' plutôt que sur sa traduction française reste la bonne pratique pour un filtre gettext : ce filtre agit avant la traduction finale, la chaîne source ne varie donc jamais selon la langue active du site, contrairement à sa version traduite.
Un piège fréquent : ce filtre touche plusieurs endroits
Le mot « Publish » apparaît à plusieurs endroits de l’interface d’administration (le bouton principal, mais aussi certains libellés de statut secondaires). C’est pour cette raison que la vérification de l’écran courant (get_current_screen()) et du type de post est indispensable avant de remplacer quoi que ce soit : sans elle, le libellé pourrait changer dans un contexte où ce n’était pas prévu, par exemple dans un tableau de bord tiers qui réutilise la même chaîne.
Traiter aussi le message de confirmation
Une fois le bouton renommé, le message de confirmation qui apparaît après le clic (« Article publié. Voir l’article ») reste par défaut trompeur pour un contenu qui n’est en réalité qu’en attente. Le filtre post_updated_messages permet d’adapter ce message selon le statut réel du contenu après l’enregistrement :
add_filter( 'post_updated_messages', function ( $messages ) {
global $post;
if ( 'pending' === get_post_status( $post ) && ! current_user_can( 'publish_posts' ) ) {
$messages['post'][6] = 'Votre compte rendu a été soumis à validation. Un responsable le relira avant publication.';
}
return $messages;
} );
L’indice 6 du tableau $messages['post'] correspond précisément au message affiché après publication d’un article ; le remplacer conditionnellement, plutôt que de façon générale, préserve le message d’origine pour les rôles autorisés à publier directement.
Et côté ancien éditeur ou formulaires personnalisés ?
Si le site utilise encore, pour un type de contenu spécifique, un formulaire de soumission côté public (via wp_insert_post() appelé depuis un formulaire frontal), le même principe s’applique directement dans le code du formulaire : le bouton doit afficher un libellé cohérent avec le statut réellement attribué au contenu soumis, sans passer par gettext puisqu’il s’agit alors d’un texte que vous écrivez vous-même dans le template.
Pourquoi ne pas simplement masquer le bouton
Une tentation existe de masquer purement le bouton de publication pour les rôles non autorisés. Ce serait une erreur : le contributeur doit pouvoir soumettre son travail pour relecture, l’action reste nécessaire, seul le libellé doit refléter honnêtement ce qui va se passer réellement. Masquer l’action reviendrait à empêcher la soumission elle-même, ce qui n’est pas le problème à résoudre ici.
- Vérifiez toujours le type de post concerné avant de remplacer une chaîne aussi générique que « Publish ».
- Testez le rendu avec chaque rôle concerné (contributeur, auteur, éditeur) pour confirmer que seuls les bons profils voient le libellé modifié.
- Documentez ce filtre dans le thème : un futur développeur qui cherche pourquoi le bouton affiche un texte inhabituel doit pouvoir le retrouver rapidement.
Sur les sites à plusieurs niveaux de contribution, je considère qu’un libellé de bouton mal aligné avec le comportement réel du système est une source de tickets de support presque garantie. Corriger ce genre de détail coûte peu et évite des échanges répétés avec des contributeurs légitimement perdus.
Notre verdict
Ce correctif tient en quelques lignes, mais son effet sur la clarté perçue de l’interface est disproportionné par rapport à sa complexité de mise en œuvre. Un bouton qui dit ce qu’il fait réellement, adapté au rôle de la personne qui clique, évite des confusions récurrentes sans nécessiter la moindre extension supplémentaire.
