Operaciones

WebBlocks CMS incluye herramientas operativas a nivel de instalación para actualizaciones, copias de seguridad y paquetes de transferencia de sitios.

Settings también se encuentra en la navegación System de la administración porque controla la identidad del proyecto, el idioma, la zona horaria, la privacidad, la versión y los ajustes de entorno a nivel de instalación.

Admin -> System -> Block Types también sirve como pantalla de inspección del catálogo a nivel de instalación. Su filtro Support se refiere a los metadatos de capacidad y de origen de contenido de los bloques, mientras que su filtro Usage se refiere a los recuentos de uso reales de la tabla blocks, de modo que los administradores puedan revisar qué filas de tipos de bloque se usan y cuáles no.

Admin -> System -> Visitor Reports ofrece informes de tráfico respetuosos con la privacidad junto a los ajustes del sistema a nivel de instalación.

Maintenance sigue siendo el grupo de herramientas operativas para:

• Search Rebuild
• Backups
• Export / Import
• Update

Visitor Reports es un informe operativo respetuoso con la privacidad sobre la actividad de las páginas públicas. Las visitas anónimas a páginas pueden contarse sin identificadores basados en consentimiento. El informe también almacena información agregada de referentes, campañas, dispositivos y bots:

• los referentes se normalizan a host/dominio más el tipo direct, internal o external; las URL completas de referente no se almacenan ni se muestran
• los referentes vacíos se agrupan como Direct / Unknown
• la fuente, el medio y la campaña UTM se almacenan solo como valores normalizados; la cadena de consulta completa no se almacena
• las cadenas de user-agent se reducen en el momento de la petición a una categoría de dispositivo (desktop, mobile, tablet, bot o unknown) más familias aproximadas de navegador y sistema operativo cuando están disponibles; las cadenas completas de user-agent no se almacenan
• los patrones conocidos de user-agent de rastreadores y bots se cuentan como visitas de bots y siguen siendo visibles en el informe en lugar de eliminarse silenciosamente

Los visitantes únicos, las sesiones, las páginas de entrada y la media de páginas por sesión requieren un seguimiento de sesión basado en consentimiento. Cuando un filtro de fecha, sitio, idioma o tráfico contiene visitas pero ningún identificador de sesión o de visitante utilizable, la interfaz muestra Not tracked en lugar de 0. Las filas antiguas que no pueden rellenarse de forma segura siguen mostrando Unknown, Direct / Unknown o Not tracked, según los campos agregados existentes.

La autorización con alcance de sitio se sigue aplicando: los superadministradores pueden ver todos los sitios, mientras que los administradores de sitio y los editores solo pueden ver los datos de los sitios asignados. El filtro de sitio se limita a los sitios accesibles para el usuario.

System Updates comprueba la versión del código del CMS en ejecución frente al servicio de actualizaciones configurado.

La pantalla de actualización puede informar de estados como:

• actualización disponible
• al día
• versión local/de código más reciente que la última versión publicada
• actualización incompatible disponible
• no se han encontrado versiones
• servidor de actualizaciones no disponible
• respuesta no válida o no admitida

El flujo de actualización dentro de la aplicación descarga el paquete de la versión, aplica las reglas de rutas protegidas, ejecuta las migraciones de actualización necesarias, limpia las cachés, verifica la versión de código de WebBlocks CMS aplicada frente a la versión de destino, registra la ejecución de la actualización y persiste la versión instalada.

La disponibilidad de actualizaciones se basa en que la última versión publicada sea más reciente que la versión del código del CMS en ejecución. Las ejecuciones de actualización fallidas del pasado y los valores obsoletos de versión instalada almacenados siguen pudiendo consultarse a través del modal de la última ejecución, el informe de soporte, la CLI de ejecuciones conservadas o Update Readiness, pero por sí mismos no hacen que una instalación actual sea accionable.

La pantalla muestra por defecto dos tarjetas: primero Install Update y después Update Details. Install Update es la única área de acción principal. Cuando hay una actualización compatible disponible, muestra la ruta de versión actual a la última, el estado de compatibilidad, la llamada a la acción de instalación y un acordeón Package Safety Details plegado. Cuando no hay ninguna actualización disponible, muestra un mensaje discreto de estar al día o de no disponibilidad y omite los detalles de seguridad del paquete.

Update Details contiene filas de acordeón de WebBlocks UI para Release Notes, Update Readiness y Last Update Run. Update Readiness describe la instalación actual y las comprobaciones del servicio de actualizaciones; no es contenido de notas de versión para la versión de destino. Last Update Run muestra en la pantalla principal solo el resumen de la ejecución relevante más reciente, con los detalles disponibles en un modal. Los superadministradores pueden descargar un informe de soporte desde la misma tarjeta para flujos de soporte en alojamiento compartido; el informe evita tokens, secretos, rutas locales absolutas y trazas de pila sin procesar, e incluye la versión actual y la más reciente, la preparación, los detalles de la última ejecución y los resúmenes de las ejecuciones conservadas.

Update History ya no se muestra como una tabla en la pantalla principal y la eliminación de filas no forma parte de la interfaz de administración. Los registros de ejecuciones de actualización se purgan automáticamente y se conservan por defecto las últimas cinco ejecuciones. La última ejecución fallida se conserva hasta que exista una ejecución correcta más reciente. Los operadores con acceso a terminal pueden inspeccionar los registros conservados con php artisan webblocks:updates:runs, php artisan webblocks:updates:runs --last o php artisan webblocks:updates:runs --failed, y pueden ejecutar una purga controlada con php artisan webblocks:updates:prune-runs --keep=5.

El cliente de actualizaciones admite metadatos estructurados del servicio de actualizaciones, incluidos el título, el resumen, los aspectos destacados, las correcciones, las notas de compatibilidad, las notas de migración, las notas sobre archivos, las notas para el operador y las notas técnicas. Estos valores se renderizan como texto plano escapado en grupos orientados al operador dentro del acordeón Release Notes. Las versiones más antiguas que solo proporcionan release_notes siguen mostrando esas notas correctamente, y las versiones sin notas muestran No release notes were provided for this release. Las comprobaciones de preparación, la versión instalada almacenada y los valores de bajo nivel del servidor de actualizaciones permanecen en Update Readiness.

La sincronización del catálogo core ya no forma parte de la cadena normal de aplicación de System Update. Los paquetes de versión aplican código, archivos, las migraciones de actualización necesarias, la limpieza de cachés, la verificación de versión posterior a la aplicación, el historial de ejecuciones y la persistencia de la versión instalada; la reparación amplia del catálogo es un flujo de mantenimiento explícito.

Para el mantenimiento manual o la recuperación en una instalación existente, los administradores y desarrolladores también pueden ejecutar:

webblocks:catalog-repair admite --block-types, --slot-types, --page-layouts, --icons y --all. Informa de las filas creadas, actualizadas, sin cambios y omitidas, conserva las filas de catálogo personalizadas propias de la instalación y puede ejecutarse repetidamente. block-types:sync-core se mantiene como comando de compatibilidad de más bajo nivel para el catálogo de tipos de bloque.

Los paquetes de versión publicados son paquetes de producto core. Distribuyen código fuente del CMS reutilizable, archivos, migraciones, vistas, rutas, configuración, documentación y pruebas, pero no distribuyen contenido de la capa de proyecto específico de la instalación procedente de project/.

La publicación de versiones/actualizaciones del CMS es un flujo de trabajo nativo/local del mantenedor:

release:prepare construye localmente el ZIP con raíz de paquete, la suma de comprobación y la carga útil para el publicador. release:publish-update envía el paquete y los metadatos al endpoint de publicación predeterminado propiedad del paquete https://publisher.webblocksui.com/api/updates/publish y, a continuación, verifica los últimos metadatos del servidor de actualizaciones para webblocks-cms en el canal estable. Los sitios CMS instalados no configuran claves de entorno de Publisher/servidor de actualizaciones, producto o canal en los archivos .env normales; el código de producto del CMS posee el servidor de versiones predeterminado, la clave de producto, el canal estable, la ruta de la última versión y la ruta de publicación a través de ReleaseDefaults. Normalmente, para publicar solo se necesita WEBBLOCKS_PUBLISHER_TOKEN. Las ejecuciones con configuración cacheada solo refrescan ese token desde el .env del proyecto, y los diagnósticos solo informan de si está configurado o no. El antiguo puente updates.webblocksui.com es únicamente histórico y no debe usarse como ruta de configuración activa. Los commits y las etiquetas de Git son solo pasos del historial del código fuente. GitHub Actions, las releases de GitHub, las URL de archivos de GitHub, la API de GitHub y la CLI gh no forman parte de la publicación de actualizaciones del CMS, y los flujos de trabajo .github están ausentes de forma intencionada.

Las copias de trabajo del CMS instaladas son consumidoras de actualizaciones. Pueden obtener el historial del código fuente cuando sea necesario, pero no deben hacer push upstream ni publicar actualizaciones del CMS desde una copia de instalación.

Los envíos del Contact Form se guardan antes de la entrega de la notificación. El estado de la notificación por correo electrónico refleja únicamente el comportamiento de la notificación y no cambia el estado editorial ni la clasificación de spam. Sent significa que Laravel aceptó el envío a través de un transporte de correo real configurado sin excepciones; no garantiza la entrega en la bandeja de entrada. Failed significa que se intentó un envío real y se produjo un fallo saneado. Skipped o Not configured significa que no se intentó ningún envío real porque la notificación estaba desactivada, no se resolvió ningún destinatario, el mailer es log, array o null, o la configuración SMTP está incompleta. El spam puntuado se almacena/pone en cuarentena de forma intencionada para su revisión por parte del administrador; solo los envíos con el campo de comprobación generado relleno o demasiado rápidos pueden descartarse antes de almacenarse, con la redirección genérica de éxito. Un umbral configurable futuro como CONTACT_SPAM_AUTO_DISCARD_SCORE podrá plantearse cuando existan suficientes datos de producción para ajustarlo con seguridad.

Los destinatarios de las notificaciones del Contact Form se resuelven en este orden:

1. recipient_email del bloque Contact Form
2. Destinatario de contacto predeterminado del sitio, desde Site -> Edit -> Contact
3. .env CONTACT_RECIPIENT_EMAIL
4. alternativa segura MAIL_FROM_ADDRESS

Los ajustes SMTP habituales de Laravel en .env son:

Después de editar los ajustes de correo del .env en una instalación de producción o de paquete, limpie la configuración cacheada cuando sea necesario:

Use el comando de diagnóstico de correo sin secretos cuando un Contact Message muestre un fallo de notificación:

El comando informa del mailer resuelto, el host, el puerto, los campos de esquema/cifrado, el nombre de usuario, la dirección de origen, CONTACT_RECIPIENT_EMAIL, el estado de la caché de configuración y las alternativas opcionales de destinatario del bloque Contact Form o del sitio. Nunca imprime MAIL_PASSWORD ni valores de tokens. La prueba de envío opcional informa únicamente del éxito o de un detalle de fallo saneado, de modo que los operadores puedan distinguir entre configuración obsoleta, discrepancia de host/puerto/cifrado, discrepancia de usuario/dirección de origen y credenciales de buzón no válidas, sin filtrar secretos en los registros del terminal.

Use Contact Messages como fuente de verdad para los envíos almacenados y el estado de las notificaciones. Los mailers de desarrollo como log, array y null no deben considerarse correo entregado en los informes de operaciones.

Prueba de humo operativa:

1. Publique o previsualice una página con el bloque nativo contact_form.
2. Envíe un mensaje de prueba.
3. Confirme que el mensaje aparece en /webadmin/contact-messages.
4. Revise el estado de la notificación y el detalle seguro del fallo.
5. Ejecute php artisan contact:mail-diagnose --block=ID si la resolución del destinatario no está clara.
6. Ejecute php artisan contact:mail-diagnose --send-test=operator@example.com solo para una comprobación controlada de envío SMTP.

WebBlocks UI Manager es un plugin interno/de operador para operaciones de publicación específicas del producto. No se incluye en los paquetes normales de runtime del CMS y las instalaciones habituales del CMS no deberían instalarlo. Construya su artefacto local desde el repositorio de mantenimiento con:

Suba el ZIP generado a través de System -> Plugins como superadministrador, revise el detalle del plugin instalado y, a continuación, actívelo explícitamente. Los plugins subidos se instalan desactivados de forma predeterminada. Las instalaciones desactivadas o incompatibles permanecen inertes, y su estado de salud no se comprueba mientras están desactivadas.

Si el plugin declara migraciones, activarlo no implica que la configuración esté completa. La pantalla de detalle del plugin muestra Setup required / Plugin migrations pending cuando faltan tablas propiedad del plugin. Use la acción de superadministrador Run Plugin Migrations desde la pantalla de detalle del plugin para ejecutar únicamente las migraciones declaradas por ese plugin instalado y solo desde la ruta de instalación del plugin. La acción es idempotente, registra un resultado de configuración en el archivo de estado de activación del plugin e informa de errores sin secretos. Las rutas de plugins activados que sean visibles antes de la configuración deben mostrar orientación de configuración controlada en lugar de errores de base de datos sin procesar.

Si una instalación ejecutó brevemente la v1.32.67 y creó tablas webblocks_ui_manager_*, este parche no las elimina automáticamente. La desinstalación manual del plugin también conserva las tablas propiedad del plugin. Déjelas en su sitio salvo que un operador haya confirmado que el plugin no es necesario y realice una limpieza manual de la base de datos por separado, con una copia de seguridad.

Cuando se instala, se activa y se configura manualmente, el plugin añade /webadmin/plugins/webblocks-ui-manager/releases para los metadatos de versión de WebBlocks UI, la validación en modo simulación y la publicación en un CDN estático local. Los usuarios super_admin del CMS pueden abrir las rutas de plugins activados mediante los permisos propiedad del plugin declarados en el manifiesto; los roles que no sean superadministrador requieren concesiones explícitas de permisos del plugin. Si faltan webblocks_ui_manager_releases, webblocks_ui_manager_artifacts o webblocks_ui_manager_publish_runs, la pantalla Releases muestra la orientación de configuración requerida y enlaza de vuelta a la configuración del plugin en lugar de consultar tablas inexistentes. Prepare una versión con archivos dist locales de WebBlocks UI:

El comando registra los metadatos de la versión, calcula las sumas de comprobación SHA-256 y prepara los metadatos del manifiesto para la convención estática propia public/cdn/webblocks-ui/{version}/.... Los archivos dist esperados se configuran mediante webblocks-plugins.webblocks_ui_manager.expected_dist_files y son de forma predeterminada webblocks-ui.css, webblocks-icons.css y webblocks-ui.js.

Valide el plan de publicación sin escribir archivos:

Aplique la publicación local una vez superada la validación en modo simulación:

El flujo de publicación valida las rutas de origen, la correspondencia entre versión y ruta de destino, los archivos dist esperados, las sumas de comprobación almacenadas, la coherencia del manifiesto y la idempotencia antes de escribir. Los archivos existentes con sumas de comprobación coincidentes se omiten. Los archivos existentes con sumas de comprobación distintas bloquean la publicación. El destino es local/propiedad del proyecto de forma predeterminada mediante WEBBLOCKS_UI_MANAGER_CDN_BASE_PATH=cdn/webblocks-ui; WEBBLOCKS_UI_MANAGER_CDN_BASE_URL son metadatos opcionales de visualización/URL. El flujo de trabajo no despliega en un servidor de producción externo, no publica metadatos en el servidor de actualizaciones ni cambia las URL de los archivos de WebBlocks UI del core del CMS.

System -> Plugins informa por separado de los estados desactivado, activado, incompatible, archivos faltantes y error. Los plugins desactivados muestran un estado de salud inactivo, no de fallo. Un plugin configurado como activado pero incompatible permanece inerte: no se activan rutas, comandos, menús, permisos, rutas de ajustes, widgets, archivos, declaraciones de bloques ni comportamiento de informe de salud del plugin.

La desinstalación manual solo está disponible para los plugins subidos manualmente después de haberlos desactivado. Elimina el directorio del paquete instalado propiedad del almacenamiento y el archivo de estado de activación, nunca archivos del core del CMS, archivos públicos de /cms, archivos del proyecto, archivos de vendor ni almacenamiento fuera de la raíz de plugins configurada. No ejecuta migraciones destructivas ni elimina tablas de base de datos propiedad del plugin.

El despliegue en una CDN de producción externa, las comprobaciones rápidas sobre CDN alojadas, el comportamiento genérico de instalación/actualización de plugins de terceros, los instaladores remotos arbitrarios, la instalación de paquetes de Composer, la publicación en un servidor de actualizaciones y los flujos de marketplace/catálogo siguen aplazados de forma intencionada.

Backup / Restore es la herramienta de recuperación a nivel de entorno.

Las copias de seguridad pueden incluir:

• volcado de la base de datos
• archivos subidos gestionados por el CMS desde storage/app/public
• metadatos del archivo comprimido en manifest.json

El comportamiento de restauración es explícito:

• solo pueden restaurarse las copias de seguridad completadas que tengan un archivo comprimido válido
• la descarga del archivo, el detalle, la elegibilidad para restaurar y las acciones de eliminación resuelven las rutas a través de la misma raíz del disco backups y bloquean el recorrido de directorios, los escapes por enlaces simbólicos y las rutas absolutas fuera de esa raíz
• los archivos comprimidos que falten o no puedan leerse se muestran como avisos controlados en la administración en lugar de como excepciones del sistema de archivos sin procesar
• la restauración crea primero una copia de seguridad de seguridad previa
• la restauración sustituye la base de datos actual
• la restauración sustituye storage/app/public cuando el archivo comprimido incluye los archivos subidos
• las restauraciones en MySQL/MariaDB ejecutan la importación con protecciones temporales de claves foráneas y de comprobación de unicidad, de modo que los volcados completos válidos siguen siendo portables aunque el orden de creación de las tablas difiera entre entornos
• las instalaciones existentes actualizadas mediante System Update también ejecutan, cuando es necesario, migraciones de reparación propiedad del paquete; así se mantienen alineados contratos de esquema como la clave padre pages(id, site_id) con copias de seguridad que contienen claves foráneas de page_translations con alcance de sitio

Use Backup / Restore cuando necesite recuperar el entorno de la instalación, no solo una página.

Export / Import es la herramienta de portabilidad de sitios.

Úsela para trasladar el contenido de un sitio entre instalaciones.

Los paquetes de transferencia de sitio se almacenan en el disco del sistema de archivos de Laravel llamado site-transfers, que por defecto es storage/app/site-transfers. Las instalaciones nuevas de consumidor mediante Composer registran este disco automáticamente y webblocks:install prepara el directorio de almacenamiento, de modo que las aplicaciones anfitrionas no necesitan editar config/filesystems.php salvo que quieran proporcionar un disco personalizado.

Las importaciones de sitio requieren que los catálogos de tipos de bloque y de tipos de slot respaldados por la base de datos en la instalación de destino contengan las filas a las que hace referencia el paquete. Las instalaciones nuevas mediante Composer siembran estos catálogos durante webblocks:install, el mantenimiento explícito del catálogo puede reparar las filas suministradas con webblocks:catalog-repair, y el ejecutor de importación realiza una sincronización final idempotente del catálogo básico antes de la validación cuando un paquete hace referencia a una fila básica suministrada que falta. Si un paquete hace referencia a un bloque o slot personalizado específico de una instalación que no está presente en el destino, el error de administración enumera los identificadores exactos que faltan.

El flujo de trabajo de administración tiene ahora dos puntos de entrada relacionados:

• Admin -> Sites incluye una acción de fila Export por sitio que abre un modal para el sitio seleccionado, muestra el nombre y el identificador del sitio y puede incluir archivos de medios antes de crear el paquete.
• Admin -> Maintenance -> Export / Import es la pantalla operativa combinada para el historial y las acciones de transferencia. Muestra juntos Site Exports y Site Imports, con las acciones Run Export y Run Import en las cabeceras de las tarjetas de listado correspondientes.
• La pantalla de revisión de importación mantiene la acción del paquete validado justo debajo del resumen de estado y del manifiesto, y después muestra los recuentos del paquete en una tabla compacta para revisarlos más rápido.
• Las instalaciones nuevas de consumidor mediante Composer representan las pantallas de Export / Import desde el espacio de nombres de vistas del paquete, por lo que no requieren archivos Blade en la raíz resources/views/admin/site-transfers/*.

Relación entre las herramientas:

• La acción Export de la fila de Sites crea un paquete para un solo sitio seleccionado y vuelve a la lista de sitios con un mensaje de éxito.
• Export / Import gestiona el historial de paquetes y es la pantalla principal de operaciones de exportación o importación.
• Sites -> Promote aplica un paquete de exportación o de promoción a un sitio de destino existente con simulación, estrategia, copia de seguridad de seguridad y reglas de conservación.

Export / Import abarca contenido con alcance de sitio, como:

• el registro del sitio y las asignaciones de idioma (locale)
• las variables de sitio almacenadas en site_variables
• páginas y traducciones de página
• los recursos de página almacenados en page_assets
• slots y bloques
• Shared Slots y sus árboles de bloques
• los ajustes de Page Layout a nivel de página, como default y docs (que internamente se siguen almacenando en public_shell)
• traducciones de bloque
• elementos de navegación, incluidos los slugs opcionales de icono de elemento de navegación que usan los renderizadores públicos de Sidebar Navigation
• archivos de medios opcionales
• los archivos canónicos de sobreescritura pública a nivel de sitio en public/site/{site_handle}/css/site.css y public/site/{site_handle}/js/site.js cuando Include media files está activado y esos archivos existen

Los Page Assets viajan en la portabilidad de sitios en dos capas:

• las filas de page_assets se incluyen siempre en las cargas de exportación e importación de sitio.
• Cuando Include media files está activado, los archivos públicos /site/... referenciados también se empaquetan en el archivo de exportación y se restauran en public/site/... al importar.
• Cuando Include media files está desactivado, los metadatos de los recursos de página se siguen importando, pero los archivos físicos referenciados ya deben existir en la instalación de destino.
• En la versión actual, los archivos de recursos de página que falten se notifican durante la exportación y se omiten, en lugar de hacer fallar la construcción completa del paquete.

Los recursos públicos de sobreescritura a nivel de sitio son intencionadamente más restringidos que los Page Assets: solo se incluyen css/site.css y js/site.js bajo el identificador del sitio de origen, y la importación los restaura bajo el identificador del sitio de destino final. Los árboles arbitrarios public/site/..., los recursos del núcleo del CMS y public/storage no forman parte de esta ruta.

Los Shared Slots se exportan e importan como contenido de sitio de primera clase:

• En el paquete se incluyen metadatos de Shared Slot como el identificador, el nombre, la compatibilidad de slot, la compatibilidad de contenedor y el estado activo.
• Los Shared Slots también pueden llevar una restricción opcional de compatibilidad con Page Layout. El campo almacenado sigue siendo public_shell por retrocompatibilidad; vacío sigue significando genérico y los valores no vacíos siguen exigiendo coincidencia exacta del identificador de Page Layout.
• Los árboles de bloques de Shared Slot, su orden anidado, sus traducciones y sus referencias de medios pasan por la misma canalización de empaquetado de bloques y medios que se usa para las páginas normales.
• Los slots de página que usan shared_slot exportan una referencia estable al identificador del Shared Slot y se reasignan al Shared Slot importado del sitio de destino durante la importación.
• Las cargas de página conservan el Page Layout de cada página, de modo que las páginas con contenedor docs mantienen tras la importación asignaciones compatibles de Shared Slot de documentación.
• Las propias definiciones de Page Layout y de Page Layout Slot a nivel de instalación no forman parte de la exportación/importación de sitio en la V1.
• Los identificadores personalizados de public_shell de página siguen transfiriéndose con la carga de la página, por lo que las instalaciones de destino deben proporcionar identificadores de Page Layout coincidentes cuando dependan de layouts personalizados.
• Si en la instalación de destino no existe un identificador de Page Layout coincidente, la representación pública recurre a una alternativa segura.
• Las páginas de origen ocultas de Shared Slot se mantienen internas y no se tratan en el paquete como páginas ordinarias de cara al usuario.
• El historial de revisiones de Shared Slot queda excluido de la exportación/importación, en línea con el límite actual de portabilidad de las revisiones de página.

Las variables de sitio también son contenido de sitio portable:

• las filas de site_variables se exportan e importan con el paquete del sitio.
• Se conservan las claves, las etiquetas, los valores, el orden y el estado de activación de las variables.
• El comportamiento de los tokens públicos no se evalúa durante la exportación o la importación; los valores en bruto se transfieren tal como están almacenados.

No incluye datos de ejecución globales de la instalación, como usuarios, copias de seguridad, historial de actualizaciones, sesiones o envíos de contacto.

Tampoco requiere el índice de búsqueda público derivado como contenido portable:

• public_search_index son datos derivados en tiempo de ejecución
• las cargas de exportación/importación no necesitan filas de búsqueda para recrear el sitio
• use php artisan search:rebuild tras la importación cuando necesite filas de búsqueda actualizadas de inmediato

La importación de una sola página en JSON es el flujo de trabajo de administración con alcance de página para crear una página nueva a partir de un archivo JSON.

• ruta de administración: Admin -> Pages -> Import Page
• alcance: una página nueva en un sitio seleccionado
• esquema: webblocks.cms.page.v1
• resultado: en la V1 siempre crea una página nueva en borrador
• en la V1 no actualiza una página existente
• no importa el historial de revisiones de la página de origen
• no sustituye al flujo de trabajo Export / Import a nivel de sitio

Lo que importa la V1:

• los campos básicos de la página necesarios para crear el borrador, incluido el Page Layout a nivel de página
• traducciones de página indexadas por código de idioma para los idiomas habilitados en el sitio de destino
• slots de página, incluidas las referencias shared_slot por identificador de Shared Slot compatible del mismo sitio
• árboles de bloques propios de la página con orden anidado padre-hijo
• filas de traducción de bloque admitidas para las familias de bloques traducibles
• metadatos de recursos de página para rutas locales válidas /site/... de CSS y JS

Restricciones de la V1:

• los conflictos de rutas traducidas en el sitio de destino bloquean la importación antes de escribir
• las referencias a Shared Slot ya deben existir en el sitio de destino y ser compatibles por sitio, estado activo, contenedor y nombre de slot
• el importador no crea Shared Slots automáticamente
• los valores de esquema no admitidos se rechazan de forma explícita
• el importador es transaccional y no deja ninguna página parcial cuando falla la validación

Consulte docs/examples/page-import-v1.json para ver la carga de ejemplo.

La promoción de sitio es el flujo de trabajo basado en paquetes para promover contenido propiedad de un sitio desde un paquete de origen hacia un sitio de destino existente.

Úsela cuando:

• el sitio de destino ya existe
• hay contenido propiedad del sitio que necesita una promoción controlada a ese sitio
• deben conservarse los datos de nivel de instalación, específicos del entorno y de ejecución en vivo

En qué se diferencia de las demás herramientas:

• Export / Import crea o gestiona paquetes de transferencia de sitio y, por defecto, crea un sitio local nuevo a partir de un paquete
• La promoción de sitio aplica el contenido de un paquete a un sitio de destino existente
• La clonación de sitio duplica contenido propiedad del sitio dentro de la instalación actual, sin paquete
• Backup / Restore es recuperación del entorno y puede sustituir la base de datos actual o los archivos subidos
• Las actualizaciones cambian el código del producto CMS y la versión instalada, no el contenido propiedad del sitio

Flujo de trabajo de la V1:

• ruta de administración: Admin -> Sites -> Promote
• comandos: site-promotion:inspect, site-promotion:dry-run, site-promotion:apply
• la simulación es obligatoria antes de aplicar
• al aplicar se crea primero una copia de seguridad de seguridad normal
• al aplicar se reconstruyen las filas de búsqueda derivadas del sitio de destino tras completarse correctamente

Entre las áreas conservadas se incluyen:

• usuarios y roles
• sesiones, caché, trabajos y colas
• copias de seguridad e historial de actualizaciones
• informes de visitantes y envíos de contacto
• dominios en vivo y registros de dominio de sitio
• configuración del entorno, secretos de la instalación y tokens internos
• filas derivadas de public_search_index

Estrategias admitidas:

• additive_update: crea el contenido de origen que falta y actualiza el contenido de destino coincidente sin eliminar el contenido adicional del destino
• mirror: crea y actualiza el contenido de origen coincidente y después archiva, desactiva o elimina el contenido propiedad del sitio de destino que esté ausente, cuando resulta seguro en la V1

Los flujos de trabajo de migración e importación de sitios web específicos de una instalación pertenecen a project/, no al núcleo del CMS.

La búsqueda V1 añade una pantalla operativa y un comando a nivel de instalación para el índice de búsqueda público derivado.

• pantalla de administración: Admin -> Maintenance -> Search Rebuild
• comando de reconstrucción: php artisan search:rebuild

La pantalla Search Rebuild revisa la cobertura del índice de búsqueda público derivado para las páginas publicadas por sitio e idioma, y puede reconstruir el índice de forma segura cuando las filas derivadas necesitan actualizarse.

Ámbitos de reconstrucción admitidos:

• toda la instalación
• un sitio con --site=
• un idioma con --locale=
• una página con --page=

La reconstrucción de la búsqueda no es destructiva:

• elimina y vuelve a crear únicamente las filas derivadas dentro del ámbito solicitado
• no modifica el contenido de páginas, bloques, traducciones, Shared Slots ni medios
• no requiere comandos destructivos de reinicio de la base de datos

System Settings es la pantalla compacta de configuración a nivel de instalación. Los grupos editables se dividen en tarjetas separadas y enfocadas, con sus propias acciones de guardado; Runtime Information es de solo lectura.

Conserva:

• Project Name y Project Tagline para el contexto de la instalación, solo en la administración
• el idioma (locale) predeterminado
• la zona horaria
• las filas por página de los listados de administración, para las pantallas de listado paginadas
• el modo de CMS Mail y los ajustes de correo personalizados para las notificaciones propiedad del CMS
• los ajustes del banner de cookies o de privacidad
• la información de versión del producto
• la información del entorno

No controla:

• las etiquetas fijas de marca de la administración de WebBlocks CMS
• la marca del sitio público
• los valores predeterminados de SEO del sitio público
• el favicon público, el alcance de la búsqueda pública ni el SEO de las traducciones de página
• el correo de autenticación del anfitrión/raíz ni el enrutamiento del formulario de contacto del sitio
• el contenido del archivo .env ni las variables de entorno

Project Identity ayuda a distinguir una instalación del CMS de otra en la barra superior de administración y en el título del navegador. Esos valores de cara al público siguen residiendo en cada sitio o traducción de página.

Admin listing rows per page tiene el valor predeterminado 15, admite valores numéricos personalizados como 10 o 12 y solo cambia el número de filas predeterminado que usan las pantallas de listado paginadas de la administración. No afecta a la paginación pública.

CMS Mail usa por defecto la configuración de correo del entorno de Laravel. Cuando el modo se cambia a los ajustes personalizados del CMS, los correos de restablecimiento de contraseña propiedad del CMS y las futuras notificaciones del sistema propiedad del CMS usan los ajustes de correo del CMS almacenados en la base de datos mediante un mailer del CMS con alcance propio. Los campos de correo personalizados solo se muestran cuando está seleccionado el modo de correo personalizado del CMS. Los ajustes de correo personalizados del CMS no sobrescriben .env; desactivar el correo personalizado del CMS devuelve el correo del CMS a la configuración MAIL_* existente de Laravel. Los secretos de correo almacenados nunca se muestran en texto plano, las actualizaciones con el secreto en blanco conservan el valor almacenado y los diagnósticos informan de los campos sensibles únicamente como configurados o no configurados. Los diagnósticos de SMTP personalizado avisan ahora cuando los ajustes de envío requeridos están incompletos o no son válidos, y los fallos de envío del correo de restablecimiento de contraseña devuelven un error de correo controlado del CMS registrando solo contexto técnico sin secretos. La tabla de diagnósticos incluye una acción Send Test Email para superadministradores que envía un mensaje sencillo del sistema del CMS por la misma ruta del resolvedor de correo del CMS que el correo de restablecimiento de contraseña propiedad del CMS, sin incluir secretos, tokens de restablecimiento ni volcados de configuración en bruto.

Site Clone duplica el contenido propiedad de un sitio de un sitio a otro dentro de la misma instalación.

Utilice Site Clone cuando:

• necesite un segundo sitio dentro de la instalación actual
• quiera duplicar la estructura de páginas, slots, bloques, navegación e idiomas (locales) sin crear antes un paquete de exportación
• quiera que los Shared Slots y las asignaciones de slots de página respaldadas por Shared Slots se muevan junto con el sitio clonado

Site Clone es diferente de Export / Import:

• Site Clone funciona dentro de la instalación actual
• Export / Import sirve para mover un paquete de sitio entre instalaciones
• Tanto Site Clone como Export / Import incluyen Shared Slots, árboles de bloques de Shared Slot, traducciones, referencias de medios y ajustes de Page Layout a nivel de página, y además reasignan los slots de página consumidores a los Shared Slots del sitio de destino en lugar de dejar referencias entre sitios
• Tanto Site Clone como Export / Import incluyen también las site_variables con ámbito de sitio.
• El historial de revisiones de los Shared Slots no se clona, en coherencia con el límite actual de clonación de revisiones de página.

• haya que restaurar una página
• necesite una recuperación editorial dentro de la instalación actual

• el entorno necesite recuperación
• la base de datos o los archivos subidos deban revertirse conjuntamente

• haya que mover un sitio a otra instalación
• necesite un paquete portátil de un sitio

• necesite duplicar un sitio en otro sitio dentro de la misma instalación
• quiera mantener el trabajo dentro del entorno actual

• vaya a aplicar una versión publicada del CMS a la instalación actual

• las actualizaciones, las copias de seguridad, la restauración y las herramientas de transferencia de sitios son funciones de nivel de instalación
• las páginas, los medios, la navegación y el flujo de trabajo editorial son principalmente funciones de contenido con ámbito de sitio
• los usuarios son cuentas de nivel de instalación, aunque algunos roles estén restringidos a los sitios asignados
• el empaquetado de versiones y la preservación de las rutas instaladas son cuestiones distintas: las versiones no incluyen project/, mientras que el contenido de project/ ya instalado se conserva entre actualizaciones