# Masquer certains champs Advanced Custom Fields selon le rôle de l’éditeur

> Adapter l'affichage d'un groupe de champs personnalisés selon les capacités de l'utilisateur connecté à l'administration, sans extension additionnelle.

- Auteur : WordPress Développement
- Publié le : 2022-06-20
- Mis à jour le : 2022-06-20
- Catégorie : Astuces
- URL : https://www.wpmoderne.fr/tips/masquer-champs-acf-selon-role-editeur/

## L’essentiel

- Filtrage réalisé via les hooks natifs d'ACF
- Basé sur les capacités WordPress plutôt que sur le nom du rôle
- Aucune extension supplémentaire nécessaire

Un champ ACF n'a pas de notion de « rôle autorisé » native au-delà du réglage grossier proposé dans l'interface de configuration du groupe de champs, limité à quelques conditions simples. Pour un site éditorial où les rédacteurs ne devaient voir ni modifier un champ « note interne SEO » réservé aux administrateurs, cette limite s'est révélée insuffisante : le réglage natif d'ACF ne permettait pas de cibler une capacité personnalisée, seulement un rôle nommé, ce qui posait problème dès qu'un utilisateur cumulait plusieurs rôles ou capacités.

La solution est passée par le filtre `acf/prepare_field`, qui s'exécute juste avant l'affichage de chaque champ dans l'éditeur, et permet de le masquer complètement ou de le rendre en lecture seule selon une logique de capacités, plus robuste qu'une simple comparaison de nom de rôle.

## Pourquoi éviter de comparer le nom du rôle

Comparer directement `current_user_can( 'administrator' )` ou tester le rôle via `wp_get_current_user()->roles` fonctionne, mais lie la logique d'affichage à un nom de rôle précis. Si l'équipe crée plus tard un rôle « rédacteur senior » qui doit aussi voir ce champ, il faut alors modifier le code à chaque nouvel intitulé de rôle. Passer par une capacité personnalisée, assignée aux rôles concernés, découple la logique d'affichage de la liste des rôles existants.

- Une capacité `voir_notes_seo`, ajoutée aux rôles administrateur et rédacteur senior
- Le champ ACF vérifie cette capacité, jamais le nom du rôle directement
- Ajouter la capacité à un nouveau rôle ne nécessite aucune modification du code du champ

## Masquer le champ avec acf/prepare_field

> L'essentiel à retenir : Filtrage réalisé via les hooks natifs d'ACF ; Basé sur les capacités WordPress plutôt que sur le nom du rôle ; Aucune extension supplémentaire nécessaire

```
add_filter( 'acf/prepare_field/name=note_interne_seo', function( $field ) {
    if ( ! current_user_can( 'voir_notes_seo' ) ) {
        return false;
    }

    return $field;
} );
```

Retourner `false` depuis ce filtre retire complètement le champ de l'éditeur pour les utilisateurs qui n'ont pas la capacité requise — il n'apparaît même pas en lecture seule, il disparaît purement et simplement de l'interface. C'est le comportement voulu ici : les rédacteurs n'ont pas besoin de savoir que ce champ existe.

## Variante : lecture seule plutôt que masqué

Pour d'autres champs, masquer complètement n'est pas souhaitable — un rédacteur doit voir la valeur d'un champ « statut de validation juridique » sans pouvoir la modifier lui-même. La même fonction de filtre peut alors désactiver le champ plutôt que le retirer :

```
add_filter( 'acf/prepare_field/name=statut_validation_juridique', function( $field ) {
    if ( ! current_user_can( 'modifier_statut_juridique' ) ) {
        $field['readonly'] = 1;
        $field['instructions'] = 'Champ modifiable uniquement par le service juridique.';
    }

    return $field;
} );
```

## Le cas des groupes de champs entiers

Quand c'est un groupe complet de champs qui doit être masqué plutôt qu'un champ isolé, le filtre équivalent au niveau du groupe est `acf/prepare_field_group`, appliqué de la même façon sur la capacité de l'utilisateur connecté plutôt que sur son rôle nommé. Le principe reste identique, seule la granularité change.

## Ce que cette approche ne fait pas

Ce filtrage agit uniquement sur l'affichage dans l'éditeur d'administration. Il ne protège pas la donnée elle-même contre une modification directe via l'API REST ou une requête `update_field()` exécutée par un autre code du site : un contrôle de capacité doit être ajouté séparément à tout point d'entrée qui permettrait de modifier ce champ en dehors de l'éditeur visuel.

## Tester le rendu pour chaque rôle concerné

Avant de considérer ce filtrage comme terminé, un test simple mais souvent négligé : se connecter successivement avec un compte de test pour chaque rôle concerné (rédacteur, rédacteur senior, administrateur) et vérifier concrètement ce qui s'affiche dans l'éditeur. Une capacité mal orthographiée dans le code du filtre, ou oubliée sur un rôle, ne se voit pas à la lecture du code — seul un test avec le bon compte le révèle vraiment.

## En résumé

Le filtre `acf/prepare_field`, combiné à une capacité personnalisée plutôt qu'à un nom de rôle, permet d'adapter finement l'affichage des champs ACF sans dépendre d'une extension supplémentaire ni figer la logique sur l'organisation des rôles du moment.