Se connecter

Gouverner les mises en page WordPress avec les Structure Contracts

Un Structure Contract transforme la mise en page Gutenberg prévue par un Blueprint en modèle de document imposé par le serveur. Un agent peut ainsi cibler hero.title ou body.additional sans recevoir un chemin de blocs fragile ni l’autorisation de reconstruire la page.

Les verrouillages de l’éditeur améliorent l’expérience, mais ne sont pas la frontière de sécurité. Composer vérifie à nouveau le contrat lors des écritures REST, de l’éditeur natif et MCP. Du balisage de blocs brut ne peut pas le contourner.

Modèle de propriété​

Chaque nœud déclaré possède un propriétaire :

  • La structure appartenant au Blueprint protège les conteneurs requis, l’ordre, le type de bloc et la présentation.
  • Le contenu appartenant à l’instance peut varier par publication et se modifie via un ID sémantique stable.
  • Le contenu de slot appartenant à l’utilisateur offre une liberté éditoriale contrôlée par une liste de blocs et une cardinalité minimale et maximale.

Cette séparation préserve le design sans figer chaque mot.

IDs sémantiques stables​

Un ID sémantique est une règle durable, pas un index de tableau. Utilisez des noms décrivant le rôle du contenu :

hero
hero.title
body
body.text
body.additional

Renommer un ID constitue une migration de contrat. N’y encodez ni version du thème, ni ID de base, ni environnement, ni position actuelle du bloc.

Slots d’extension​

Un slot déclare son ID sémantique et son parent, les types de blocs directs autorisés, le minimum et le maximum, son caractère obligatoire, ainsi que le verrouillage et le comportement de l’appender.

Composer expose insertion, mise à jour, déplacement et suppression sémantiques. Il attribue une identité stable appartenant à l’utilisateur à chaque arbre inséré et valide le document complet après chaque modification. Un échec de cardinalité ou d’allowlist est atomique : le brouillon n’est pas enregistré en partie.

Patterns structurels synchronisés​

Stockez la structure réutilisable dans un pattern WordPress wp_block synchronisé et publié. La publication conserve une référence native core/block verrouillée au lieu d’une copie de l’arbre.

Utilisez les Pattern Overrides natifs pour les champs d’instance. Composer stocke les enfants des slots sur l’instance du pattern de la publication, et non dans le wp_block partagé. Modifier une instance ne change donc pas toutes les pages.

Le Site Contract identifie chaque pattern gouverné, son enregistrement wp_block local, sa version, ses liaisons d’override et le Structure Contract compatible. Theme & providers n’indique une source manquante que si ce type de source est pertinent et réellement indisponible.

Création native WordPress​

Le Site Contract peut définir Add New pour chaque type de contenu :

  • off : la création native reste non gérée ;
  • optional : un administrateur peut choisir un Blueprint compatible ;
  • required : le document doit être initialisé depuis le Blueprint par défaut.

Le document natif reçoit le même Blueprint, les mêmes patterns synchronisés, Structure Contract, baseline, langue et protection d’écriture serveur. Il ne devient pas pour autant la propriété de l’agent.

Évolution et réconciliation des patterns​

Une révision compatible peut modifier la présentation protégée tout en conservant les champs sémantiques et slots requis. Pattern Overrides et enfants de slots utilisateur restent attachés à leur instance.

Si une révision supprime ou change une liaison obligatoire, Composer signale explicitement un état invalide ou nécessitant une réconciliation. Il ne réécrit pas silencieusement les contenus et n’en supprime aucun.

Pour un changement de contrat versionné :

  1. clonez le Config Set actif ;
  2. enregistrez le Structure Contract et le Blueprint successeurs ;
  3. définissez une migration source-cible exacte ;
  4. prévisualisez sans écrire ;
  5. classez les éléments automatiques et ceux à réviser ;
  6. créez des propositions liées à la révision ;
  7. faites fusionner les propositions acceptées par une personne.

La planification en lot est bornée et la création des propositions explicite. Une migration ne devient jamais une publication massive automatique.

Responsabilités du thème et des providers​

Le thème possède templates, patterns synchronisés, balisage, styles et tokens theme.json. Un provider possède le schéma et le materializer de ses composants. Composer possède contrat sémantique, validation, mutation gouvernée, état de réconciliation, propositions et piste d’audit.

Les sections Knowledge Base d’AI Kit peuvent servir de conteneurs sémantiques à des descendants Gutenberg ou Agent Canvas gouvernés. Feature et Doc Search conservent leur validation enfant plus stricte.

Liste d’acceptation​

  • Chaque ID sémantique est stable et unique.
  • Chaque champ ou slot requis est résolu une seule fois après expansion du pattern.
  • Chaque bloc autorisé est enregistré et validé.
  • Les limites des slots correspondent à la liberté éditoriale voulue.
  • Pattern Overrides couvre tous les champs d’instance.
  • Le contenu des slots d’instance ne modifie pas le wp_block partagé.
  • Add New, édition MCP, aperçu, proposition et réconciliation sont testés avec le thème actif.
  • Les changements publiés restent soumis à proposition et approbation humaine.

Continuez avec Configuration et cycle de vie, Intégration du thème et Accès MCP et OAuth.