Contrats de types de bloc

Cette référence décrit les blocs publiés, champs modifiables, traductions, règles des enfants et rendu public. L’administration affiche le contrat en lecture seule ; elle ne définit ni schéma personnalisé ni nouveau formulaire.

Le système de plugins des plugins ajoute des hooks de bloc de plugin purement déclaratifs via PluginBlockTypeDefinition, PluginBlockPackDefinition et PluginBlockRegistry. Les plugins activés peuvent exposer des handles appartenant au plugin, tels que analytics-tools::score-card, à des fins de découverte, mais ces déclarations ne remplacent pas les contrats de bloc core livrés, les vues de bloc core, les seeders core ni les services d'édition de blocs. Les handles non qualifiés de style core, tels que hero, restent la propriété du core et sont rejetés pour les déclarations de plugins.

A Le contrat de type de bloc est l'accord technique actuel sur le comportement d'un type de bloc sur les couches CMS :

• identité du catalogue : slug, étiquette, catégorie, statut et métadonnées du système ou du conteneur
• source du formulaire d'administration : quel Blade partiel modifie actuellement le bloc et quels champs il expose
• validation et traitement des demandes : commentWebBlocks\Cms\Http\Requests\Admin\BlockRequestnormalise et valide actuellement les charges utiles de bloc
• propriété du stockage : sur quelles valeurs perdurentblocks, des lignes de traduction dédiées,block_media, ou des enregistrements associés
• propriété de la traduction : quels champs destinés à l'utilisateur appartiennent aux paramètres régionaux
• propriété partagée : quels paramètres ou relations restent partagés entre les paramètres régionaux
• propriété des médias ou des relations : directemedia_id, commandéblock_media, recherches de navigation ou relations sur la même page
• pension alimentaire pour enfants : si le bloc est un conteneur et si les types d'enfants sont restreints
• source de rendu public : quel public Blade partiel restitue le bloc aujourd'hui
• contrat racine du moteur de rendu : si le bloc possède son balisage racine public ou s'appuie sur le chemin du wrapper générique
• portabilité et révisions : si la forme de stockage actuelle doit continuer à voyager à travers les révisions, le clonage, l'exportation/importation et la promotion
• tests et lacunes : couverture ciblée connue, comportement peu clair ou dette de compatibilité

Termes de statut utilisés ci-dessous :

• clear : le formulaire d'administration, le traitement des requêtes, le stockage et le moteur de rendu concordent pour l'essentiel
• mostly clear : le contrat actuel est compréhensible mais comporte une réserve notable
• transitional : le contrat actuel conserve intentionnellement un chemin de compatibilité ou un modèle de propriété mixte
• needs review: confirmez le contrat installé avant de vous appuyer sur le comportement
• legacy/fallback : le comportement publié dépend d'un chemin de repli ou de compatibilité

Les travaux contractuels actuels et futurs devraient maintenir ces règles de propriété explicites :

• la copie destinée à l'utilisateur appartient aux lignes de traduction lorsque le bloc appartient aux paramètres régionaux
• les données opérationnelles ou de paramètres partagées appartiennent aux paramètres de bloc partagés ou aux relations explicites
• les médias doivent utiliser media_id ou block_media chemins de propriété le cas échéant
• éviter de déplacer le contenu destiné aux utilisateurs vers des paramètres partagés arbitraires
• conserver les chemins de stockage de compatibilité documentés lorsqu'ils affectent encore la sortie publique ou les importations

À partir du CMS 1.98.6, le champ modèle settings/API compatible est soutenu par des enregistrements relationnels. Les champs principaux connus utilisent des colonnes d'apparence, de média, de navigation et de contenu typées finies. Les liaisons de contenu, la configuration de collection et les valeurs d'instance d'application ont des enregistrements distincts ; les nœuds typés conservent la structure, l’ordre et les extensions historiques/plugin. Le CMS 1.98.8 a supprimé les copies de restauration temporaires de JSON ; SQL fait autorité. L'éditeur, la propriété de la traduction, les charges utiles API et les méthodes de rendu conservent leurs contrats existants ; la migration du stockage ne déplace pas la copie appartenant aux paramètres régionaux vers les paramètres partagés.

CMS 1.105.9 ajoute la découverte authoring_settings_schema révisée pour les 55 blocs principaux publiés. Lisez les indicateurs de création, PATCH et d'écriture d'administrateur distincts avant de fournir un champ. Les valeurs nouvelles ou modifiées doivent satisfaire aux types, énumérations et limites déclarés ; les champs non pris en charge renvoient des erreurs de validation au lieu d'être acceptés ou effacés silencieusement. Cela reste un contrat appartenant au code, et non un schéma modifiable ou un générateur de formulaire généré.

Les valeurs historiques inchangées survivent aux modifications sans rapport et au clonage, transfert et révisions fiables. Les nouveaux blocs et les remplacements complets doivent passer la validation en cours. Les plugins sans schéma conservent leur comportement existant ; Les schémas scalaires de plugin facultatifs ne remplacent pas les validateurs de média, d'application ou Dynamic Content. HTML reste réservé aux humains.

Voir Schémas des paramètres d’édition par bloc pour les métadonnées des opérations, les règles de compatibilité et la commande de compatibilité en lecture seule webblocks:blocks:audit-settings. L’audit de catalogue distinct ci-dessous vérifie les formulaires et moteurs de rendu livrés, et non les paramètres enregistrés.

La référence utilise le catalogue, les formulaires et les renderers livrés.

• source du catalogue : src/Support/Blocks/CoreBlockTypeCatalogSyncer.php
• normalisation des demandes de modification de bloc : src/Http/Requests/Admin/BlockRequest.php
• assistants de persistance : src/Support/Blocks/BlockPayloadWriter.php, src/Support/Blocks/BlockTranslationWriter.php, src/Support/Blocks/BlockTranslationResolver.php
• registre de traduction : src/Support/Blocks/BlockTranslationRegistry.php
• formulaires d'administration : resources/views/admin/blocks/types/*.blade.php
• rendeurs publics : resources/views/pages/partials/blocks/*.blade.php
• références de couverture : catalogue de blocs, rendu, traduction et tests spécifiques aux slugs sous tests/Feature/

Types de blocs de base publiés actuellement documentés ici : 55.

Réconciliation du catalogue : WebBlocks CMS 1.105.8. Le tableau couvre les 55 définitions de base publiées ; sept définitions supplémentaires restent inédites. Les notes des phases ultérieures ci-dessous sont des documents historiques, et non un deuxième décompte actuel du catalogue.

Les opérateurs et développeurs peuvent lancer ce contrôle du catalogue en lecture seule :

La commande est en lecture seule.

• elle ne modifie pas la base de données
• elle ne dépend pas du contenu du site installé
• elle lit les définitions du catalogue core livré
• elle vérifie la présence des fichiers de formulaire d'administration et de moteur de rendu public livrés
• elle rend compte des métadonnées de famille de traduction et de la prise en charge de base des conteneurs

La commande est une aide à l'actualisation permettant de repérer les écarts de catalogue et de présence de fichiers. Elle ne remplace pas les notes de contrat plus complètes de ce document.

Ouvrez les détails en lecture seule dans Admin -> System -> Block Types.

• chaque ligne peut ouvrir une fenêtre modale Block Type Contract
• la fenêtre modale est purement informative et ne soumet aucune mise à jour
• elle affiche les détails de catalogue, de formulaire d'administration, de stockage, de traduction, de médias ou de relations, d'enfants, de moteur de rendu et d'écarts à partir du code livré
• elle ne transforme pas l'administration Block Types en éditeur de schémas ou en générateur de formulaires
• les types de bloc personnalisés ou en brouillon peuvent également ouvrir la fenêtre modale, mais peuvent afficher No shipped contract is documented for this block type yet. lorsqu'aucun contrat core n'est défini

Les types de blocs publiés n'ont pas chacun leur propre classe de requête dédiée aujourd'hui.

• WebBlocks\Cms\Http\Requests\Admin\BlockRequest est le chemin de demande de modification partagé
• branches spécifiques au slug à l'intérieur de cette demande de normalisation des champs dans le stockage canonique actuel
• WebBlocks\Cms\Support\Blocks\BlockPayloadWriter conserve le format normalisé charge utile de bloc
• WebBlocks\Cms\Support\Blocks\BlockTranslationWriter déplace les champs appartenant aux paramètres régionaux dans des lignes de traduction pour les familles enregistrées
• WebBlocks\Cms\Support\Blocks\BlockTranslationResolver résout les valeurs traduites ou de secours sur une instance de bloc pouvant être rendue

Les paramètres hérités Gallery et Table peuvent rester lisibles en l’absence de traductions canoniques ou de médias ordonnés. Les anciens recours ne sont pas le format de création privilégié. Utilisez la matrice actuelle.

Les lignes de brouillon et identifiants de compatibilité réservés au renderer ne sont pas des contrats publiés. La découverte et le dialogue peuvent indiquer qu’aucun contrat livré n’est disponible.