Coexistence

Ce document décrit comment WebBlocks CMS doit coexister avec un autre produit hôte Laravel au sein de la même application. Il consigne uniquement l'orientation d'architecture ; il n'implémente à lui seul aucune modification de routes, de configuration, de migrations, de modèles, de contrôleurs, d'installateur, d'inscription, d'invitation ou d'authentification.

WebBlocks CMS peut fonctionner comme CMS autonome : le CMS possède alors l'expérience d'administration principale, le rendu du site public et les opérations de contenu de l'application.

WebBlocks CMS peut aussi être installé à côté d'un autre produit hôte Laravel. Dans ce modèle, le produit hôte conserve ses propres responsabilités produit tandis que le CMS fournit un comportement optionnel de gestion de site web et de contenu.

Dans les installations en coexistence, le CMS est une couche optionnelle de site web et de contenu. Il ne doit pas s'approprier les décisions de domaine du produit hôte, son autorisation ni ses routes d'administration.

Le CMS doit rester package-first et éviter toute collision avec les routes de l'application hôte, les clés de configuration, les espaces de noms de vues, la propriété des tables et les autres frontières au niveau de l'application.

L'installation du package doit être reprenable sur des hôtes partagés. Avant d'exécuter de nouvelles migrations du CMS, webblocks:install détecte un état partiel des tables du CMS et signale les tables existantes, le nombre de lignes, les lignes de migration correspondantes et les conflits de clés étrangères connus. Les tables partielles vides du CMS ne peuvent être renommées que via l'option explicite de l'installateur --repair-partial. Les tables non vides exigent une revue manuelle et ne doivent pas être supprimées, renommées ni considérées automatiquement comme appartenant au CMS.

Le préfixe d'administration du CMS doit être configurable.

Pour les installations en coexistence, le préfixe d'administration du CMS recommandé est /webadmin. L'application hôte peut posséder /admin, et le CMS ne doit pas supposer que /admin est toujours disponible ou lui appartient. Le segment de chemin /cms est réservé aux ressources statiques du CMS, telles que /cms/css, /cms/js et /cms/brand.

Les installations autonomes utilisent désormais /webadmin comme préfixe canonique d'administration du CMS. La documentation, la conception et les travaux d'implémentation à venir doivent séparer clairement le comportement actuel et l'orientation à plus long terme d'un préfixe configurable.

Les préfixes d'administration du CMS ne doivent jamais réutiliser le segment d'un répertoire physique de ressources publiques. En version v1.32.56, le préfixe canonique d'administration est passé à /webadmin parce que try_files de Nginx peut résoudre /cms/ comme le répertoire physique public/cms/ avant que Laravel ne voie la route. /cms doit rester réservé aux ressources : n'ajoutez pas d'alias ni de redirections d'administration sous /cms appartenant au CMS, et ne rétablissez pas de routes /admin appartenant au CMS.

La solution finale évite entièrement la collision route/système de fichiers au lieu de s'appuyer sur un relais public/cms/index.php ou sur un pont de contrôleur frontal. public/cms/index.php doit rester absent aussi bien des ressources publiques racine que des ressources publiques du package.

Les pages publiques utilisent le path de la traduction de page comme URL canonique et peuvent inclure des chemins comportant des barres obliques, comme /docs/internal-content-api. Les catchall des pages publiques doivent continuer à laisser /webadmin, /webadmin/api, /cms, /search, /search.json, /contact-messages, /install et les routes d'authentification de l'hôte à leurs fichiers de routes respectifs. /p/... relève uniquement de la compatibilité héritée et ne doit pas être généré comme nouvelle URL canonique.

Les routes d'administration du CMS dans le navigateur utilisent /webadmin, tandis que /webadmin/api est réservé aux API JSON protégées par jeton. Les URL de ressources doivent être prévisibles :

• collection : /webadmin/{resource}
• création : /webadmin/{resource}/create
• édition : /webadmin/{resource}/{id}/edit
• action sur un élément : /webadmin/{resource}/{id}/{action}
• action sur la collection : /webadmin/{resource}/{action}

L'aperçu de page est une action sur un élément : GET /webadmin/pages/{page}/preview. N'ajoutez pas de routes d'aperçu de page du CMS sous /admin, /cms, /webadmin/api, /webadmin/pages/preview/{page} ou /webadmin/preview/pages/{page}.

Les aperçus d'administration authentifiés doivent garder le routage public séparé. Ils peuvent afficher du contenu appartenant à la page à l'état de brouillon ou en revue pour les utilisateurs autorisés du CMS, mais la route publique de la page doit continuer à n'exposer que les pages publiées et le contenu public publié.

Au sein d'un hôte Laravel partagé, la connexion et l'inscription relèvent de l'application hôte. La table partagée users constitue la couche d'identité et de connexion.

Le CMS ne doit pas exiger une identité utilisateur dupliquée dans les applications co-installées. Lorsque les routes d'authentification du CMS fournies par le package sont actives, les redirections d'invité de l'administration du CMS et les écrans d'authentification du CMS doivent utiliser la route /webadmin/login appartenant au CMS, avec le nom de route webblocks.auth.login, au lieu du nom de route global login, car le produit hôte peut posséder login pour des chemins tels que /quiztem/login. Les hôtes qui remplacent intentionnellement l'authentification du CMS peuvent conserver leur propre flux de connexion, mais les vues et middlewares CMS du package doivent rester sur des noms de route appartenant au package.

L'authentification prouve seulement qu'un utilisateur est connecté. Elle n'accorde pas l'accès au CMS.

L'autorisation du CMS doit être décidée par le système d'appartenances et de rôles du CMS. Le statut de super admin du CMS ne fait pas de l'utilisateur un administrateur du produit hôte, et le statut d'administrateur du produit hôte n'en fait pas un super admin du CMS.

La table users est la couche d'identité dans un hôte Laravel partagé. L'accès au CMS est représenté par des enregistrements d'appartenance ou de rôle appartenant au CMS, et non par la création d'un second utilisateur pour la même personne.

Les conceptions d'installateur, d'inscription et d'invitation du CMS ne doivent pas créer de lignes users dupliquées pour la même adresse e-mail.

Les flux d'installateur, d'invitation et d'inscription qui accordent l'accès au CMS doivent suivre cette séquence :

1. Rechercher un utilisateur hôte existant ayant la même adresse e-mail.
2. Réutiliser cet utilisateur lorsqu'il existe.
3. Créer un nouvel utilisateur uniquement lorsqu'aucun utilisateur hôte correspondant n'existe.
4. Ajouter l'enregistrement d'appartenance ou de rôle du CMS une fois l'enregistrement d'identité résolu.

Le statut de super admin est une attribution d'appartenance ou de rôle du CMS, et non un type particulier d'enregistrement users.

Le routage courant en coexistence doit être conçu autour d'une propriété clairement définie :

• /login -> identité et connexion de l'hôte
• /admin -> administration du produit hôte, lorsque celui-ci en possède une
• /webadmin -> administration de WebBlocks CMS, recommandée pour les installations en coexistence
• /webadmin/login -> connexion CMS appartenant au package, lorsque les routes d'authentification CMS du package sont actives
• /webadmin/forgot-password et /webadmin/reset-password/{token} -> écrans de réinitialisation de mot de passe CMS appartenant au package, lorsque les routes d'authentification CMS du package sont actives
• /cms/... -> ressources statiques de WebBlocks CMS
• routes du site public -> rendu public du CMS, lorsque le CMS possède le contenu public de la requête

Les installations autonomes du CMS utilisent /webadmin pour les routes d'administration appartenant au CMS, les réglages de préfixe configurable demeurant une orientation future.

Les vues d'authentification du CMS appartenant au package doivent utiliser des routes d'authentification préfixées CMS pour les écrans appartenant au CMS : webblocks.auth.login, webblocks.auth.logout et les noms existants webblocks.auth.password.*. Si l'ensemble de routes d'authentification du package ne fournit pas d'inscription au CMS, la connexion CMS doit omettre le lien Register plutôt que de pointer vers une route /register racine appartenant à l'hôte.

L'implémentation actuelle utilise /webadmin comme préfixe canonique d'administration du CMS et n'expose pas intentionnellement de comportement d'administration du CMS via /admin ou /cms.

L'orientation cible reste un préfixe d'administration du CMS configurable, avec /webadmin par défaut, afin qu'un produit hôte puisse conserver /admin pour sa propre zone d'administration et que les ressources du CMS puissent rester sous /cms.

Tant que l'implémentation n'a pas rattrapé son retard, la documentation et les conceptions doivent indiquer explicitement si elles décrivent le comportement actuel ou l'architecture cible.

• Ce document ne rend pas le CMS responsable de l'autorisation du produit hôte.
• Ce document n'exige pas que les produits hôtes dépendent du CMS.
• Ce document n'implémente pas à lui seul de modifications de routes ou de migrations.