Coexistencia

Este documento describe cómo WebBlocks CMS debe coexistir con otro producto anfitrión Laravel dentro de la misma aplicación. Solo registra la dirección arquitectónica; por sí mismo no implementa cambios en rutas, configuración, migraciones, modelos, controladores, instalador, registro, invitaciones ni autenticación.

WebBlocks CMS puede funcionar como CMS autónomo, en cuyo caso el CMS es el propietario de la experiencia de administración principal, de la representación del sitio público y de las operaciones de contenido de la aplicación.

WebBlocks CMS también puede instalarse junto a otro producto anfitrión Laravel. En ese modelo, el producto anfitrión conserva sus propias responsabilidades de producto mientras el CMS aporta un comportamiento opcional de gestión de sitio web y de contenido.

En instalaciones de coexistencia, el CMS es una capa opcional de sitio web y contenido. No debe apropiarse de las decisiones de dominio del producto anfitrión, de su autorización ni de sus rutas de administración.

El CMS debe seguir siendo package-first y evitar colisiones con las rutas de la aplicación anfitriona, las claves de configuración, los espacios de nombres de vistas, la propiedad de las tablas y otros límites de nivel de aplicación.

La instalación del paquete debe poder reanudarse en anfitriones compartidos. Antes de ejecutar migraciones nuevas del CMS, webblocks:install detecta un estado parcial de las tablas del CMS e informa de las tablas existentes, del número de filas, de las filas de migración coincidentes y de los conflictos de claves foráneas conocidos. Las tablas parciales vacías del CMS solo pueden renombrarse mediante el indicador explícito del instalador --repair-partial. Las tablas no vacías requieren revisión manual y no deben eliminarse, renombrarse ni tratarse automáticamente como propiedad del CMS.

El prefijo de administración del CMS debe ser configurable.

Para instalaciones de coexistencia, el prefijo de administración del CMS recomendado es /webadmin. La aplicación anfitriona puede ser propietaria de /admin, y el CMS no debe dar por hecho que /admin esté siempre disponible o le pertenezca. El segmento de ruta /cms está reservado para los recursos estáticos del CMS, como /cms/css, /cms/js y /cms/brand.

Las instalaciones autónomas usan ahora /webadmin como prefijo canónico de administración del CMS. La documentación, el diseño y el trabajo de implementación futuro deben mantener claramente separados el comportamiento actual y la dirección a más largo plazo de un prefijo configurable.

Los prefijos de administración del CMS nunca deben reutilizar el segmento de un directorio físico de recursos públicos. En la versión v1.32.56 el prefijo canónico de administración pasó a /webadmin porque try_files de Nginx puede resolver /cms/ como el directorio físico public/cms/ antes de que Laravel vea la ruta. /cms debe seguir siendo exclusivamente para recursos: no añada alias ni redirecciones de administración bajo /cms pertenecientes al CMS, ni restaure rutas /admin pertenecientes al CMS.

La solución final evita por completo la colisión entre ruta y sistema de archivos en lugar de apoyarse en un traspaso mediante public/cms/index.php o en un puente de controlador frontal. public/cms/index.php debe seguir ausente tanto de los recursos públicos raíz como de los recursos públicos del paquete.

Las páginas públicas usan el path de la traducción de página como URL canónica y pueden incluir rutas con barras, como /docs/internal-content-api. Los catchall de páginas públicas deben seguir dejando /webadmin, /webadmin/api, /cms, /search, /search.json, /contact-messages, /install y las rutas de autenticación del anfitrión a sus propios archivos de rutas. /p/... existe únicamente por compatibilidad heredada y no debe generarse como nueva URL canónica.

Las rutas de administración del CMS en el navegador usan /webadmin, mientras que /webadmin/api queda reservado para las API JSON protegidas por token. Las URL de recursos deben ser predecibles:

• colección: /webadmin/{resource}
• creación: /webadmin/{resource}/create
• edición: /webadmin/{resource}/{id}/edit
• acción sobre un elemento: /webadmin/{resource}/{id}/{action}
• acción sobre la colección: /webadmin/{resource}/{action}

La vista previa de página es una acción sobre un elemento: GET /webadmin/pages/{page}/preview. No añada rutas de vista previa de páginas del CMS bajo /admin, /cms, /webadmin/api, /webadmin/pages/preview/{page} ni /webadmin/preview/pages/{page}.

Las vistas previas de administración autenticadas deben mantener separado el enrutamiento público. Pueden representar contenido propiedad de la página en estado borrador o en revisión para usuarios autorizados del CMS, pero la ruta pública de la página debe seguir exponiendo únicamente páginas publicadas y contenido público publicado.

Dentro de un anfitrión Laravel compartido, el inicio de sesión y el registro son responsabilidad de la aplicación anfitriona. La tabla compartida users es la capa de identidad e inicio de sesión.

El CMS no debe exigir una identidad de usuario duplicada en aplicaciones coinstaladas. Cuando las rutas de autenticación del CMS incluidas en el paquete están activas, las redirecciones de invitado de la administración del CMS y las pantallas de autenticación del CMS deben usar la ruta /webadmin/login propiedad del CMS, con el nombre de ruta webblocks.auth.login, en lugar del nombre de ruta global login, porque el producto anfitrión puede ser propietario de login para rutas como /quiztem/login. Los anfitriones que sustituyan intencionadamente la autenticación del CMS pueden seguir teniendo su propio flujo de inicio de sesión, pero las vistas y el middleware del CMS del paquete deben permanecer en nombres de ruta propiedad del paquete.

La autenticación solo demuestra que un usuario ha iniciado sesión. No concede acceso al CMS.

La autorización del CMS debe decidirse mediante el sistema de pertenencias y roles del CMS. La condición de superadministrador del CMS no convierte al usuario en administrador del producto anfitrión, y la condición de administrador del producto anfitrión no convierte al usuario en superadministrador del CMS.

La tabla users es la capa de identidad en un anfitrión Laravel compartido. El acceso al CMS se representa mediante registros de pertenencia o de rol propiedad del CMS, no creando un segundo usuario para la misma persona.

Los diseños de instalador, registro e invitación del CMS no deben crear filas users duplicadas para la misma dirección de correo electrónico.

Los flujos de instalador, invitación y registro que conceden acceso al CMS deben seguir esta secuencia:

1. Buscar un usuario anfitrión existente con la misma dirección de correo electrónico.
2. Reutilizar ese usuario cuando exista.
3. Crear un usuario nuevo solo cuando no exista ningún usuario anfitrión coincidente.
4. Añadir el registro de pertenencia o de rol del CMS después de resolver el registro de identidad.

La condición de superadministrador es una asignación de pertenencia o de rol del CMS, no un tipo especial de registro users.

El enrutamiento habitual en coexistencia debe diseñarse en torno a una propiedad clara:

• /login -> identidad e inicio de sesión del anfitrión
• /admin -> administración del producto anfitrión, cuando el producto anfitrión tiene una
• /webadmin -> administración de WebBlocks CMS, recomendada para instalaciones de coexistencia
• /webadmin/login -> inicio de sesión del CMS propiedad del paquete, cuando las rutas de autenticación del CMS del paquete están activas
• /webadmin/forgot-password y /webadmin/reset-password/{token} -> pantallas de restablecimiento de contraseña del CMS propiedad del paquete, cuando las rutas de autenticación del CMS del paquete están activas
• /cms/... -> recursos estáticos de WebBlocks CMS
• rutas del sitio público -> representación pública del CMS, cuando el CMS es propietario del contenido público de la petición

Las instalaciones autónomas del CMS usan /webadmin para las rutas de administración propiedad del CMS, con los ajustes de prefijo configurable como dirección futura.

Las vistas de autenticación del CMS propiedad del paquete deben usar rutas de autenticación con prefijo del CMS para las pantallas propiedad del CMS: webblocks.auth.login, webblocks.auth.logout y los nombres existentes webblocks.auth.password.*. Si el conjunto de rutas de autenticación del paquete no ofrece registro en el CMS, el inicio de sesión del CMS debe omitir el enlace Register en lugar de apuntar a una ruta /register raíz propiedad del anfitrión.

La implementación actual usa /webadmin como prefijo canónico de administración del CMS y no expone intencionadamente comportamiento de administración del CMS a través de /admin ni de /cms.

La dirección objetivo sigue siendo un prefijo de administración del CMS configurable, con /webadmin como valor predeterminado, de modo que un producto anfitrión pueda conservar /admin para su propia área de administración y los recursos del CMS puedan permanecer bajo /cms.

Hasta que la implementación se ponga al día, la documentación y los diseños deben indicar explícitamente si describen el comportamiento actual o la arquitectura objetivo.

• Este documento no hace al CMS responsable de la autorización del producto anfitrión.
• Este documento no exige que los productos anfitriones dependan del CMS.
• Este documento no implementa por sí mismo cambios de rutas ni de migraciones.