Se connecter

Configurer les contrats du site et les plans de page

Composer stocke sa politique d'exécution sous la forme d'un Config Set versionné. La hiérarchie visible est la suivante :

Config Set -> Site Contract -> Blueprints

Construisez la configuration du cadre le plus large vers le plus spécifique. Conservez le Config Set actif comme immuable ; clonez-le lorsque vous devez modifier le comportement de production.

1. Créer un Config Set de travail​

Ouvrez WP Admin -> SmartCloud -> Agent Composer -> Config sets et créez un nouvel ensemble ou clonez-en un existant.

  • Utilisez Universal Gutenberg pour un contrat de page minimal, neutre vis-à-vis du thème, construit à partir de blocs principaux stables.
  • Utilisez SmartCloud Recommended pour une page portable plus riche avec héros, fonctionnalités, étapes, FAQ facultative et action de clôture.
  • Utilisez Detected Theme Starter pour générer un starter local sûr à partir d'un modèle enregistré adapté dans le thème actif. Composer enregistre le modèle source ainsi que les empreintes actuelles du thème et des capacités.
  • Utilisez New pour une configuration propre.
  • Utilisez Clone lorsque la configuration active constitue une base utile.
  • Utilisez Import uniquement pour un package Composer protégé par somme de contrôle et en lequel vous avez confiance.

Les ensembles fondés sur un préréglage, les ensembles nouveaux, clonés et importés sont inactifs. Un préréglage est copié dans un Config Set de travail doté d'un identifiant unique ; il n'écrase jamais la configuration et ne l'active jamais. Donnez à chaque ensemble un libellé stable et descriptif qui explique son objectif plutôt que son mot de passe d'environnement, le nom du client ou un ticket interne.

2. Définir le Site Contract​

Le Site Contract est la politique partagée par chaque Blueprint du Config Set. Utilisez-le pour les contraintes qui ne doivent pas dériver d'un type de page à l'autre, par exemple :

  • les types de publication WordPress autorisés ;
  • la langue éditoriale et opérateur ;
  • les indications de typographie et de système visuel ;
  • les règles de placement des médias et des légendes ;
  • les attentes communes en matière de gabarit ;
  • les contraintes de conception comme un style limité aux préréglages du thème ;
  • les déclarations de sécurité et les politiques indépendantes du fournisseur.

Le contrat n'est pas du code de thème exécutable. N'y placez pas d'identifiants, de clés API, d'appels distants, de JavaScript, de PHP ni de secrets de fournisseur. La validation des packages portables rejette les champs à forme secrète.

3. Ajouter un Blueprint pour chaque type de page​

Un Blueprint transforme un type de page sémantique en cible WordPress applicable. Créez un Blueprint distinct pour chaque forme de contenu matériellement différente, comme une page standard, un article, une solution, un document d'architecture ou une page produit.

Configurez ces champs avec soin :

  • Page type : identifiant machine stable utilisé par les opérations MCP.
  • Target post type : la page, l'article ou le type de publication personnalisé approuvé que Composer peut créer.
  • Target template : un modèle enregistré par le thème actif. Préférez un modèle sans titre lorsque le modèle approuvé contient déjà le seul H1.
  • Allowed patterns : modèles que l'agent peut assembler pour ce type de page.
  • Required sequence : la séquence minimale ordonnée de modèles que tout brouillon valide doit contenir.
  • Allowed blocks : la liste d'autorisation complète des blocs, y compris les blocs imbriqués utilisés par chaque modèle approuvé.
  • Constraints : règles H1, nombre de mots, embed, shortcode, Custom HTML et préréglages du thème.
  • Excerpt policy : required, optional ou disabled pour ce type de page.
  • SEO contract : comportement requis pour l'extrait WordPress et la méta-description.
  • Content mode : utilisez document pour le contenu en blocs Gutenberg et fields pour les enregistrements structurés enregistrés.
  • Approved fields : sélectionnez uniquement les champs visibles via REST et enregistrés pour le type de publication cible, puis déclarez leur politique de lecture/écriture.
  • Relation fields : déclarez la cardinalité, l'ordre, les types et statuts de publication cibles autorisés, ainsi que le nombre maximal d'éléments.
  • Taxonomy access : autorisez la recherche, l'affectation ou la création confirmée uniquement pour les taxonomies découvertes rattachées au type de publication cible de ce Blueprint.

Utilisez le sélecteur de blocs enregistrés au lieu de saisir les noms de blocs de mémoire. Un bloc ou un modèle fourni par un autre plugin n'est valide que tant que ce fournisseur est installé, actif et enregistré sur ce site.

Pour un champ de relation, le plugin du site ou du fournisseur enregistre le type de publication sous-jacent, le champ de méta et le contrat de relation. Composer gère le chemin d'exécution générique : smartcloud-agent-composer/get-content-field-contract annonce le flux de travail, smartcloud-agent-composer/search-relation-targets résout les titres ou slugs vers matches[].id, smartcloud-agent-composer/update-content-fields écrit ces identifiants dans un brouillon détenu par Composer, et smartcloud-agent-composer/inspect-content-fields vérifie la valeur stockée. smartcloud-agent-composer/list-content-drafts liste le contenu modifiable ou adoptable et ne doit pas être utilisé pour résoudre des cibles de relation.

Gouverner séparément les termes de taxonomie​

Le plugin responsable ou le cœur de WordPress enregistre toujours chaque taxonomie et l'attache au type de publication cible. Sous Composer taxonomy access, le Site Contract peut autoriser séparément la recherche, l'affectation au brouillon et la création confirmée de termes pour chaque taxonomie découverte. Il fixe également un nombre maximal d'éléments et impose le comportement d'affectation à append ou replace. La création hiérarchique est par défaut limitée à la racine ; une liste d'autorisation facultative utilise des slugs de parent durables plutôt que des identifiants locaux au site.

La séquence gouvernée de l'agent est get-taxonomy-contract -> search-taxonomy-terms -> réutiliser matches[].term_id exact lorsqu'il est disponible -> create-taxonomy-term uniquement pour un terme public manquant justifié et avec confirmation explicite -> assign-taxonomy-terms -> inspect-taxonomy-terms. Les nouveaux termes exigent un nom naturel, un slug durable, une description d'archive autonome et la langue du contenu du Blueprint. Composer n'expose ni l'édition ni la suppression des termes, et chaque affectation reste limitée à un brouillon détenu par Composer avec des jetons de concurrence à jour.

4. Rescanner le site actif​

Ouvrez Theme & providers et choisissez Rescan site après l'installation, l'activation ou la mise à jour d'un thème ou d'un plugin fournisseur.

Vérifiez :

  • l'identité et la version du thème actif ;
  • les modèles et patterns enregistrés ;
  • tous les blocs Gutenberg enregistrés ;
  • les patterns référencés par le Config Set sélectionné ;
  • les métadonnées facultatives du fournisseur et l'état d'exécution ;
  • toute dépendance de contrat manquante.

La découverte signale les capacités ; elle ne réécrit pas la configuration. Si le thème a changé, clonez l'ensemble actif et ajustez la copie de travail.

5. Préparer et appliquer les changements​

Les modifications d'entité sont préparées dans le navigateur. L'enregistrement d'une fenêtre modale d'entité ne crée pas immédiatement une nouvelle révision de base de données. La barre d'actions affiche les ajouts en attente, les modifications et les suppressions confirmées pour le Config Set sélectionné.

  • Apply modifications écrit l'ensemble complet des changements préparés comme une transaction unique protégée par contrôle de concurrence optimiste.
  • Discard supprime les changements préparés sans écrire dans WordPress.

L'application d'un ensemble de changements recalcule le hachage et l'horodatage de modification du Config Set. Si un autre administrateur a modifié la même entité, Composer renvoie un conflit au lieu d'écraser l'une ou l'autre version.

6. Valider et activer​

Choisissez Validate après tout changement significatif de contrat, de thème, de pattern, de bloc, de modèle ou de fournisseur. Résolvez les erreurs avant l'activation ; examinez les avertissements dans leur contexte.

L'activation nécessite un reçu de validation récent lié à :

  • la somme de contrôle exacte du Config Set ;
  • le site WordPress actuel ;
  • l'administrateur actuel ;
  • une fenêtre de validité limitée.

Choisissez Activate uniquement après avoir examiné l'ensemble de travail complet. L'ensemble actif précédent devient archivé et reste disponible pour la comparaison et la restauration confirmée.

Comparer, restaurer, exporter et sauvegarder​

  • Compare to active montre en quoi l'ensemble sélectionné diffère de la configuration d'exécution.
  • Restore archived as active valide de nouveau l'ensemble archivé et nécessite une confirmation explicite ; cette action n'annule pas une modification non enregistrée dans le navigateur.
  • Export crée un package de Config Set protégé par somme de contrôle.
  • Audit & portability -> Export all configuration crée une sauvegarde complète de chaque Config Set.

Les exports portables excluent volontairement les identifiants et la chaîne d'audit spécifique au site. Les ensembles restaurés restent inactifs jusqu'à ce qu'ils soient validés puis explicitement activés.

Exemple de transfert d'agence : un workflow de cas client existant​

Supposons qu'une agence ait déjà conçu un type de publication personnalisé case_study, ses modèles d'interface publique et le traitement visuel approuvé. Le thème reste responsable de la présentation ; Composer n'introduit pas de mise en page universelle WP Suite pour les cas clients.

L'agence peut créer un Config Set qui n'expose que le workflow pertinent et ajouter un Blueprint case_study exigeant :

  • un titre et un contexte client ;
  • des sections problème, mise en œuvre et résultat ;
  • un seul appel à l'action approuvé ;
  • les métadonnées d'image existantes de la médiathèque ;
  • les catégories, mots-clés et métadonnées SEO autorisés ;
  • le modèle de thème, les patterns, les blocs et la séquence déjà utilisés par le site.

Lorsque le client demande à son agent compatible un nouveau cas client, l'agent charge ce Blueprint et le contexte de conception actif, prépare le contenu, valide la structure complète et crée un brouillon. Un humain vérifie les faits, les médias et la présentation avant approbation. La publication via WordPress ou une publication facultative de Static Publisher reste une action séparée.

Ce transfert transforme les décisions existantes de l'agence en une opération de contenu reproductible. Il ne demande ni à Composer ni à l'agent du client de redessiner le site.

Avant de connecter un agent​

Confirmez que :

  1. un seul Config Set est actif ;
  2. chaque type de page demandé possède un Blueprint valide ;
  3. tous les patterns, modèles et blocs requis existent ;
  4. les fournisseurs facultatifs signalent qu'ils sont prêts ou sont absents du Blueprint ;
  5. l'utilisateur dédié à l'agent possède le rôle smartcloud_agent ;
  6. l'état MCP dans Composer signale le point de terminaison attendu.