Page Layouts

Los Page Layouts son definiciones a nivel de instalación que gestionan la elección del armazón público exterior y los envoltorios de slot gestionados de las páginas.

Alcance de la V1

Ruta de administración: Admin -> System -> Page Layouts
Acceso: solo super_admin
La V1 admite listar, crear, editar, activar, desactivar, ordenar, el CRUD de Page Layout Slots gestionados, la comparación de slots en Edit Page y la aplicación segura de los slots que faltan
La V1 no admite eliminar layouts del sistema
En esta versión, las páginas siguen guardando el handle del layout seleccionado en pages.settings.public_shell por compatibilidad con versiones anteriores
Los campos visibles del Page Layout son Name, Handle, Description, Status, Sort Order y Body Class
Shell Type, Slot Schema JSON y Wrapper Schema JSON son campos de compatibilidad obsoletos y ya no forman parte del formulario de administración
El Slot Schema JSON y el Wrapper Schema JSON en bruto ya no son el modelo de edición de la administración

Layouts integrados

default / Default Layout: armazón estándar de página pública
docs / Docs Layout: armazón de documentación con mapeo de regiones header, sidebar, main y footer

Estos layouts integrados siguen siendo compatibles con páginas, importaciones, exportaciones y renderizado público anteriores.

Cada layout integrado siembra además Page Layout Slots gestionados:

default: header, main, sidebar, footer
docs: header, sidebar, main, footer

Cómo funciona el renderizado

Una página guarda un handle de Page Layout en public_shell
En tiempo de ejecución, ese handle se resuelve a un Page Layout gestionado cuando existe
El Page Layout resuelto puede aportar un body_class validado al elemento <body> público
En tiempo de ejecución, los envoltorios de slot se resuelven desde page_layout_slots relacionales cuando están disponibles
Cada Page Layout Slot referencia una fila SlotType publicada del CMS y define metadatos del envoltorio como el elemento, el id, las clases y fragmentos de envoltorio de confianza
Si los Page Layout Slots relacionales no están disponibles, las definiciones de reserva integradas mantienen estable el renderizado de default y docs

En la V1, los layouts personalizados siguen reutilizando el comportamiento existente del armazón público default o docs. Por compatibilidad, el runtime deduce ese comportamiento de forma conservadora a partir de las definiciones de slot gestionadas.

Page Layout Slots gestionados

Los Page Layout Slots son los registros de región gestionados asociados a un Page Layout.

Ruta de administración: Admin -> System -> Page Layouts -> Edit -> Page Layout Slots
Los Slot Types son el catálogo para añadir Page Layout Slots
Cada Page Layout Slot guarda slot_type_id, slot_name, label, description, html_element, html_id, html_classes, before_html, start_html, end_html, after_html, is_required, is_active, is_system y sort_order
La edición en la administración agrupa estos campos en Slot Identity, Wrapper Markup, Advanced Trusted Layout HTML y Status / Ordering
La validación solo permite ids HTML seguros, clases seguras separadas por espacios y fragmentos de envoltorio de confianza, y rechaza scripts, atributos de evento, javascript:, iframe, object y embed
Los layouts del sistema mantienen estable su mapeo de slots del sistema: los Page Layout Slots del sistema no permiten cambiar el nombre de slot subyacente ni el Slot Type
Los Page Layout Slots que no son del sistema ni obligatorios se pueden eliminar
CSS Classes espera tokens de clase separados por espacios
Las clases del envoltorio pueden incluir pistas de layout como wb-sidebar, wb-dashboard-main o wb-stack cuando encajan con el layout seleccionado
El comportamiento fijo de la Navbar pública debe venir de la primitiva wb-navbar incluida, no de reglas sticky de cabecera a nivel de sitio
Cuando un slot de cabecera pública por defecto contiene solo un bloque Navbar, el CMS promueve el envoltorio del slot a la raíz nav.wb-navbar para que la Navbar quede fija sin CSS específico del sitio
Before Slot HTML se renderiza antes del envoltorio del slot
Slot Start HTML se renderiza dentro del envoltorio, antes de los bloques
Slot End HTML se renderiza dentro del envoltorio, después de los bloques
After Slot HTML se renderiza después del envoltorio del slot
El HTML de layout de confianza avanzado es solo para marcado de layout adyacente al envoltorio, no para scripts

Comparar y aplicar en Edit Page

Edit Page muestra ahora una tarjeta Page Layout Slots junto a la gestión de slots
La tarjeta compara los Page Layout Slots gestionados activos del Page Layout seleccionado con los Page Slots actuales de la página
La comparación informa como mínimo de:
los Layout Slots definidos por el Page Layout seleccionado
los Page Slots ya presentes en la página
los Layout Slots que faltan
los Page Slots adicionales no definidos por el Page Layout seleccionado
los Page Slots desactivados
los Page Slots respaldados por un Shared Slot
Add Missing Layout Slots solo aparece cuando faltan Layout Slots
La acción es explícita. Guardar los ajustes normales de la página no sincroniza los slots en silencio.

Reglas de seguridad

Add Missing Layout Slots crea en la página actual únicamente los Page Layout Slots activos que faltan
No elimina los Page Slots adicionales
No elimina bloques
No cambia el page_slots.source_type existente
No borra el shared_slot_id existente
No activa automáticamente los Page Slots desactivados
No reordena ni reescribe en silencio los Page Slots existentes
Los Page Slots adicionales se conservan y se informan por seguridad, aunque el Page Layout seleccionado no los defina
La compatibilidad de Shared Slot sigue siendo exacta según el handle public_shell guardado

Valores por defecto de las páginas nuevas

Las páginas nuevas usan, cuando es posible, los Page Layout Slots gestionados activos del Page Layout seleccionado
La reserva heredada slot_schema permanece solo como reserva segura de compatibilidad cuando no hay definiciones de slot gestionadas relacionales o integradas disponibles
Las páginas nuevas no deberían obligar a los administradores a añadir manualmente los slots estándar tras elegir un Page Layout

Cambios de Page Layout en páginas existentes

Cambiar el Page Layout seleccionado en una página existente no elimina ni reescribe automáticamente los slots durante un guardado normal
Tras guardar, Edit Page muestra la comparación actualizada para que los editores revisen con seguridad los slots que faltan o sobran
La versión actual prefiere deliberadamente el Add Missing Layout Slots explícito antes que la mutación automática

Body Class

Body Class es una lista opcional de tokens separados por espacios que se añade al <body> público
Los valores integrados sembrados son actualmente layout-default y layout-docs
El renderizado público mantiene la clase base wb-public-body y añade las clases de body del Page Layout cuando están disponibles
El CSS específico de layout puede apuntar a combinaciones como body.layout-docs más los ids y clases de slot definidos por los Page Layout Slots
Prefiera un bloque Navbar para las cabeceras públicas fijas; el CMS promueve los slots de cabecera por defecto con una sola Navbar a la raíz nav.wb-navbar, de modo que WebBlocks UI controla el desplazamiento fijo y el apilamiento

Límites de responsabilidad

El Page Layout es responsable de la elección del armazón público exterior
El Page Layout también es responsable de los tokens de clase de body públicos de ese armazón
Los Page Layout Slots son responsables de los metadatos y el orden de los envoltorios de región
Los Page Layout Slots son responsables del elemento envoltorio público, su id, sus clases y el HTML de confianza opcional adyacente al envoltorio de cada región
Los nombres de slot son responsables de la semántica del envoltorio de región, como header, main, sidebar y footer
Los bloques son responsables del contenido renderizado dentro de esos envoltorios
El comportamiento fijo de la navbar sigue siendo responsabilidad de .wb-navbar de WebBlocks UI, no de los Page Layouts del CMS

Layouts desconocidos o ausentes

Las páginas existentes no se migran fuera de public_shell
Los handles de layout desconocidos se conservan tal cual
La edición en la administración se mantiene segura mostrando el handle heredado actual como una opción preservada
El renderizado público recurre a una alternativa segura en lugar de fallar
En la V1, los handles desconocidos recurren de forma segura al comportamiento de runtime por defecto

Compatibilidad con Shared Slot

En la V1, la compatibilidad de Shared Slot sigue siendo conservadora.

Las pantallas de administración de Shared Slot presentan ahora esta restricción como Page Layout, mientras que el campo de compatibilidad almacenado sigue siendo public_shell por compatibilidad con versiones anteriores en esta versión
Se exige una coincidencia exacta del handle public_shell cuando un Shared Slot define public_shell
Un public_shell vacío sigue siendo genérico
Un handle de layout personalizado que reutiliza el comportamiento de runtime de tipo docs no coincide automáticamente con los Shared Slots restringidos a docs
Añadir los Layout Slots que faltan crea Page Slots nuevos como Page Content por defecto y no amplía el comportamiento de compatibilidad de los Shared Slots

Límite de portabilidad

La exportación/importación de sitios y la clonación siguen transfiriendo los handles public_shell a nivel de página como configuración de página
En la V1, las definiciones de Page Layout y de Page Layout Slot a nivel de instalación no se incluyen en la exportación/importación de sitios
Si una página transferida usa un handle de layout personalizado, la instalación de destino debería tener un handle de Page Layout equivalente para obtener el comportamiento previsto
Si no existe un layout equivalente en la instalación de destino, el renderizado recurre a una alternativa segura