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 contiene la descripción general consolidada junto con las herramientas operativas existentes:

• Salud del sistema
• Reconstrucción del índice de búsqueda
• Copias de seguridad
• Limpieza
• Exportación / Importación
• Actualización

Desde CMS 1.98.0, Mantenimiento → Estado del sistema proporciona un lugar para revisar la instalación y sus sitios. Para los usuarios con acceso a System Health, el Panel muestra un resumen compacto de las comprobaciones que necesitan acción, que vale la pena revisar o que aún no se han verificado, con un enlace a la descripción general completa. Los recuentos cero muestran que no se encontraron problemas en los cheques disponibles. La página comienza con los recuentos y los elementos más urgentes, seguidos de tarjetas para Sistema, Sitios, Copias de seguridad, Trabajo programado, Almacenamiento, Búsqueda, Complementos y Actualizaciones. Cada elemento explica el siguiente paso y enlaza con la herramienta existente. Los detalles técnicos, los resultados recientes de la copia de seguridad/restauración/actualización y los valores de información del sistema existentes se pliegan de forma predeterminada.

La tarjeta Notificaciones programadas incluye el aviso detallado del programador, el efecto en el correo electrónico pendiente, UTC tiempos para el último latido programado y la ejecución de notificación completa, instrucciones de configuración y un enlace a la guía de instalación. Los enlaces de Revisión de programación abren esta sección y mantienen el filtro del sitio seleccionado. Los administradores de operaciones del sitio que no pueden acceder al Estado del sistema conservan la tarjeta del Programador detallada y específica del sitio en su Panel de control y en la configuración de Contactos del sitio. El resumen de la bandeja de entrada de notificaciones del Panel permanece en el Panel.

Los estados distinguen entre correcto, requiere revisión, urgente, aún no verificado y no aplicable. Una comprobación no disponible no se presenta como correcta. Las comprobaciones de búsqueda comparan los pares de página e idioma publicados aptos con la cobertura del índice; no certifican la actualidad del texto. Las comprobaciones de copias cubren los registros recientes satisfactorios y la disponibilidad de los archivos; no certifican la integridad de la restauración. La preparación para actualizar es independiente de la salud de la instalación, y la disponibilidad de versiones utiliza un resultado reciente de actualización almacenado en caché. Abra Actualizaciones para solicitar una nueva comprobación de versiones.

Las comprobaciones del sitio se almacenan en caché durante cinco minutos; la pantalla Estado del sistema lee la evidencia registrada del programador en cada visita. Panel, Copias de seguridad y Limpieza muestran el último informe completado con su tiempo de medición. No analizan la copia de seguridad SQL al abrir. Los informes faltantes no están verificados y los informes antiguos o invalidados se marcan explícitamente como obsoletos. La configuración permanece disponible antes del primer informe. Las pestañas Almacenamiento e historial y Acciones de limpieza de Cleanup explican los informes no disponibles y ofrecen comprobaciones de actualización directamente; una actualización regresa a la misma pestaña. El botón de actualización muestra la actividad durante el envío y el resultado confirma la finalización, informa que ya se está ejecutando otra actualización o muestra un mensaje de error. Las actualizaciones del estado del sistema conservan el filtro del sitio seleccionado.

Las entradas de la caché del informe de mantenimiento contienen matrices versionadas y valores escalares, por lo que las instalaciones pueden mantener desactivada la deserialización de objetos de la caché. Las comprobaciones de actualización confirman el éxito solo después de leer la instantánea exacta que escribió. Un error de verificación de caché muestra un error e intenta conservar el informe completo anterior; Las decisiones de retención faltantes en las copias de seguridad se muestran como vistas previas no disponibles en lugar de requisitos de actualización del esquema. Después de una actualización de producto, el primer informe para esa versión lo generan las comprobaciones de actualización o el programador.

El planificador Laravel ejecuta php artisan system:reports:refresh cada cinco minutos. Las comprobaciones de actualización sobre el estado del sistema también pueden ejecutar este trabajo manualmente. Cada invocación valida como máximo ocho archivos de respaldo del piso de recuperación existentes y luego actualiza el informe compartido; una instalación grande puede necesitar varias invocaciones para finalizar la validación inicial. Validación de registros de nuevas copias de seguridad y cargas cuando se crean. La validación pendiente retiene la elegibilidad de limpieza en el informe del panel. Se necesita un programador que funcione para la actualización automática; abrir una página no inicia una actualización sincrónica. Los informes almacenados en caché nunca reemplazan las comprobaciones de seguridad actuales realizadas antes de la limpieza o restauración. El último informe completado se conserva durante un máximo de siete días y se muestra obsoleto después de cinco minutos. El filtro de sitio limita las comprobaciones relacionadas con el sitio y al mismo tiempo conserva las comprobaciones de toda la instalación. La descripción general no ejecuta la limpieza, reconstruye la búsqueda, inicia copias de seguridad, instala actualizaciones ni crea evidencia del programador. Los sitios existentes y las páginas de mantenimiento operativo permanecen disponibles. Desde CMS 1.98.1, se eliminan la pantalla separada Información del sistema y el enlace de la barra lateral; sus nueve campos de información de tiempo de ejecución permanecen en Estado del sistema → Detalles del sistema y /webadmin/system/information redirige a Estado del sistema con el mismo requisito de acceso al sistema. La ayuda es un enlace de documentación directo a https://cms.webblocksui.com/docs; Los destinos de complementos que anteriormente contribuyeron a la Ayuda permanecen accesibles en Sistema.

El endpoint de solo lectura de la API interna es GET /webadmin/api/system/health, con el parámetro opcional site_id. Requiere la capacidad system-health.read otorgada explícitamente a un token de sistema sin restricciones cuyo creador activo tenga acceso al Sistema en ese momento. Los tokens personales y limitados a sitios no pueden leer la salud de toda la instalación. Las respuestas utilizan mensajes controlados y resultados normalizados en lugar de textos de excepciones, registros de operaciones, rutas de archivos o secretos de plugins. Consulte API interna de contenido para conocer el contrato de respuesta.

Visitor Reports proporciona resúmenes operativos de la actividad de la página pública. Los registros básicos de vistas de página no requieren identificadores basados ​​en consentimiento. Los registros incluyen información reducida 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.

Desde CMS 1.105.26, el cuadro de diálogo de progreso muestra una fase actual traducida mientras se confirma la ejecución. Su título identifica la versión de destino sin implicar que el trabajo aún se esté ejecutando una vez finalizado. Cuando el seguimiento se detiene o el resultado se vuelve terminal, la fase, el indicador de progreso y el aviso de espera desaparecen juntos; el tiempo transcurrido y el resultado permanecen visibles. El éxito confirmado vuelve a Actualizaciones automáticamente. Los resultados de fallas o de la copia de seguridad restaurada permanecen disponibles para su revisión. Los identificadores de fase desconocida utilizan un respaldo legible en lugar de una clave de traducción.

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 en la aplicación es de un clic. Una sola acción Update to X descarga el paquete de versión, realiza una copia de seguridad previa a la actualización automática, aplica reglas de ruta protegida, ejecuta las migraciones de actualización de paquetes requeridas, borra los cachés, verifica la versión del código WebBlocks CMS aplicado con la versión de destino, registra la ejecución de la actualización y conserva la versión instalada. Si la aplicación falla, el actualizador restaura automáticamente la copia de seguridad previa a la actualización y registra la ejecución con el estado restored; Si la restauración automática también falla, la ejecución se registra como failed con ambos rastros de error. Para la recuperación manual, la copia de seguridad previa a la actualización permanece en la pantalla Copias de seguridad para descargarla y restaurarla, y php artisan system:backup:restore realiza una restauración CLI.

Maintenance → Cleanup posee políticas de retención para toda la instalación. Los controles del ciclo de vida a continuación están disponibles en CMS 1.105.12.

Las políticas guardadas existentes, incluida la retención de seguridad de restauración de 30 días, permanecen sin cambios. La protección por antigüedad y recuento se aplican juntas. Sólo los archivos físicos distintos, estructuralmente validados y disponibles cuentan para el número mínimo de archivos exitosos válidos de un tipo. Una copia de seguridad caducada puede permanecer protegida por ese recuento mínimo. Los archivos fallidos o faltantes no reemplazan los puntos de recuperación válidos. Las copias de seguridad en ejecución y los puntos de recuperación asociados con actualizaciones recientes fallidas o restauradas permanecen protegidos.

Utilice el ícono de bloqueo/configuración en Copias de seguridad para administrar el indicador Protegido de un archivo y su modo policy, never o expires. La protección bloquea la eliminación única, forzada y masiva hasta que se elimina. El modo indefinido evita la caducidad automática pero aún permite la eliminación explícita. Al elegir una fecha, se opta explícitamente por la limpieza de ese archivo, incluidos los archivos manuales y cargados; todavía se aplican la protección y los conteos mínimos exitosos. Las fechas siguen la zona horaria de la aplicación. El cuadro de diálogo de creación manual registra la protección/retención seleccionada antes de capturar SQL.

El presupuesto opcional se mide en GiB (1024³ bytes), no se establece de forma predeterminada, advierte en el 80% e informa un exceso en el 100%. Nunca anula la protección o la retención. Las copias de seguridad y la limpieza muestran el almacenamiento físico total, los bytes protegidos explícitamente, los bytes elegibles, el almacenamiento estimado después de la limpieza y cualquier exceso restante. Los archivos no registrados cuentan para el uso del disco, pero nunca se seleccionan automáticamente. Las medidas parciales/no disponibles son explícitas. Un archivo compartido no se cuenta varias veces y al eliminar un registro nunca se desvincula el archivo de otro registro.

Explicación del almacenamiento (CMS 1.105.13): la tarjeta de retención de copia de seguridad en la pestaña Almacenamiento e historial de Limpieza y la lista de Copias de seguridad agregan una tabla de motivos. Muestra recuentos de registros de respaldo, recuentos distintos de archivos físicos y bytes medidos para protección de recuento mínimo, períodos de retención, protección explícita, retención indefinida, limpieza manual deshabilitada y otras decisiones actuales. Los archivos elegibles aparecen por separado. Las reglas de antigüedad y de recuento mínimo protegen las copias de seguridad; “mantener el último N” es un mínimo, no un límite, en el número total retenido.

Los archivos compartidos contribuyen con bytes una vez según el primer motivo aplicable de la tabla. Los recuentos de registros siguen el estado de cada registro, por lo que un motivo puede tener registros sin bytes físicos adicionales. Otros archivos en el almacenamiento de respaldo, incluidos los archivos de bloqueo o de soporte, aparecen por separado y nunca se eliminan automáticamente. Un análisis parcial muestra tamaños de archivos conocidos con totales no confirmados y otros tamaños de archivos marcados como no disponibles. La limpieza de respaldo existente API incluye el mismo desglose en preview.overview.reason_summary.

La limpieza de la copia de seguridad se ejecuta diariamente en 03:30 bajo la configuración habilitada existente. El paquete no invoca la limpieza de la copia de seguridad después de una actualización exitosa; Se requiere un programador de host que funcione para su ejecución automática. Vista previa con php artisan system:backups:cleanup --dry-run -v; la ejecución normal utiliza la misma política. --force omite sólo la configuración habilitada. Nunca pasa por alto la protección, los recuentos mínimos ni las operaciones activas. La invocación del programador agrega --scheduled para registrar su fuente. Las vistas previas de solo lectura no crean historial de ejecución ni raíces de disco; Las ejecuciones completadas registran un resultado limitado SQL con bytes eliminados reales.

Un contrato de arrendamiento común de sistema de archivos sin bloqueo serializa la creación, carga, restauración, cambios de retención y eliminación de copias de seguridad. Sobrevive a la restauración SQL y se libera al salir del proceso. Los sistemas de archivos de copias de seguridad compartidas deben admitir bloqueos de archivos de aviso. Se requieren migraciones de paquetes actuales. El mantenimiento de restauración repara el esquema de resumen/retención aditiva cuando una instantánea anterior SQL es anterior a él.

La API interna mantiene GET/PUT /webadmin/api/system/backup-cleanup con backups.read / backups.settings.write y el POST destructivo /webadmin/api/system/backup-cleanup/run con backups.delete. Los campos originales siguen siendo obligatorios; los campos opcionales de ciclo de vida modifican solo los valores enviados y conservan los omitidos. Un valor null en budget_gb elimina el presupuesto. GET/PUT /webadmin/api/system/backups/{backup}/retention lee o establece protección y caducidad con las mismas capacidades separadas de lectura y escritura de ajustes. Consulte el contrato de descubrimiento de la API para los campos obligatorios y modos válidos. La copia a almacenamiento remoto queda para una fase posterior.

El espacio de trabajo de limpieza muestra recuentos de archivos físicos y bytes para copias de seguridad del sistema, paquetes de exportación/importación, cargas públicas excluyendo variantes generadas, variantes generadas, espacios de trabajo temporales conocidos, archivos de revisión de activos, archivos públicos del sitio y registros de aplicaciones estándar. Las mediciones tienen una marca de tiempo y distinguen los directorios faltantes, los escaneos parciales y el almacenamiento no disponible. No miden la cuota de alojamiento ni las tablas de bases de datos asignadas. Se excluyen las ubicaciones de registros personalizados; Las raíces de discos compartidos pueden hacer que las categorías se superpongan, por lo que no las agregue a una cifra de cuota para toda la instalación. Los tamaños de revisión por sitio existentes describen las cargas útiles de instantáneas lógicas por separado. Se muestra explícitamente una vista previa de limpieza no disponible.

Las cinco categorías son asset-revisions, media-variants, temporary-workspaces, page-revisions y shared-slot-revisions. Las revisiones de recursos conservan por defecto al menos 90 días de historial y las últimas 20 revisiones por recurso. Los espacios temporales usan un plazo predeterminado de 24 horas. Las revisiones de páginas y Shared Slot conservan al menos 90 días y las últimas 50 por propietario; también se protegen las fuentes de restauraciones de revisiones activas. Los originales de la biblioteca multimedia y las huellas de variantes vigentes nunca pueden seleccionarse para limpiar variantes. Los archivos de transferencia y los registros siguen bajo gestión del operador.

La edad de revisión y la protección de recuento mínimo se aplican juntas. Por ejemplo, una página con 20 revisiones mantiene todas las 20 incluso si tienen más de 90 días, porque las últimas 50 están protegidas. Se conservan las políticas guardadas explícitas, incluida la retención de 365 días; sólo el respaldo para una configuración no configurada cambia a 90 días. Guardar la configuración actualiza la elegibilidad y el siguiente trabajo programado habilitado puede aplicarla.

De CMS 1.105.25, Política de retención agrupa los cronogramas de categorías, la retención de copias de seguridad y la retención de revisión/espacio de trabajo en tablas responsivas. Retención significa un umbral de antigüedad más el recuento mínimo protegido, no un recuento máximo de copias de seguridad. La inclusión de la copia de seguridad manual y el presupuesto de almacenamiento siguen siendo controles separados; un presupuesto nunca anula la protección. Los valores guardados existentes se conservan durante la actualización y después de errores de validación.

El enlace Configuración y verificación del programador abre una pantalla autorizada de solo lectura con comandos específicos de la instalación y evidencia de latidos registrados. Admite alojamiento estándar cron sin Herne, además de configuración opcional confirmada CLI para la cuenta de la aplicación. Consulte configuración del programador . Agregar una entrada cron no es prueba de ejecución. Actualice después de 1–2 minutos para verificar la actividad real; La limpieza aún se ejecuta según el cronograma que se muestra en la tabla.

El espacio de trabajo utiliza pestañas nativas para Almacenamiento e historial, Retención y automatización, y Acciones de limpieza. La configuración utiliza grupos con nombre WebBlocks UI con campos de edad/recuento emparejados, sin marcos de conjunto de campos/leyenda HTML. Las redirecciones de validación/acción conservan el panel correspondiente. Las acciones de engranaje de Historial retenido abren la pestaña de configuración en la política de revisión relevante, y su acción ocular abre la administración de paquetes de transferencia. Todos utilizan las acciones de íconos estándar del panel con etiquetas accesibles. Las categorías vacías muestran un estado neutral de "Nada que limpiar"; Las categorías con artículos elegibles conservan el modo de confirmación destructivo existente. La selección automática muestra el tiempo programado propio de cada categoría.

Ejecute las migraciones actuales de instalación o actualización del paquete antes de usar los nuevos resúmenes. Cada categoría guarda únicamente su último resultado manual o programado con inicio, fin, último éxito, recuentos, bytes y errores. Una eliminación parcial solo contabiliza los bytes realmente eliminados. La falta del esquema de resumen bloquea la limpieza; un resumen antiguo de una ejecución en curso se muestra como interrumpido. Las lecturas y simulaciones no generan pruebas de ejecución ni de actividad del programador.

Habilite las categorías programadas individualmente en Mantenimiento → Limpieza. Las nuevas banderas están desactivadas de forma predeterminada. Los cronogramas diarios ejecutan revisiones de activos en 04:00, variantes de medios obsoletos en 04:10 y espacios de trabajo temporales en 04:20. La limpieza de páginas y revisiones Shared Slot se realiza los domingos a las 04:30 y 04:45. Los horarios siguen la zona horaria de programación de la aplicación. El host debe ejecutar Laravel Scheduler y usar un caché compartido con bloqueos atómicos cuando operan varios trabajadores. La poda de revisión de escritura de activos existente aún se aplica después de los cambios de activos, incluso cuando su programación diaria adicional está desactivada. La limpieza de la copia de seguridad existente tiene su política y cronograma separados.

La limpieza temporal cubre ejecuciones de actualización de marca de tiempo reconocidas/UUID y ejecuciones temporales de copia de seguridad/restauración abandonadas en storage/app/temp/system-backups y storage/app/temp/system-backup-restores. Cada entrada anidada debe ser anterior al umbral de retención. El valor predeterminado sigue siendo 24 horas; No es necesario bajarlo para recuperar obra abandonada. Se conservan la identidad de la instalación, los archivos o nombres de ejecución desconocidos, las carpetas de copia de seguridad y recuperación del actualizador, los árboles con enlaces simbólicos y los archivos de copia de seguridad superpuestos o las cargas públicas. El uso físico incluye archivos retenidos, por lo que el almacenamiento medido puede ser distinto de cero sin ningún candidato elegible.

El historial de actualizaciones obsoleto running/pending por sí solo ya no bloquea la limpieza. Las admisiones recientes, los nuevos latidos del corazón, los trabajos de operador en cola y los bloqueos de actualizaciones retenidos reales aún protegen el trabajo. Los arrendamientos de procesos de copia de seguridad/restauración también protegen las operaciones cuya instantánea de base de datos ya dice completed. La eliminación retiene ambos arrendamientos operativos y vuelve a verificar la edad y la identidad del árbol; no reescribe el historial de actualizaciones. Si el latido del arrendamiento no se puede escribir ni volver a leer, la limpieza se detiene de forma segura. Las descargas de catálogos utilizan arrendamientos de archivos durante la instalación; sólo son elegibles los archivos temporales vencidos y desbloqueados catalog-plugin-. Otros archivos en ese directorio no están seleccionados. La limpieza temporal automática sigue siendo una opción explícita por instalación en Retención y automatización; habilitarlo no cambia el límite de edad ni las otras banderas de categoría.

El último formulario se ejecuta solo si el mantenimiento automático está habilitado para esa categoría. Utilice cualquiera de los cinco nombres de categoría para el argumento de categoría. Un ensayo nunca elimina archivos ni escribe un resumen de ejecución; Los comandos devuelven un error cuando la limpieza o su vista previa no se pueden completar.

El Interno API expone GET y PUT /webadmin/api/system/cleanup a través de maintenance.read y maintenance.settings.write, además de los destructivos POST /webadmin/api/system/cleanup/{category}/run a maintenance.delete. Los campos de retención existentes siguen siendo obligatorios en las escrituras de configuración. Los parches de objetos opcionales automatic denominados indicadores de categoría booleana; las banderas omitidas mantienen sus valores. La respuesta de lectura agrega mediciones físicas y los resultados más recientes en overview.storage_report y overview.automation. Se rechazan las banderas desconocidas y los valores no booleanos. Una ejecución fallida devuelve ok: false y un recuento de errores en lugar de afirmar que la limpieza fue exitosa.

La disponibilidad de la actualización se basa en que la última versión publicada sea más reciente que la versión del código CMS en ejecución. Las ejecuciones históricas de actualizaciones fallidas y los valores de versiones instaladas almacenadas obsoletas permanecen inspeccionables a través de los detalles de ejecución modal y ejecución retenida CLI, pero no hacen que una instalación actual sea procesable por sí mismas.

La pantalla es una tarjeta de estado única. Cuando hay una actualización compatible disponible, muestra la ruta de la versión actual a la más reciente, un área de registro de cambios plegada What's new, la acción de un clic Update to X con una nota de copia de seguridad y un aviso de copia de seguridad del servidor que se vincula a la pantalla Copias de seguridad para que los operadores realicen una copia de seguridad completa y nueva antes de una actualización importante. Cuando no hay ninguna actualización disponible, muestra un mensaje silencioso actualizado con la versión instalada y la hora de la última verificación.

Los superadministradores tienen un shell indicador de actualización asíncrona en la barra superior de administración. Está oculto de forma predeterminada, verifica el estado de actualización de forma asincrónica y se vuelve visible solo cuando hay disponible una versión confiable más nueva.

La preparación de verificación previa es una lista de verificación explícita de pasa/falla en la pantalla: conexión de base de datos, extensiones ZIP y sodio PHP, ejecución de proceso PHP/Composer, acceso de escritura a la raíz de la aplicación y al espacio de trabajo de actualización, y espacio libre en disco. La acción de actualización está disponible solo cuando se superan todas las comprobaciones y ninguna otra ejecución de actualización mantiene el bloqueo.

El historial de actualizaciones muestra las ejecuciones retenidas como un acordeón cerrado; cada ejecución abre su registro en un modal y la eliminación de filas no es parte del administrador UI. Los registros de ejecución de actualización se eliminan automáticamente y se conservan las últimas cinco ejecuciones de forma predeterminada. La última ejecución fallida se conserva hasta que exista una ejecución exitosa más nueva. Los operadores con acceso a la terminal pueden inspeccionar los registros retenidos con php artisan webblocks:updates:runs, php artisan webblocks:updates:runs --last o php artisan webblocks:updates:runs --failed y pueden ejecutar una poda controlada con php artisan webblocks:updates:prune-runs --keep=5.

El cliente de actualización admite metadatos estructurados del servicio de actualización, incluidos título, resumen, aspectos destacados, correcciones, notas de compatibilidad, notas de migración, notas de activos, notas de operador y notas técnicas, además de entradas acumulativas del registro de cambios por versión para el acordeón What's new. La preparación de la versión nativa CMS deriva un resumen y aspectos destacados de la sección de la versión coincidente CHANGELOG.md y agrega metadatos técnicos específicos de la versión, por lo que la tarjeta de la versión debe describir la versión publicada real en lugar de marcadores de posición repetidos del flujo de trabajo de publicación. Estos valores se representan como texto sin formato con escape. Las versiones más antiguas que solo proporcionan release_notes aún muestran esas notas limpiamente, y las versiones sin notas muestran No release notes were provided for this release.

La sincronización del catálogo enviado se ejecuta automáticamente como un paso de mayor esfuerzo de la cadena de aplicación de actualización (webblocks:catalog-repair --all); una falla de sincronización no impide la ejecución de la actualización y se puede reparar manualmente después.

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, --plugin-block-types, --slot-types, --page-layouts, --icons y --all. Informa de las filas creadas, actualizadas, sin cambios y omitidas, conserva las filas del catálogo personalizado específicas de la instalación y se puede ejecutar repetidamente. block-types:sync-core permanece como un comando de compatibilidad de nivel inferior para el catálogo de tipos de bloques.

--plugin-block-types escribe una fila de catálogo para cada tipo de bloque declarado por un complemento instalado, habilitado o no, para que el bloque se pueda colocar en el editor; Los bloques de un complemento deshabilitado aún se filtran de los selectores mediante PluginBlockCatalog. Las acciones del ciclo de vida del complemento (instalar, habilitar, deshabilitar, configurar, actualizar) ya ejecutan esta sincronización a través de PluginRuntimeRefresher, por lo que el alcance es una ruta de reparación en lugar de la normal. Una resincronización corrige las columnas propiedad del complemento (name, description, source_type, is_system, is_container) y deja deliberadamente category, sort_order y status solas, por lo que la curación del operador (volver a tabular un bloque, reordenarlo o configurarlo como borrador para ocultarlo) sobrevive a la reparación.

Los paquetes de versión publicados contienen el tiempo de ejecución reutilizable CMS: fuente, activos públicos, migraciones, vistas, rutas, configuración, archivos de idioma y códigos auxiliares de instalación. Las pruebas de desarrollo, los scripts, los metadatos del repositorio, la configuración local, las fuentes de documentación y el contenido del proyecto específico de la instalación están excluidos del archivo de distribución. La documentación canónica se mantiene en su repositorio independiente.

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

release:push envía la rama de lanzamiento y la etiqueta anotada a origin en una sola inserción de Git, por lo que el conjunto de validación previa a la inserción se ejecuta una vez. Luego refleja las referencias verificadas en backup sin volver a ejecutar ese gancho. release:prepare construye el paquete ZIP, la suma de comprobación y la carga útil Publisher a partir del compromiso HEAD; requiere un árbol limpio, una versión fuente coincidente, la etiqueta v{VERSION} anotada exacta y un inventario revisado con la procedencia de la documentación coincidente.

Ejecute las comprobaciones locales y verifique las confirmaciones de lanzamiento GitHub CI antes de publicar. release:publish-update -- --dry-run valida el artefacto y la configuración sin cargarlos. El comando de publicación real requiere autenticación GitHub CLI, firma y carga el artefacto en Publisher, verifica los metadatos del canal estable y publica o actualiza la versión GitHub coincidente. Publisher sigue siendo la fuente de actualización de la instalación; una versión GitHub por sí sola no publica el canal de actualización CMS. Si se interrumpe una respuesta, inspeccione ambos estados de publicación antes de volver a intentarlo.

La publicación del mantenedor requiere WEBBLOCKS_PUBLISHER_TOKEN y WEBBLOCKS_PUBLISHER_SIGNING_KEY, cargados durante la ejecución desde la configuración del mantenedor establecida. No copie estas credenciales en una instalación o documentación CMS. Los sitios instalados utilizan los valores predeterminados del servidor de lanzamiento, del producto y del canal estable propiedad del paquete; Las instalaciones normales no necesitan Publisher configuración del entorno del servidor o del canal. El antiguo puente updates.webblocksui.com es histórico y no es una ruta de configuración activa.

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 de formularios de contacto se guardan antes de la entrega de la notificación. El estado de las notificaciones por correo electrónico refleja únicamente el comportamiento de las notificaciones y no cambia la clasificación editorial. Sent significa que Laravel aceptó el envío a través de un transporte de correo real configurado sin excepción; no garantiza la entrega por bandeja de entrada. Failed significa que un intento de notificación real arrojó una falla de desinfección. Skipped o Not configured significa que no se produjo ningún envío real. Los envíos válidos se califican como permitidos, en cuarentena o spam; la cuarentena y el spam se retienen para su revisión y se suprimen las notificaciones. Una prueba firmada no válida, un campo de verificación generado completo o un envío por debajo del tiempo mínimo estricto siguen al éxito genérico sin almacenamiento. El resumen continuo de protección cuenta solo las solicitudes que alcanzaron la puntuación. Consulte Protección de envíos públicos para conocer señales, umbrales, límites de privacidad y ajustes.

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. Revise los totales de protección de 30 días y corrija los falsos positivos a través del estado.
6. Ejecute php artisan contact:mail-diagnose --block=ID si la resolución del destinatario no está clara.
7. 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
• CMS cargas administradas desde storage/app/public, excluyendo archivos regenerables media/transforms/ en nuevas copias de seguridad
• archivos públicos del sitio de public/site
• 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

Nuevo registro de copias de seguridad excluded_upload_paths: ["media/transforms/"] en su manifiesto de versión uno. Las imágenes originales, los archivos adjuntos y otras cargas permanecen en el archivo. Las variantes generadas se reconstruyen cuando el renderizador las necesita después de la restauración; los códecs ausentes vuelven al original. Reconstruir todas las variantes por adelantado es opcional; consulte Variantes de imágenes multimedia. Los archivos antiguos y antiguos de la versión uno se pueden restaurar, incluidas las variantes almacenadas en caché cuando estén presentes. Las copias de seguridad en el mismo segundo tienen nombres de archivo distintos, por lo que el archivo de seguridad previo a la restauración no puede sobrescribir su fuente.

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
• zona horaria, que es la predeterminada para toda la instalación y la alternativa para cualquier sitio que no establezca su propia
• 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

Visitor Reports ahora deriva un gráfico de tiempo, una comparación de períodos anteriores de igual duración, cobertura de mediciones y modales de detalles de página de los registros existentes. No agrega scripts públicos, cookies, identificadores, eventos ni transferencias de terceros. Las decisiones de consentimiento existentes siguen gobernando la recopilación de identificadores.

• Los gráficos llenan los días faltantes con cero vistas registradas. Los rangos superiores a 90 días utilizan depósitos de varios días del mismo tamaño, etiquetados en el gráfico y en la tabla de valores accesible, abiertos con el botón de valores del gráfico en un modal WebBlocks UI. Las fechas utilizan el mismo calendario de aplicación/base de datos que los informes existentes.
• El período anterior finaliza inmediatamente antes del período seleccionado. Un total anterior cero no tiene cambio porcentual. Los períodos que incluyen fechas actuales o futuras se denominan provisionales. Los recuentos describen registros retenidos, no prueba de que el seguimiento estuviera continuamente activo o de que un período histórico vacío no tuviera visitantes.
• La cobertura es la proporción de vistas con un identificador utilizable basado en el consentimiento en los registros detallados conservados. no es una tasa de aceptación del consentimiento. Las estimaciones de visitantes/sesiones describen este subconjunto y no son recuentos verificados de personas.
• El estado de seguimiento muestra el último registro detallado dentro del alcance del sitio seleccionado accesible, independientemente de la fecha, la ubicación y los filtros de tráfico. No afirma que el programador se esté ejecutando o que la ausencia de registros demuestre una falla de seguimiento.
• Las filas de contenido abren WebBlocks UI modales con totales de página/sitio/localización y desgloses independientes de dispositivos/referentes. Se oculta un desglose completo si algún grupo tiene menos de cinco vistas, evitando la resta directa de una celda suprimida. Esta es una protección de visualización, no una garantía de anonimización. No se añaden viajes individuales. Los diez grupos más grandes se muestran cuando hay un desglose disponible.

El informe sigue el contrato de barra de filtro etiquetado WebBlocks UI, con métricas resumidas encima del gráfico y pestañas de informe detalladas debajo. La cobertura de medición, el estado de seguimiento, el contexto de privacidad y la política de retención están disponibles en la modalidad Información del informe. Las migraciones faltantes, la limpieza deshabilitada y los avisos de registros archivados permanecen visibles en el informe mismo.

El gráfico utiliza el componente WebBlocks UI 2.26.0 wb-chart incluido y la tabla modal visitor-chart-data como fuente. Los atributos numéricos contienen recuentos sin formato; las celdas visibles conservan el formato localizado. UI posee SVG dibujo, ejes, cambio de tamaño e interacción con el teclado; CMS mantiene consultas, permisos, privacidad y agregación. No se introduce ninguna biblioteca de cartas externa ni colección de visitantes adicionales.

El paquete registra visitors:cleanup diariamente en el Programador 03:45 a Laravel. El host debe ejecutar su programador normal; ninguna solicitud pública realiza la limpieza. El comando programado y el comando manual comparten un bloqueo de caché atómico. Utilice una caché compartida con capacidad de bloqueo cuando programe en varios servidores.

Estos son valores predeterminados del producto, no requisitos de retención legales ni una certificación de cumplimiento legal. Los propietarios de sitios pueden elegir períodos más cortos para sus propósitos. Las instalaciones existentes con un programador en funcionamiento comienzan a aplicar esta política después de instalar la nueva migración y el código. No hay ninguna eliminación dentro de la propia migración.

Vista previa y ejecución local en el host:

La limpieza se ejecuta incluso cuando la recopilación de nuevas visitas está deshabilitada. La desactivación de la recopilación no debe dejar los identificadores históricos almacenados indefinidamente. La desactivación de la limpieza se muestra en el informe. Las migraciones resumidas faltantes bloquean la limpieza sin eliminar registros y dejan operativos los informes existentes.

Los registros caducados se reemplazan transaccionalmente, un día a la vez, con filas en wbcms_visitor_daily_totals: sitio, ubicación (cero para desconocido), día, vistas totales y vistas de bot. No retienen la ruta de la página, la referencia, la campaña, el dispositivo, el tiempo exacto de visita, IP hash o el identificador de sesión. Los registros tardíos se fusionan una vez con los totales existentes. Los registros anteriores al horizonte de retención total, los registros sin fecha y los registros vencidos cuyo sitio se eliminó se descartan sin un resumen. Al eliminar un sitio también se eliminan sus totales diarios. Las copias de seguridad existentes tienen su propio ciclo de vida de retención; este comando no reescribe los archivos de respaldo.

Los totales principales, el gráfico y la comparación combinan los detalles retenidos con los totales diarios y preservan la autorización del sitio más los filtros de sitio/localización/tráfico. Los totales de bots incluyen ambas fuentes. Las tablas detalladas y las métricas de sesión utilizan únicamente los registros detallados restantes; un aviso explícito explica la diferencia cuando un período incluye resúmenes. Las visitas o sesiones únicas diarias no se suman deliberadamente entre días. El informe nunca reconstruye los historiales de los visitantes a partir de los resúmenes conservados.

Tanto las instalaciones nuevas como las migraciones de actualizaciones de instalaciones existentes crean la tabla de totales. Ejecute el flujo normal de migración/actualización de paquetes antes de habilitar la limpieza programada. Las nuevas cadenas de información se envían en inglés y turco; otras configuraciones regionales de administración utilizan el inglés normal cuando no está disponible una traducción detallada.