{ duree > 0 ? `${ duree } min de lecture` : __( 'Durée non renseignée', 'mon-extension' ) }
); } ``` Le hook retourne un tableau à trois éléments : la valeur courante de la propriété demandée, une fonction pour la modifier, et la valeur complète enregistrée. Ici, la propriété demandée est `meta`, c'est-à-dire l'objet qui regroupe toutes les métadonnées exposées à l'API REST pour cet article. L'écriture passe donc par un objet entier, d'où la copie avec l'opérateur de décomposition : sans elle, l'appel remplacerait l'ensemble des métadonnées éditées par une seule clé. Les paramètres sont, dans l'ordre, le type d'entité (`postType`), son nom (le type de contenu), la propriété, puis un identifiant facultatif. Lorsque l'identifiant est omis, le hook s'appuie sur l'entité du contexte courant de l'éditeur. Dans l'exemple, le type et l'identifiant viennent du contexte du bloc, ce qui suppose de les déclarer dans le fichier `block.json`. ## Déclarer le contexte dans block.json ``` { "apiVersion": 2, "name": "mon-extension/duree-lecture", "title": "Durée de lecture", "category": "widgets", "usesContext": [ "postType", "postId" ], "editorScript": "file:./index.js" } ``` La clé `usesContext` indique à l'éditeur quelles valeurs fournies par les blocs parents, ou par l'éditeur lui-même, doivent arriver dans la propriété `context` du composant. Un bloc placé dans un article, une page ou à l'intérieur d'une boucle de requête reçoit ainsi le bon type et le bon identifiant, sans aller les chercher dans le magasin de données. C'est aussi ce qui rend le bloc réutilisable dans un modèle du site, où le contexte change d'un affichage à l'autre. ## Ce qui se passe à l'enregistrement Modifier la valeur avec `setMeta` ne déclenche aucun appel réseau : le changement est tenu en mémoire, comme une modification du titre ou du contenu, et marque l'article comme modifié. L'envoi vers le serveur a lieu à la sauvegarde habituelle, avec le bouton « Mettre à jour » ou « Publier ». C'est une bonne nouvelle pour l'expérience de rédaction, car l'annulation et le rétablissement restent cohérents, mais c'est aussi un piège pour celui qui s'attend à une écriture immédiate en base. Côté affichage public, le bloc peut être dynamique : une fonction de rendu PHP lit la valeur avec `get_post_meta()` et produit le balisage, de sorte que le résultat ne dépende pas d'un contenu sérialisé dans l'article : ``` register_block_type( __DIR__ . '/build', array( 'render_callback' => function ( $attributs, $contenu, $bloc ) { $duree = (int) get_post_meta( $bloc->context['postId'], 'duree_lecture_minutes', true ); if ( $duree < 1 ) { return ''; } return sprintf( '%d min de lecture
', $duree ); }, ) ); ``` ## Un cas concret : la durée de lecture d'un magazine Une rédaction veut afficher une durée de lecture sur chaque article, avec la possibilité de la corriger à la main lorsque le calcul automatique se trompe. Le bloc ci-dessus suffit : la valeur calculée à l'enregistrement sert de valeur par défaut, le rédacteur ajuste le curseur dans l'inspecteur, et le modèle d'affichage des articles place le bloc sous le titre. La même métadonnée alimente ensuite un tri dans l'administration ou un filtre dans une boucle de requête, sans duplication de données. > Le meilleur état partagé est celui qu'on n'a pas à synchroniser : la donnée reste dans l'article, le bloc ne fait que la regarder et la corriger. ## Les pièges fréquents - Oublier `show_in_rest` : le champ n'apparaît jamais dans l'objet `meta`, et le hook renvoie `undefined` sans erreur visible. - Oublier que le type de contenu doit prendre en charge les champs personnalisés (`custom-fields`) pour que les métadonnées soient exposées à l'API REST. - Écrire une clé seule dans `setMeta` sans conserver les autres : les valeurs déjà modifiées dans la même session sont écrasées. - Utiliser une clé préfixée par un tiret bas sans déclarer de fonction `auth_callback` : les clés protégées refusent l'écriture par défaut. - Déclarer un type différent entre PHP et JavaScript : une chaîne envoyée pour un champ déclaré entier est rejetée à la sauvegarde. ## Quand ne pas utiliser ce hook Pour une donnée qui n'appartient pas à une entité WordPress, comme un réglage global de l'extension ou un compteur stocké dans une table personnalisée, `useEntityProp` ne convient pas. Il est conçu pour les entités que le magasin de données de l'éditeur connaît : articles, pages, utilisateurs, termes, réglages du site. Pour le reste, un appel `apiFetch` vers une route dédiée reste la bonne approche. De même, une valeur purement locale à un bloc, qui n'a pas à survivre hors de lui, relève des attributs du bloc, pas des métadonnées. ## Conclusion `useEntityProp` remplace un ensemble de mécanismes que l'on écrivait autrefois à la main : appel REST, état local, rapprochement avec l'enregistrement. À condition de déclarer correctement la métadonnée côté PHP, de transmettre le contexte du bloc et de ne jamais écraser l'objet complet, il offre un pont fiable entre l'inspecteur et les données de l'article.