Contratos de tipos de bloque

Esta referencia describe bloques publicados, campos editables, traducciones, reglas de hijos y renderizado público. La administración muestra el contrato en modo solo lectura; no define esquemas personalizados ni crea formularios nuevos.

El sistema de plugins de plugins añade hooks de bloque de plugin solo declarativos mediante PluginBlockTypeDefinition, PluginBlockPackDefinition y PluginBlockRegistry. Los plugins habilitados pueden exponer handles propios del plugin, como analytics-tools::score-card, para su descubrimiento, pero estas declaraciones no sustituyen a los contratos de bloque core distribuidos, las vistas de bloque core, los seeders core ni los servicios de edición de bloques. Los handles sin cualificar de estilo core, como hero, siguen perteneciendo al core y se rechazan en las declaraciones de plugins.

A El contrato de tipo de bloque es el acuerdo técnico actual sobre cómo se comporta un tipo de bloque en las capas de CMS:

• identidad del catálogo: slug, etiqueta, categoría, estado y metadatos del sistema o contenedor
• fuente del formulario de administrador: qué parcial de Blade edita actualmente el bloque y qué campos expone
• validación y solicitud manejo: cómo WebBlocks\Cms\Http\Requests\Admin\BlockRequest normaliza y valida actualmente las cargas útiles de bloque
• propiedad de almacenamiento: qué valores se encuentran en blocks, filas de traducción dedicadas, block_media o registros relacionados
• propiedad de traducción: qué campos de cara al usuario son locale-owned
• propiedad compartida: qué configuraciones o relaciones permanecen compartidas entre locales
• propiedad de medios o relaciones: media_id directo, block_media ordenado, búsquedas de navegación o relaciones en la misma página
• soporte infantil: si el bloque es un contenedor y si los tipos secundarios están restringidos
• fuente de renderizador público: qué Blade público parcial representa el bloque hoy
• contrato raíz del renderizador: si el bloque posee su marcado raíz público o depende de la ruta contenedora genérica
• portabilidad y revisiones: si la forma de almacenamiento actual debe continuar viajando a través de revisiones, clonación, exportación/importación y promoción
• Pruebas y brechas: cobertura enfocada conocida, comportamiento poco claro o deuda de compatibilidad

Términos de estado utilizados a continuación:

• clear: el formulario de administración, la gestión de peticiones, el almacenamiento y el renderizador coinciden en gran medida
• mostly clear: el contrato actual se entiende, pero tiene una salvedad destacable
• transitional: el contrato actual mantiene de forma intencionada una ruta de compatibilidad o un patrón de propiedad mixto
• needs review: confirme el contrato instalado antes de depender del comportamiento
• legacy/fallback: el comportamiento publicado depende de una ruta alternativa o de compatibilidad

El contrato de trabajo actual y futuro debe mantener explícitas estas reglas de propiedad:

• La copia orientada al usuario pertenece a las filas de traducción cuando el bloque es de propiedad local
• Los datos operativos o de configuración compartidos pertenecen a la configuración del bloque compartido o relaciones explícitas
• Los medios deben usar media_id o block_media rutas de propiedad cuando corresponda
• evite mover contenido de cara al usuario a configuraciones compartidas arbitrarias
• mantenga las rutas de almacenamiento de compatibilidad documentadas cuando aún afecten la salida pública o las importaciones

Desde CMS 1.98.6, el campo modelo settings/API compatible está respaldado por registros relacionales. Los campos principales conocidos utilizan columnas de apariencia, medios, navegación y contenido de tipo finito. Los enlaces de contenido, la configuración de la colección y los valores de la instancia de la aplicación tienen registros separados; Los nodos escritos conservan la estructura, el orden y las extensiones históricas/de complementos. CMS 1.98.8 eliminó las copias de reversión temporales de JSON; SQL tiene autoridad. El editor, la propiedad de la traducción, las cargas útiles API y los métodos de renderizado mantienen sus contratos existentes; La migración de almacenamiento no mueve la copia de propiedad local a la configuración compartida.

CMS 1.105.9 agrega el descubrimiento authoring_settings_schema revisado para los 55 bloques principales publicados. Lea los indicadores de creación, PATCH y escritura del administrador por separado antes de proporcionar un campo. Los valores nuevos o modificados deben satisfacer los tipos, enumeraciones y límites declarados; Los campos no admitidos devuelven errores de validación en lugar de aceptarse o borrarse silenciosamente. Este sigue siendo un contrato de propiedad del código, no un esquema editable ni un generador de formularios generado.

U Los valores históricos sin cambios sobreviven a ediciones no relacionadas y clonaciones, puestas en escena y revisiones confiables. Los bloques nuevos y los reemplazos completos deben pasar la validación actual. Los complementos sin esquema conservan su comportamiento existente; Los esquemas escalares del complemento opcional no reemplazan los validadores de medios, aplicaciones o Dynamic Content. HTML sigue siendo solo para humanos.

Consulte Esquemas de ajustes de edición por bloque para conocer los metadatos de operación, las reglas de compatibilidad y el comando de compatibilidad de solo lectura webblocks:blocks:audit-settings. La auditoría de catálogo que aparece a continuación comprueba los formularios y renderizadores distribuidos, no los ajustes almacenados.

La referencia utiliza el catálogo, formularios y renderizadores distribuidos.

• fuente del catálogo: src/Support/Blocks/CoreBlockTypeCatalogSyncer.php
• normalización de solicitud de edición de bloque: src/Http/Requests/Admin/BlockRequest.php
• ayudantes de persistencia: src/Support/Blocks/BlockPayloadWriter.php, src/Support/Blocks/BlockTranslationWriter.php, src/Support/Blocks/BlockTranslationResolver.php
• registro de traducción: src/Support/Blocks/BlockTranslationRegistry.php
• formularios de administrador: resources/views/admin/blocks/types/*.blade.php
• representantes públicos: resources/views/pages/partials/blocks/*.blade.php
• referencias de cobertura: catálogo de bloques, renderizado, traducción y pruebas específicas de slug bajo tests/Feature/

Tipos de bloques principales publicados actualmente documentados aquí: 55.

Conciliación de catálogo: WebBlocks CMS 1.105.8. La tabla cubre las 55 definiciones principales publicadas; siete definiciones adicionales permanecen inéditas. Las notas de la fase posterior a continuación son registros históricos, no un segundo recuento del catálogo actual.

Operadores y desarrolladores pueden ejecutar esta comprobación de solo lectura:

El comando es de solo lectura.

• no modifica la base de datos
• no depende del contenido del sitio instalado
• lee las definiciones del catálogo core distribuido
• verifica la presencia de los archivos del formulario de administración y del renderizador público distribuidos
• informa de los metadatos de la familia de traducción y del soporte básico de contenedores

El comando es una ayuda de actualidad para detectar desviaciones del catálogo y de la presencia de archivos. No sustituye a las notas de contrato más completas de este documento.

Abra los detalles en modo solo lectura en Admin -> System -> Block Types.

• cada fila puede abrir un modal Block Type Contract
• el modal es solo informativo y no envía actualizaciones
• muestra los detalles de catálogo, formulario de administración, almacenamiento, traducción, medios o relaciones, hijos, renderizador y carencias a partir del código distribuido
• no convierte la administración de Block Types en un editor de esquemas ni en un constructor de formularios
• los tipos de bloque personalizados o en borrador también pueden abrir el modal, pero pueden mostrar No shipped contract is documented for this block type yet. cuando no hay ningún contrato core definido

Los tipos de bloques publicados no tienen cada uno su propia clase de solicitud dedicada en la actualidad.

• WebBlocks\Cms\Http\Requests\Admin\BlockRequest es la ruta de solicitud de edición compartida
• Las ramas específicas de slug dentro de esa solicitud normalizan los campos en el almacenamiento canónico actual
• WebBlocks\Cms\Support\Blocks\BlockPayloadWriter persiste el carga útil de bloque normalizada
• WebBlocks\Cms\Support\Blocks\BlockTranslationWriter mueve campos de propiedad local a filas de traducción para familias registradas
• WebBlocks\Cms\Support\Blocks\BlockTranslationResolver resuelve valores traducidos o alternativos en una instancia de bloque renderizable

Los ajustes heredados de Gallery y Table pueden seguir siendo legibles cuando falten traducciones canónicas o medios ordenados. Los valores alternativos históricos no son el formato preferido de creación. Use la matriz actual.

Las filas de borrador y los identificadores de compatibilidad exclusivos del renderer no son contratos publicados. El descubrimiento y el diálogo pueden indicar que no existe contrato distribuido.