Pourquoi WebBlocks CMS est un package Composer

Lorsqu'un produit Laravel existant a besoin de pages, de navigation, de médias, de localisation et d'un flux de travail éditorial, la première question est souvent formulée comme suit : le CMS doit-il faire partie de l'application ou un service sans interface distinct ?

Ce cadrage ignore une option intermédiaire utile. Un CMS peut s'exécuter dans l'application Laravel sans devenir l'application elle-même.

WebBlocks CMS est distribué sous le nom de package Composer fklavyenet/webblocks-cms. Le choix porte moins sur la commodité de l’installation que sur la propriété. Le package apporte un système de contenu ; l'hôte reste le produit Laravel.

L'installation du package ne transmet pas la racine du projet au CMS. L'hôte est toujours propriétaire de son bootstrap, de son environnement, de sa connexion à la base de données, de son cache, de ses files d'attente, de sa messagerie, de ses tâches planifiées, de son déploiement, de ses sauvegardes, de la racine du document public et du code spécifique au produit.

Il possède également son domaine. Une plateforme d’apprentissage conserve ses cours et ses étudiants. Une application commerciale conserve ses commandes et ses clients. Le CMS peut publier des pages marketing ou de la documentation à côté de ces fonctionnalités, mais il ne doit pas transformer les concepts d'hôte en concepts CMS simplement parce que les deux s'exécutent dans le cadre d'un seul processus.

C'est pourquoi les espaces de noms sont importants. WebBlocks utilise /webadmin ; il ne suppose pas que le /admin de l'hôte appartient au CMS. Les ressources CMS statiques utilisent /cms. Les noms de routes, les vues, les clés de configuration, les tables et les autorisations nécessitent également une propriété claire.

Laravel découvre le fournisseur de services de packages via Composer. Le package enregistre ses routes, ses vues avec espace de noms, ses traductions, ses migrations, ses valeurs de configuration par défaut, ses commandes, ses politiques et ses ressources statiques.

Le résultat est un ensemble de fonctionnalités substantiel (pages, mises en page, blocs, médias, localisation, révisions, Shared Slots, navigation, API de contenu et interface opérateur) sans copier les contrôleurs et modèles CMS dans le répertoire app/ de l'hôte.

Ceci est important lors des mises à jour. Le code appartenant au package a un emplacement canonique. Un fichier CMS supprimé peut disparaître avec un remplacement de package au lieu de persister comme un ancien remplacement au niveau racine. Les fichiers hôtes et les fichiers de package peuvent suivre des cycles de vie de version différents car la propriété est explicite.

Un service headless achète une véritable isolation. Il peut évoluer, se déployer et échouer de manière indépendante, et plusieurs produits peuvent le consommer sur plusieurs piles technologiques. Lorsque ces propriétés sont des exigences, une limite HTTP peut être la bonne.

Il crée également un travail d'intégration. L'authentification, l'autorisation, les aperçus, le routage localisé, l'accès aux médias, l'invalidation du cache, la coordination du déploiement et la gestion des pannes traversent une frontière réseau. Le contenu nécessitant des données d’application nécessite généralement une autre API ou couche de synchronisation.

Un package effectue une transaction différente. Il réutilise le runtime Laravel de l'hôte et peut participer aux mêmes transactions, politiques, routage et déploiement. Pour un produit Laravel avec un propriétaire opérationnel, cela peut être une limite plus simple.

La séparation opérationnelle devrait être rentable. Un service réseau n'est pas automatiquement plus découplé lorsque chaque flux de travail utile dépend toujours d'un lien personnalisé entre le service et le produit.

Le conditionnement sous forme de package Composer a des coûts réels. Le CMS et l'hôte partagent un processus PHP, un solveur de dépendances, une version Laravel et un serveur de base de données. Les routes, les middlewares, les configurations, les tables, les hypothèses d'authentification et les chemins publics peuvent entrer en collision si les limites sont conçues avec négligence.

La propriété du schéma nécessite également de la discipline. Les migrations de packages peuvent créer des tables CMS, mais elles ne doivent pas déduire la propriété d'une table hôte existante, car un nom correspond. Les installations partielles nécessitent une détection et une réparation explicite, et non des suppositions destructrices.

Les utilisateurs sont un bon exemple. Un hôte partagé peut utiliser une table users pour l'identité tandis que l'accès CMS est représenté par des rôles CMS et des attributions de site. Un administrateur hôte n’est pas automatiquement un super administrateur CMS, et l’inverse est également vrai. La réutilisation de l'identité ne doit pas faire échouer deux systèmes d'autorisation.

Il ne s'agit pas d'arguments contre le modèle de package. Ils constituent le travail nécessaire pour le rendre réel.

Un test pratique détecte de nombreuses erreurs d'architecture : imaginez installer le package dans un produit Laravel sans rapport.

Verrait-il un itinéraire, un chemin d'accès d'actif, un domaine, un enregistrement de départ ou une définition d'application qui appartient uniquement à l'hôte d'origine ? Le CMS exigerait-il que l'hôte adopte son URL d'administration ou sa chaîne de construction frontend ? Une mise à jour écraserait-elle le contenu ou la configuration appartenant au site ?

Si la réponse est oui, la fonctionnalité a probablement dépassé les limites du package.

WebBlocks applique la même règle aux applications exécutables. Le noyau du CMS fournit un modèle générique de registre et d'autorisation ; les véritables définitions d'application hôte appartiennent à la base de données ou au référentiel de cette installation. Le package ne doit pas introduire clandestinement les conventions du système de fichiers d'un client dans chaque consommateur.

Installer avec Composer ne devient une promesse architecturale que lorsque la propriété reste claire après l'installation :

• l’hôte possède l’application Laravel et les opérations ;
• le package possède le code CMS réutilisable ;
• les contenus du site et les personnalisations appartiennent à l’installation ;
• les données métier de l’hôte restent ses données métier ;
• l’authentification peut être partagée, tandis que l’autorisation reste limitée à son périmètre ;
• la capacité de publication ne devient pas implicitement une autorité de déploiement.

Cette promesse est la raison pour laquelle WebBlocks CMS est un package. Le but n'est pas de faire ressembler chaque application Laravel à des WebBlocks. Il s’agit d’ajouter une publication structurée à une application qui doit rester reconnaissablement sienne.

Choisissez un service distinct lorsque des opérations indépendantes, une réutilisation entre piles ou une isolation de sécurité justifient les limites du réseau. Choisissez un package lorsque le contenu et le produit nécessitent une intégration étroite et qu'un environnement d'exécution Laravel est un avantage plutôt qu'un inconvénient.

Quelles responsabilités devez-vous séparer et lesquelles deviennent plus difficiles lorsque vous le faites ?