Conceptos básicos

WebBlocks CMS utiliza un modelo de contenido relacional explícito construido en torno a páginas, layouts, slots y bloques.

La estructura básica es:

Page -> Layout -> Slots -> Blocks

• Una página posee el enrutamiento, el contexto de sitio, el estado del flujo de trabajo y la selección de layout.
• Una página también puede poseer filas relacionales de Page Assets con referencias a archivos CSS y JS con alcance de página.
• Un layout define las regiones estructurales disponibles.
• Los slots son áreas de colocación con nombre dentro del layout, como header, main, sidebar y footer.
• Los bloques son las unidades de contenido reales que se colocan en los slots y, cuando está soportado, se anidan bajo otros bloques.

Las páginas no almacenan JSON libre de constructor de páginas. El contenido y las relaciones se mantienen en tablas relacionales para que la estructura siga siendo explícita y revisable.

• Page Assets es una funcionalidad básica del CMS para referencias a archivos CSS y JS con alcance de página.
• Page Assets se almacena de forma relacional en page_assets, no dentro del JSON de pages.settings.
• La V1 solo acepta rutas locales de la instalación bajo /site/....
• Se rechazan las URL externas, el CSS en línea, el JS en línea, las cadenas de consulta, los fragmentos, el recorrido de directorios y las extensiones no coincidentes.
• Actualmente, el CSS solo se renderiza en el head del documento público.
• Actualmente, el JS solo se renderiza en el head del documento público con defer.
• Los archivos públicos propiedad del CMS residen bajo public/cms/.
• public/storage es el enlace simbólico de almacenamiento público de Laravel para storage/app/public y es independiente de los archivos de sobrescritura de sitio o de página.
• Las rutas públicas canónicas de los archivos son public/site/{site_handle}/css/site.css, public/site/{site_handle}/js/site.js, public/site/{site_handle}/pages/{page_slug}/page.css y public/site/{site_handle}/pages/{page_slug}/page.js.
• Page Assets se renderiza únicamente para la página pública propietaria y se excluye de los layouts de administración y de páginas no relacionadas.
• Las revisiones de página, la duplicación, el movimiento y la exportación o importación del sitio tratan Page Assets como configuración propiedad de la página.
• La importación JSON de una sola página también puede crear filas de page_assets cuando la carga útil usa rutas locales /site/... válidas que superan las reglas de validación de Page Assets existentes.
• La indexación de búsqueda no trata las rutas de Page Assets como contenido del cuerpo de la página.

• Una página pertenece exactamente a un sitio a la vez.
• El formulario habitual Edit Page mantiene Site como solo lectura en las páginas existentes.
• Duplicar una página crea un nuevo registro de página en el mismo sitio o en otro sitio accesible.
• Los movimientos de páginas entre sitios usan un flujo de trabajo dedicado Move to another site en lugar de un cambio de campo en línea.
• La duplicación de páginas usa un flujo de trabajo dedicado Duplicate page en lugar de apoyarse en el formulario de página habitual.
• El movimiento se ejecuta como una transacción controlada para que pages.site_id y page_translations.site_id sigan siendo válidos frente a la clave foránea compuesta (page_id, site_id).
• La duplicación siempre inicia la nueva página como borrador y copia el estado del contenido sin copiar el historial de revisiones de la página de origen.
• El movimiento conserva el id de la página, las traducciones, los slots, los bloques propiedad de la página, las traducciones de los bloques, el orden, el estado del flujo de trabajo y el historial de revisiones.
• La duplicación conserva el layout, las traducciones, los slots, los bloques propiedad de la página, las relaciones de bloques anidados, las traducciones de los bloques y las referencias compatibles a Shared Slots, pero crea un nuevo id de página.
• Los conflictos de ruta en el sitio de destino son errores de validación bloqueantes en la versión actual.
• Las referencias a Shared Slots deben poder reasignarse a Shared Slots compatibles con el mismo handle en el sitio de destino; de lo contrario, el movimiento se bloquea.
• La duplicación dentro del mismo sitio conserva las referencias existentes a Shared Slots.
• La duplicación entre sitios solo reasigna los Shared Slots compatibles con el mismo handle en el sitio de destino.
• Cuando una duplicación entre sitios no puede reasignar algunos slots respaldados por Shared Slots, el comportamiento predeterminado sigue siendo bloquear la duplicación.
• El flujo de trabajo de duplicación ahora puede desactivar explícitamente solo esos slots incompatibles de la página duplicada en lugar de persistir una referencia a un Shared Slot de otro sitio no válida.
• Esa alternativa opcional escribe el slot de la página duplicada como disabled, borra shared_slot_id, deja la página de origen sin cambios y no copia los árboles de bloques de los Shared Slots a la página duplicada en esta versión.
• Las herramientas de portabilidad a nivel de sitio, como Export / Import y Site Clone, siguen siendo independientes de los movimientos y de la duplicación de páginas.
• Admin -> Pages -> Import Page es un flujo de trabajo de portabilidad con alcance de página. Crea una nueva página a partir de una carga útil JSON documentada webblocks.cms.page.v1 y es intencionadamente independiente de la Export / Import a nivel de sitio.
• La importación de una sola página en V1 siempre crea una página nueva y siempre la importa como borrador.
• La importación de una sola página en V1 no importa el historial de revisiones de la página de origen.
• Los slots de página respaldados por Shared Slots en la importación de una sola página deben referenciar un Shared Slot compatible del sitio de destino mediante un handle estable. En la V1, el importador no crea Shared Slots automáticamente.

• La identidad de producto de WebBlocks CMS es fija en el shell de administración y proviene de App\Support\WebBlocks.
• Project Identity es el contexto de administración a nivel de instalación que se configura en Admin -> System -> Settings.
• Project Identity incluye actualmente Project Name y Project Tagline.
• Project Identity se utiliza únicamente para el contexto de la barra superior de administración y para los títulos del navegador en la administración.
• Project Identity no cambia la marca fija de la barra lateral de WebBlocks CMS, el pie de versión de la barra lateral, los metadatos públicos del sitio, el favicon público, el alcance de la búsqueda pública ni los valores SEO de las traducciones de página.
• Los registros de sitio poseen la identidad y los metadatos de cara al público.
• sites.name sigue siendo el nombre interno del registro en la administración.
• display_name es la sobrescritura opcional del nombre público del sitio.
• tagline es texto público opcional para el sitio.
• seo_title, seo_description y seo_keywords son metadatos de respaldo a nivel de sitio.
• favicon_media_id y social_image_media_id son referencias de medios opcionales a nivel de sitio para la salida del head público.
• site_variables son valores de texto plano reutilizables opcionales a nivel de sitio para la sustitución controlada de tokens públicos.
• Las filas de traducción de página también poseen campos de sobrescritura SEO localizados, como seo_title, seo_description, seo_keywords, og_title, og_description y og_image_media_id.
• Esto mantiene los metadatos públicos de la página dependientes del idioma y fuera de los ajustes JSON compartidos de la página.

• Media es el nombre canónico de los archivos subidos compartidos en todo el runtime activo del CMS.
• Los nombres técnicos activos usan ahora Media, media_id, media, media_folders y block_media en el código de runtime actual, las peticiones, las revisiones y los paquetes de transferencia de sitios.
• Los nombres heredados Asset se conservan únicamente para envoltorios de compatibilidad, migraciones históricas y la normalización de cargas útiles o archivos antiguos.
• Admin -> Media mantiene el título principal de la lista Media y el título de la tarjeta del listado Media Library.
• En la lista de Media, tanto el enlace del título como el icono del lápiz abren Edit Media: {title} y llevan una URL de retorno segura a la lista filtrada actual.
• El icono del ojo sigue siendo la acción de vista previa ampliada en modal desde la lista.
• La ruta de detalle /webadmin/media/{id} redirige a /webadmin/media/{id}/edit, de modo que los enlaces de detalle de medios llevan a la pantalla de edición canónica.
• Edit Media reúne la vista previa, los detalles del archivo, los metadatos, la organización, el uso y la gestión de la zona de peligro en una sola pantalla.
• Copy public URL se encuentra ahora en el área File Details de la pantalla de edición, en lugar de en la columna de acciones de la lista.
• La eliminación sigue el patrón estándar de modal de administración más Danger Zone, en lugar del marcado de confirmación del navegador.

• Las Site Variables se almacenan de forma relacional en site_variables.
• Son registros ordenados con alcance de sitio, con clave, etiqueta, valor, estado de activación y orden de clasificación.
• La sintaxis de token público admitida es exactamente {{ site.variable_key }}, con espacios internos opcionales.
• Las claves se normalizan a snake_case en minúsculas y deben coincidir con el patrón conservador ^[a-z][a-z0-9_]*$.
• Los tokens desconocidos, las variables desactivadas, las claves no válidas y los tokens ajenos al sitio permanecen sin cambios.
• La sustitución es solo textual. No es un motor de plantillas general.
• No se admiten condicionales, bucles, llamadas a funciones, acceso a env, acceso a config, ejecución de PHP, variables anidadas ni expresiones arbitrarias.
• La sustitución solo se produce durante el renderizado público compartido y la indexación de la búsqueda pública.
• Los formularios y las vistas previas de administración conservan el texto del token tal como está almacenado.
• Los valores de las variables se tratan como texto plano. En contextos públicos que admiten HTML se insertan como texto escapado, no como marcado ejecutable.

La edición se realiza a través de los slots.

Flujo habitual:

1. Cree una página.
2. Asigne un layout.
3. Edite los slots del layout.
4. Añada y ordene bloques dentro de esos slots.

Los bloques pueden tener relaciones padre-hijo, lo que permite estructuras de contenido agrupadas sin reducir el modelo a bloques opacos.

Los bloques son las unidades editoriales reutilizables del CMS.

• Los datos compartidos contienen la estructura, la colocación, los archivos y los ajustes operativos.
• Los datos traducidos contienen el texto dirigido al usuario para cada idioma.
• El contenido dirigido al usuario no se almacena en blobs JSON arbitrarios.

Los bloques de navegación del sistema siguen la misma regla relacional. Navbar conserva el handle persistido sticky-navbar por compatibilidad, pero ahora actúa como un bloque contenedor primitivo: renderiza únicamente nav.wb-navbar más los bloques hijos anidados. Por sí mismo no renderiza el marcado de marca, los enlaces de menú, las acciones de cabecera ni un contenedor forzado.

La composición de la Navbar es relacional en lugar de estar dirigida por JSON:

• Navbar posee únicamente la semántica del envoltorio y un ajuste compartido Position.
• Container posee la restricción de anchura. Los contenedores heredados siguen usando por defecto el flujo apilado por compatibilidad, pero Flow = None hace que Container sea neutral respecto al layout, de modo que los bloques de layout hijos controlan la composición.
• Cluster es la primitiva de layout horizontal o agrupado. Sus ajustes controlan la anchura, la justificación, la alineación en el eje transversal, el ajuste de línea y el espaciado.
• Stack sigue siendo la primitiva de flujo vertical.
• Navbar Brand posee el logotipo y el texto de marca.
• Navbar Navigation posee la selección de menú y renderiza los navigation_items del sitio usando las clases de navbar de WebBlocks UI. En pantallas estrechas también renderiza un botón de menú accesible que abre el mismo menú mediante el comportamiento de dropdown de WebBlocks UI, dejando la marca y las acciones de cabecera en la fila principal de la navbar.
• Header Actions, Search Form, Container y otros bloques compatibles pueden colocarse dentro de Navbar como hijos cuando sea necesario.
• Navbar Brand y Navbar Navigation deben residir en algún punto del árbol de ancestros de Navbar, pero no es necesario que sean hijos directos del bloque raíz Navbar.
• Navbar Brand admite el uso solo con logotipo cuando existe una imagen de logotipo. Cuando el texto del título visible está vacío, una etiqueta accesible explícita o la etiqueta resuelta del sitio proporcionan el nombre alternativo seguro.

Composición recomendada:

• Navbar
• Container (Flow: None)
• Cluster (Width: Full, Justify: Between, Align: Center, Wrap: Nowrap)
• Navbar Brand
• Cluster (Justify: End, Align: Center, Wrap: Nowrap)
• Navbar Navigation
• Header Actions

Use Container para la anchura, Cluster para la distribución horizontal y Stack para el flujo vertical. Navbar sigue siendo únicamente el envoltorio nav y no añade por sí mismo ayudantes de layout específicos del CMS.

Esto mantiene la composición de la cabecera explícita, reutilizable y alineada con WebBlocks UI, en lugar de duplicar una superficie de diseño de navbar exclusiva del CMS.

Esto mantiene clara la propiedad del contenido en el multisitio, la localización, las revisiones y el renderizado público.

La búsqueda V1 es infraestructura pública derivada, no lógica de sitio web de la capa de proyecto.

• La búsqueda indexa únicamente páginas públicas publicadas.
• Las filas de búsqueda tienen alcance por sitio e idioma.
• La búsqueda usa las traducciones de página como fuente de verdad para el título y los metadatos de la URL pública.
• El contenido de búsqueda se construye a partir de los bloques publicados propiedad de la página más los bloques compatibles de Shared Slots resueltos en el contexto de la página que los consume.
• Las páginas de origen de Shared Slots ocultas se excluyen de la resolución de rutas públicas y de los resultados de búsqueda independientes.
• La primera versión almacena las filas derivadas en la tabla de base de datos public_search_index y usa coincidencias SQL conservadoras en lugar de un servicio de búsqueda externo.
• Las filas de búsqueda son datos de runtime derivados y pueden reconstruirse de forma segura a partir del contenido del CMS.

La estructura de la página pública se controla en la capa de página y de slot.

• Page Layout es el nombre visible en la administración de la configuración del envoltorio exterior a nivel de página.
• Los Page Layouts son ahora registros gestionados a nivel de instalación en Admin -> System -> Page Layouts.
• El campo de compatibilidad almacenado sigue siendo public_shell en esta fase, de modo que los datos y los handles de página existentes siguen siendo válidos.
• default es el shell público estándar.
• docs es el shell orientado a documentación para layouts con regiones de cabecera, barra lateral y contenido principal.
• Los Default Layout y Docs Layout integrados son layouts del sistema precargados con los handles estables default y docs.
• Las páginas almacenan el handle del Page Layout seleccionado, no un modo de shell resuelto aparte.
• Page Layout ahora es propietario de tokens públicos body_class opcionales y validados.
• Los Page Layout Slots son registros relacionales a nivel de instalación asociados a un Page Layout que definen el orden de los slots y los metadatos del envoltorio.
• Los Slot Types son el catálogo reutilizable para la asignación de Page Layout Slots.
• El renderizado en tiempo de ejecución resuelve el handle almacenado a un registro Page Layout cuando está disponible y, a continuación, resuelve las clases del body y los envoltorios de slot a partir de sus Page Layout Slots gestionados.
• Body Class está pensado para CSS específico del layout en el <body> público, mientras que los ids y las clases de los envoltorios de Page Layout Slot proporcionan puntos de anclaje CSS a nivel de región dentro de ese layout.
• El comportamiento sticky de la Navbar pública proviene de la primitiva wb-navbar incluida. Cuando un slot de cabecera público predeterminado contiene únicamente un bloque Navbar, el CMS promueve el envoltorio del slot a la raíz nav.wb-navbar para que el comportamiento sticky no quede limitado por un envoltorio de cabecera adicional.
• Edit Page compara los Layout Slots gestionados del Page Layout seleccionado con los Page Slots actuales de la página.
• Los Layout Slots que falten pueden añadirse explícitamente mediante Add Missing Layout Slots.
• Los Page Slots sobrantes se conservan por seguridad y se notifican en lugar de eliminarse.
• Las páginas nuevas utilizan los Page Layout Slots gestionados activos del Page Layout seleccionado antes de recurrir a los arrays de slots heredados.
• Cambiar el Page Layout en un guardado normal no modifica automáticamente los Page Slots existentes.
• Los Page Layouts personalizados de V1 pueden usar handles personalizados, pero siguen reutilizando de forma conservadora el comportamiento de shell default o docs existente por compatibilidad.
• El nombre del slot determina el rol semántico del envoltorio público de esa región.
• Los envoltorios de slot se resuelven automáticamente a partir de los Page Layout Slots gestionados cuando están disponibles, con definiciones de reserva heredadas para los layouts integrados. Los slots desconocidos utilizan el envoltorio div predeterminado seguro.
• El HTML de layout avanzado y de confianza existe únicamente para el marcado estructural adyacente al envoltorio. No es una superficie de scripting general y no debe utilizarse para scripts.
• Los slots de cabecera son neutrales respecto al layout de forma predeterminada y no fuerzan wb-stack alrededor de sus árboles de bloques.
• Los slots principales todavía pueden gestionar el ritmo apilado a través de su parcial de shell cuando esa presentación es intencionada.
• El espaciado entre la cabecera y el contenido principal pertenece al envoltorio del shell público, no a Navbar ni a otros bloques de cabecera individuales. Los envoltorios de cabecera y principal del shell predeterminado gestionan ese ritmo para que el primer bloque de contenido no necesite márgenes superiores improvisados.
• El comportamiento sticky de la navbar debe seguir siendo propiedad del contrato .wb-navbar incluido en WebBlocks UI. El page layout y los envoltorios de los slots de cabecera gestionan la estructura a nivel de página, pero el CMS no debe inyectar una clase sticky de navbar paralela.
• Los bloques renderizan contenido dentro de esos envoltorios de slot y no deben gestionar el shell exterior de la página.
• La validación de Page Layout permite fragmentos de envoltorio de confianza para cubrir huecos estructurales, pero rechaza scripts, atributos de eventos, URLs javascript: y contenido iframe, object y embed.

Para las páginas de tipo documentación, utilice el page layout en lugar de trasladar la responsabilidad del layout a los bloques de contenido individuales. La receta habitual es Page Layout = Docs Layout con los slots Header, Sidebar y Main, de modo que el shell pueda asignarlos automáticamente a los envoltorios de navbar, barra lateral y contenido principal de la documentación.

En V1, Page Layout es propietario de la elección del shell público exterior, los nombres de slot son propietarios de la semántica de los envoltorios de región y los bloques son propietarios del contenido dentro de esos envoltorios.

• Los metadatos públicos se resuelven a partir del sitio actual y del contexto de traducción de la página actual, no a partir de Project Identity ni de los ajustes heredados y editables de nombre o eslogan de la aplicación.
• Los títulos públicos de página son de forma predeterminada Site Label · Page Label.
• La precedencia de la etiqueta del sitio es: display_name del sitio, seo_title del sitio, name del sitio y, por último, un valor de reserva seguro del CMS.
• La precedencia de la etiqueta de página es: seo_title de la traducción de la página y, después, el título de la traducción de la página.
• La precedencia de la descripción es: seo_description de la traducción de la página, seo_description del sitio y, si no, ninguna etiqueta de descripción.
• La precedencia de las palabras clave es: seo_keywords de la traducción de la página, seo_keywords del sitio y, si no, ninguna etiqueta de palabras clave.
• La precedencia del título de Open Graph es: og_title de la traducción de la página y, en caso contrario, el mismo patrón de título público con el sitio en primer lugar.
• La precedencia de la descripción de Open Graph es: og_description de la traducción de la página, seo_description de la traducción de la página y seo_description del sitio.
• La precedencia de la imagen de Open Graph es: og_image_media_id de la traducción de la página, social_image_media_id del sitio y, si no, ninguna etiqueta og:image.
• El medio del favicon del sitio no cambia y en esta fase sigue siendo exclusivamente de nivel de sitio.
• Los metadatos multisitio siguen teniendo en cuenta el host a través del sitio público resuelto; el sitio principal no se utiliza a ciegas cuando otro sitio coincide con el host actual.

• La búsqueda pública sigue limitada al sitio y al idioma (locale) resueltos.
• El texto de la ventana modal de búsqueda puede incluir la etiqueta del sitio resuelta para que los usuarios vean en qué sitio se está buscando.
• El texto de la búsqueda pública utiliza Site Identity, no Project Identity.

Los Shared Slots son una capa de propiedad del contenido de los slots que se sitúa bajo el modelo de page layout existente.

• El page layout sigue siendo propietario de qué slots están disponibles.
• El shell de página más el nombre del slot siguen siendo propietarios de los envoltorios públicos de cada slot.
• El origen de cada slot de página puede ser page, shared_slot o disabled.
• page significa que el slot utiliza bloques propiedad directa de la página, que es el comportamiento actual.
• shared_slot significa que el slot hace referencia a un árbol de bloques Shared Slot reutilizable y limitado al sitio que se renderiza dinámicamente en tiempo de ejecución público.
• disabled significa que el envoltorio del slot sigue existiendo, pero no se renderiza ningún bloque dentro de él.
• Los Shared Slots son árboles de bloques de slot reutilizables y limitados al sitio, no plantillas basadas en copias.
• Las referencias a Shared Slots solo son válidas dentro del mismo sitio. Las operaciones de página entre sitios deben reasignarse a un Shared Slot compatible del sitio de destino o recurrir a un resultado seguro de bloqueo o desactivación según la operación y la elección explícita del usuario.
• Los Shared Slots no son propietarios de los shells de página ni de los envoltorios de slot. El shell de página sigue siendo propietario del shell exterior, y el slot de página consumidor sigue siendo propietario del envoltorio de header, main, sidebar u otras regiones de slot.
• Un Shared Slot válido aporta únicamente el árbol de bloques renderizado dentro de ese envoltorio de slot de página existente.
• El renderizado público de Shared Slots es conservador:
• Las referencias a shared slots de otro sitio no renderizan nada.
• Las pantallas de administración de Shared Slots describen la restricción opcional SharedSlot.public_shell como Page Layout, pero el nombre del campo almacenado sigue siendo public_shell por retrocompatibilidad en esta versión.
• Si SharedSlot.public_shell está definido, debe coincidir exactamente con el handle del page layout consumidor.
• Si SharedSlot.slot_name está definido, debe coincidir con el nombre del slot de página consumidor.
• Los valores nulos o vacíos de public_shell y slot_name actúan como coincidencias genéricas.
• Un handle de Page Layout personalizado que se asigna a shell_type = docs no coincide automáticamente con un Shared Slot restringido a docs en V1.

El alcance actual incluye ya la base, el renderizado público, la gestión administrativa limitada al sitio, la asignación del origen de los slots de página y el soporte de portabilidad entre sitios para los Shared Slots.

• Los Shared Slots tienen su propio listado de administración y sus formularios de metadatos en el área de contenido de sitio de la administración.
• Los árboles de bloques de los Shared Slots se editan mediante un editor de bloques específico para Shared Slots que reutiliza el modelo actual de autoría de bloques en lugar de copiar el contenido en los slots de página consumidores.
• Los bloques de los Shared Slots siguen siendo registros blocks reales conectados mediante shared_slot_blocks, con el texto traducido en las tablas de traducción existentes.
• No se puede eliminar un Shared Slot mientras algún slot de página siga haciendo referencia a él.
• El editor de páginas ahora expone un selector de origen por slot con tres modos admitidos:
• Page Content: page_slots.source_type = page y shared_slot_id = null.
• Shared Slot: page_slots.source_type = shared_slot y shared_slot_id apunta a un Shared Slot activo y compatible del mismo sitio.
• Disabled: page_slots.source_type = disabled y shared_slot_id = null.
• Cambiar el origen de un slot no elimina ni desvincula el árbol de bloques propiedad de la página para ese slot. Si un editor cambia un slot a shared_slot o disabled, los bloques propiedad de la página permanecen asociados, de modo que volver a Page Content restaura el contenido específico de la página anterior.
• Añadir los Layout Slots que faltan sigue el mismo principio de seguridad: solo crea nuevos Page Slots y no altera los slots respaldados por Shared Slots, los slots Disabled ni los árboles de bloques propiedad de la página.
• El editor de páginas filtra las opciones de Shared Slot de forma conservadora. Solo aparecen los Shared Slots activos del mismo sitio, y las restricciones opcionales public_shell y slot_name del Shared Slot deben coincidir con el shell y el nombre de slot de la página consumidora.
• Los formularios de administración de Shared Slots etiquetan ahora esa restricción opcional public_shell como Page Layout, de modo que el término visible para el usuario coincida con las pantallas del editor de páginas y de gestión de Page Layouts.
• La exportación/importación y la clonación de sitios siguen transfiriendo los handles public_shell de nivel de página como parte de la configuración de la página. Las definiciones de Page Layout de nivel de instalación siguen siendo locales a la instalación en V1, por lo que las instalaciones de destino deberían definir cualquier handle personalizado que esperen renderizar sin recurrir a un valor de reserva.
• Las definiciones de Page Layout Slot de nivel de instalación también siguen siendo locales a la instalación en V1.
• Las protecciones del renderizado público en tiempo de ejecución se mantienen incluso después de la validación en el momento de la escritura, de modo que las asignaciones no válidas, obsoletas, de otro sitio, inactivas o incompatibles siguen sin renderizar contenido compartido públicamente.
• Los Shared Slots participan ahora en la exportación/importación y la clonación de sitios. Sus metadatos, los árboles de bloques de las páginas de origen ocultas, las traducciones, el orden anidado y las referencias de medios se transfieren como contenido de sitio de primera clase. Los slots de página consumidores mantienen las referencias shared_slot por handle de Shared Slot durante la exportación y se reasignan a los Shared Slots del sitio de destino durante la importación y la clonación.
• Las páginas de origen ocultas de los Shared Slots siguen siendo internas. Se excluyen de las cargas de exportación de páginas normales, de los listados de páginas ordinarios y del enrutamiento público, aunque sus registros de bloques sigan sustentando el editor de Shared Slots y los flujos de portabilidad.
• Los Shared Slots tienen ahora su propio historial de revisiones y su propio flujo de restauración, intencionadamente separado de las revisiones de página.
• Las revisiones de Shared Slot capturan los metadatos del Shared Slot y el árbol de bloques reutilizable del Shared Slot que hay detrás de la página de origen interna oculta.
• Restaurar una revisión de Shared Slot restaura el Shared Slot en su sitio. El id del Shared Slot permanece estable, las referencias page_slots.shared_slot_id existentes se mantienen intactas y el contenido restaurado afecta de inmediato a todas las páginas que hacen referencia a ese Shared Slot.
• Las revisiones de Shared Slot no consideran las revisiones de página como autoritativas para el contenido de los Shared Slots, y las revisiones de página no pretenden capturar los árboles de bloques de los Shared Slots.

La publicación del flujo de trabajo de página y la publicación de bloques están separadas de forma predeterminada. Publicar un registro de página hace que la página sea enrutable cuando sus reglas de idioma (locale) y ruta coinciden, pero no publica de forma silenciosa los bloques en borrador o en revisión que haya dentro de esa página. Esto permite que los editores y revisores publiquen el shell de la página mientras retienen determinados bloques para revisarlos más adelante.

Cuando un usuario elige explícitamente incluir los bloques propiedad de la página, WebBlocks CMS publica únicamente los bloques propiedad de los slots de página no compartidos de la página. Los bloques hijos anidados bajo esos slots propiedad de la página se incluyen. Los slots respaldados por Shared Slots quedan excluidos; sus árboles de bloques reutilizables deben revisarse y publicarse mediante los flujos de trabajo específicos de los Shared Slots.

La Internal Content API sigue la misma regla. POST /webadmin/api/pages/{page}/publish utiliza de forma predeterminada include_page_owned_blocks: false, requiere content.publish y excluye los Shared Slots. Las herramientas de IA u operador deben optar por include_page_owned_blocks: true únicamente con la aprobación explícita del usuario.

• Site Promotion trabaja sobre el contenido propiedad del sitio, no sobre toda la instalación.
• Puede actualizar campos seguros de identidad del sitio, asignaciones de idioma (locale), variables de sitio, páginas, traducciones de página, slots, bloques, Shared Slots, navegación, recursos de página y, opcionalmente, recursos de archivo del paquete.
• Conserva los datos de nivel de instalación y de tiempo de ejecución en vivo, como usuarios, sesiones, copias de seguridad, historial de actualizaciones, envíos de contacto, informes de visitantes, dominios, ajustes de entorno y secretos.
• No trata public_search_index como contenido portable. Las filas de búsqueda se reconstruyen a partir del contenido promocionado después de aplicar los cambios.
• Es un flujo de trabajo de paquete controlado, no una replicación de base de datos en bruto.

El núcleo de WebBlocks CMS contiene la funcionalidad reutilizable del CMS.

• Mantenga en project/ el código específico de la instalación que debe sobrevivir a las actualizaciones del CMS.
• Mantenga fuera del núcleo los comandos, vistas, rutas, configuración, ayudantes de importación y flujos de migración específicos del sitio cuando no sean funciones de producto reutilizables.
• Trate project/ como el límite de extensión seguro ante actualizaciones para una instalación.
• Mantenga en el núcleo el comportamiento de producto reutilizable, como bloques, layouts, interfaz de administración, renderizadores públicos, flujo de trabajo, copia de seguridad/restauración, exportación/importación y el soporte genérico de la capa de proyecto.
• Mantenga en project/ los ayudantes de migración/importación de sitios y las herramientas de sincronización de contenido específicas de la instalación.
• Los puentes de migración rápida de sitios web pueden vivir en project/ cuando son intencionadamente temporales y específicos de un sitio web. El importador de documentación restante de WebBlocks UI es un ejemplo: almacena los fragmentos <main> de la documentación obtenida como HTML de confianza en forma de carga útil de proyecto sin enseñarle al núcleo del CMS nada sobre ese sitio web.
• Ese tipo de puente debería preservar el contenido curado existente del CMS, mantener el comportamiento del shell o de la navegación bajo la propiedad del CMS y hacer explícito el límite temporal de HTML de confianza para que siga siendo posible refinarlo más adelante hasta convertirlo en bloques de primera clase.
• Los paquetes de versión del núcleo no incluyen contenido de project/.

Consulte ../DEVELOPMENT.md para conocer el flujo completo de desarrollo y publicación de versiones.