# register_meta et show_in_rest : publier un champ personnalisé sans faille

> Alimenter un front headless suppose d'exposer certains champs personnalisés via l'API REST. Voici la configuration register_meta qui évite d'ouvrir plus que prévu.

- Auteur : WordPress Développement
- Publié le : 2020-03-27
- Mis à jour le : 2020-03-27
- Catégorie : Extensions
- URL : https://www.wpmoderne.fr/extensions/register-meta-show-in-rest-champ-personnalise-lecture/

## L’essentiel

- show_in_rest n'ouvre que la lecture par défaut aux capacités adéquates
- auth_callback contrôle qui peut écrire
- Un schema évite les valeurs mal typées

Trois lignes suffisent-elles vraiment à exposer un champ personnalisé sur un front découplé ? La réponse tient surtout dans le détail des arguments passés à `register_meta()`, une fonction souvent utilisée avec un seul paramètre `show_in_rest` mis à `true`, sans que le développeur mesure ce que cela ouvre exactement.

Pour un projet headless, où un front en JavaScript consomme l'API REST plutôt que les templates PHP classiques, chaque champ personnalisé exposé devient un point d'accès potentiellement lisible par n'importe qui, y compris un visiteur anonyme qui interroge directement l'URL de l'API sans passer par l'interface prévue.

## Un register_meta minimal mais complet

```
function wpm_enregistrer_meta_produit() {
    register_meta(
        'post',
        'reference_fournisseur',
        array(
            'object_subtype' => 'produit',
            'type'           => 'string',
            'description'    => 'Référence interne fournisseur',
            'single'         => true,
            'show_in_rest'   => true,
            'auth_callback'  => function() {
                return current_user_can( 'edit_products' );
            },
        )
    );
}
add_action( 'init', 'wpm_enregistrer_meta_produit' );
```

Le paramètre `object_subtype` restreint l'enregistrement au type de contenu `produit` plutôt qu'à tous les articles du site, ce qui évite qu'un champ pensé pour un catalogue apparaisse aussi sur les pages ou les articles de blog. C'est une nuance souvent oubliée : sans lui, `register_meta( 'post', ... )` s'applique à l'ensemble des types de contenus basés sur les articles.

## show_in_rest ouvre la lecture, pas forcément l'écriture

Passer `show_in_rest` à `true` rend la méta lisible par tout client qui consulte l'endpoint `/wp/v2/produit/{id}`, y compris sans authentification, dès lors que le contenu lui-même est publié. L'écriture, en revanche, reste conditionnée par `auth_callback` : sans lui, WordPress applique une vérification par défaut basée sur la capacité `edit_post`, ce qui peut suffire ou non selon la sensibilité du champ.

> L'essentiel à retenir : show_in_rest n'ouvre que la lecture par défaut aux capacités adéquates ; auth_callback contrôle qui peut écrire ; Un schema évite les valeurs mal typées

Sur un champ qui contient une information interne, comme une marge commerciale ou une référence fournisseur, il est préférable de définir une capacité personnalisée plutôt que de s'appuyer sur la capacité générique d'édition. Cela évite qu'un rôle capable d'éditer le produit sur le front en profite pour modifier un champ qui ne devrait relever que d'un rôle achat.

### Structurer la réponse avec un schema

Depuis les versions qui ont suivi l'introduction de `show_in_rest`, il est possible de fournir un tableau plutôt qu'un simple booléen, afin de définir un `schema` précis :

```
'show_in_rest' => array(
    'schema' => array(
        'type'        => 'string',
        'description' => 'Référence interne fournisseur',
        'pattern'     => '^[A-Z0-9-]{4,20}$',
    ),
),
```

Ce schema n'est pas décoratif : l'API REST l'utilise pour valider les valeurs entrantes lors d'une requête d'écriture, ce qui évite qu'une chaîne mal formée ou un type inattendu vienne polluer la base de données via l'API plutôt que via l'écran d'édition classique.

## Champs multiples et objets imbriqués

Pour un champ qui accepte plusieurs valeurs, il faut passer `single` à `false` et adapter le schema en conséquence :

- `single => false` pour un tableau de valeurs répétées
- `type => 'array'` côté schema, avec un sous-schema `items`
- Un `sanitize_callback` dédié si le nettoyage par défaut ne convient pas au format attendu

## Éviter l'exposition involontaire d'un champ sensible

Une pratique risquée consiste à copier un enregistrement existant pour un nouveau champ sans relire les valeurs par défaut. Omettre `show_in_rest` ne suffit pas toujours à protéger une donnée : certaines extensions listent les métadonnées disponibles par un autre canal, ou un développeur ajoute plus tard `show_in_rest => true` sur un groupe de champs sans vérifier chacun individuellement.

| Argument | Rôle | Risque si oublié |
| --- | --- | --- |
| object_subtype | Restreint au bon type de contenu | Champ visible sur tous les articles |
| auth_callback | Contrôle l'écriture | Écriture ouverte à trop de rôles |
| schema | Valide le format | Valeurs incohérentes en base |
| single | Structure la valeur | Confusion tableau / valeur unique |

> Sur un projet headless, chaque champ exposé à l'API doit être justifié par un besoin réel du front, pas ajouté « au cas où » : ce qui n'est pas exposé n'a pas besoin d'être protégé.

## Notre verdict

Un register_meta pensé pour un front découplé mérite le même niveau d'attention qu'un endpoint REST personnalisé : restreindre le type de contenu concerné, définir précisément qui peut écrire, et documenter la structure attendue via un schema. Ces quelques lignes supplémentaires évitent des heures de diagnostic le jour où un champ interne se retrouve exposé plus largement que prévu.