Cómo gestiona WebBlocks CMS los recursos frontend
WebBlocks CMS incluye recursos de navegador listos para servir y al mismo tiempo mantiene CSS y JavaScript propiedad del sitio en un espacio de nombres explícito e independiente.
WebBlocks CMS envía el CSS y JavaScript requeridos por su espacio de trabajo de administración y renderizadores públicos como activos de paquete listos para servir.
La versión de CMS contiene sus archivos de navegador. El instalador los publica en el directorio público de la aplicación host Laravel, donde el servidor web los entrega como archivos estáticos.
WebBlocks CMS incluye y mantiene su tiempo de ejecución de JavaScript como parte del lanzamiento del paquete.
Los límites de los activos de un vistazo
WebBlocks CMS separa los recursos de su navegador en tres capas de propiedad explícita:
- Los activos principales de CMS se encuentran bajo
public/cmsy cambian con la versión de CMS. - Las anulaciones a nivel de sitio se encuentran en
public/site/{site_handle}/css/site.cssypublic/site/{site_handle}/js/site.js. - Los recursos a nivel de página pueden hacer referencia a CSS o JavaScript local
/site/...aprobado para una necesidad específica de una página más específica.
Los caminos hacen visible la propiedad. Un archivo con el nombre /cms pertenece a la versión del producto. Un archivo bajo /site/{site_handle} pertenece a esa instalación y sitio.
Qué envía el paquete
WebBlocks CMS mantiene los activos de tiempo de ejecución propiedad de CMS bajo el espacio de nombres public/cms. El instalador del paquete y la etiqueta de publicación webblocks-cms-assets copian los activos rastreados del paquete en la raíz del documento público del host.
Los estilos de administración, los estilos de representación pública, los activos de marca de producto y los comportamientos de JavaScript enfocados pertenecen a la versión de CMS que los utiliza. Se publican y prueban con el código PHP.
Las URL públicas siguen siendo URL estáticas normales. Laravel no necesita transmitir cada hoja de estilo o script a través de un controlador. El servidor web puede servir archivos existentes directamente, mientras que Laravel maneja las rutas de la aplicación.
Esto también explica por qué /cms es un espacio de nombres de activos en lugar de una ruta de administración. La interfaz del operador se encuentra bajo /webadmin; Mantener la propiedad de la ruta y la propiedad del sistema de archivos separadas evita colisiones try_files en implementaciones comunes de Nginx.
Los activos principales y las anulaciones de sitios son productos diferentes
WebBlocks CMS proporciona un límite de extensión independiente para ajustes visuales propios de la instalación.
La configuración de bloque nativo y los tokens WebBlocks UI manejan la presentación normal. Las anulaciones de sitios están reservadas para composiciones específicas de la instalación que pertenecen a ese sitio.
La republicación de activos de CMS reemplaza los archivos propiedad del paquete y al mismo tiempo conserva las anulaciones propiedad del sitio. Las correcciones al núcleo de CMS se entregan a través de versiones de CMS.
Cómo WebBlocks CMS ofrece comportamiento frontend
WebBlocks CMS incluye JavaScript para sus flujos de trabajo de administración y mejora progresiva pública.
El HTML renderizado por el servidor sigue siendo la base. Los scripts enfocados mejoran la navegación, la visualización de medios, la búsqueda, los modales y los flujos de trabajo de edición. Los archivos JavaScript con nombre se cargan con defer; Los renderizadores públicos no ocultan el arranque de aplicaciones dentro de scripts en línea arbitrarios.
El proceso de lanzamiento de WebBlocks CMS posee compatibilidad del navegador, accesibilidad, ordenación de activos, invalidación de caché e interacciones entre esos scripts.
WebBlocks CMS posee y versiona los recursos del navegador requeridos por su tiempo de ejecución.
Cómo los activos estáticos se mantienen actualizados
WebBlocks CMS versiona los activos orientados al navegador para que los archivos almacenados en caché se mantengan actualizados.
Los diseños de CMS añaden un valor de versión a las URL de activos propiedad del paquete, normalmente en función de la hora de modificación del archivo instalado. Los activos de anulación a nivel de sitio utilizan un hash de contenido. Cuando un archivo cambia, su URL cambia, por lo que el navegador solicita la nueva representación en lugar de reutilizar una copia obsoleta en caché.
El paquete también fija su tiempo de ejecución WebBlocks UI en una ruta local versionada. El navegador no necesita una CDN de terceros activa para representar la interfaz del CMS, y la versión del CMS identifica la versión de la interfaz de usuario con la que se probó.
Lo que debe garantizar la versión CMS
Un modelo de activos enviados otorga al CMS responsabilidades concretas:
- los cambios de origen deben confirmarse como archivos de tiempo de ejecución revisables;
- el proceso de liberación debe verificar que todos los activos requeridos estén presentes;
- las actualizaciones de paquetes deben sincronizar las copias en tiempo de ejecución de forma segura;
- La personalización profunda de la interfaz necesita anulación explícita o contratos de complementos.
Para el núcleo WebBlocks CMS, la compatibilidad del navegador y la integridad de los activos pertenecen a la versión del paquete. La presentación específica del sitio sigue siendo propiedad de la instalación y está separada del núcleo del CMS.
¿Qué parte de este límite de activos le gustaría inspeccionar primero: publicación, invalidación de caché o anulaciones de sitios?