Transition vers l'architecture en paquet

WebBlocks CMS est actuellement livré sous la forme d'une application Laravel gérée depuis la racine, où les fichiers du cœur du CMS se trouvent directement à la racine de l'installation, aux côtés des fichiers applicatifs appartenant à l'utilisateur. Ce modèle rend les mises à jour fragiles, car le code produit du CMS et le code de projet propre à l'installation partagent le même système de fichiers de premier niveau.

Lorsque les mises à jour du CMS sont appliquées en remplaçant ou en copiant des fichiers gérés depuis la racine, rien ne garantit que les fichiers du cœur supprimés en amont disparaissent des installations en aval. Un fichier du cœur supprimé mais obsolète peut subsister à la racine de l'installation, continuer d'être autochargé ou rendu par Laravel et écraser silencieusement le comportement livré plus récent. C'est exactement la catégorie de problème récemment confirmée par un fichier Blade obsolète à la racine d'une installation en aval.

L'architecture actuelle maintient également les mises à jour du CMS étroitement couplées à l'état de Git et à la synchronisation des fichiers sur toute la racine. Il est donc plus difficile de raisonner sur les frontières de propriété, de préserver sans risque les personnalisations propres à l'installation et de rendre les mises à jour prévisibles sur les installations existantes.

L'architecture cible est un paquet Laravel géré par Composer :

• Nom du paquet : fklavyenet/webblocks-cms
• Chemin d'installation : vendor/fklavyenet/webblocks-cms
• Source de vérité canonique du paquet installé : vendor/fklavyenet/webblocks-cms

Dans le modèle cible, le code du cœur du CMS est installé et mis à jour comme un paquet Composer normal, au lieu d'être copié à la racine du projet Laravel appartenant à l'utilisateur.

Cela signifie que :

• le code source PHP du CMS appartient au src/ du paquet
• les ressources du paquet Laravel restent dans les config/, database/, resources/, routes/, public/ et stubs/ du paquet
• src/ n'est pas la destination de chaque fichier du paquet
• la racine Laravel appartenant à l'utilisateur devrait posséder app/, config/, database/, public/site/, resources/, routes/, storage/ et composer.json

System Update doit s'aligner sur cette organisation de paquet Composer. Chez les consommateurs natifs du paquet installé, l'updater applique les artefacts de version enracinés dans le paquet à vendor/fklavyenet/webblocks-cms ; il ne doit pas conserver packages/webblocks-cms comme seconde copie d'exécution active et mise à jour. Une arborescence packages/webblocks-cms n'appartient qu'aux copies de développement maintenues depuis les sources ou aux vestiges hérités de la transition.

Lorsqu'une installation vendor Composer héritée a la forme d'un dépôt, System Update normalise vendor/fklavyenet/webblocks-cms vers la racine plate du paquet. Après normalisation, src/, docs/, routes/, resources/, database/, public/, config/ et stubs/ se trouvent directement sous vendor/fklavyenet/webblocks-cms ; les vestiges de la racine du dépôt tels que artisan, app/, bootstrap/, packages/, plugins/ et tests/ sont retirés du remplacement de la racine du paquet.

project/ peut subsister temporairement comme couche de compatibilité pendant la transition, mais il ne devrait pas rester à long terme le modèle de personnalisation obligatoire pour le comportement propre à l'installation.

La direction prévue pour le projet de départ est un starter Laravel distinct, tel que fklavyenet/webblocks-cms-starter, où la racine du projet appartenant à l'utilisateur compose le paquet CMS au lieu d'embarquer directement tous les fichiers du cœur du CMS.

La préparation du paquet pour les consommateurs a désormais commencé, mais elle est volontairement partielle et explicite :

• les consommateurs disposant d'une installation Laravel neuve peuvent installer le paquet et exécuter webblocks:install
• le paquet utilise un chemin de migration ciblé pour les installations neuves des consommateurs, au lieu de rejouer toute la chaîne historique de migrations de la racine
• les migrations du paquet du dépôt de maintenance restent désactivées par garde et inertes par défaut
• App\Models\User reste la frontière d'authentification temporaire du consommateur en v1.32.8
• l'installeur du paquet applique automatiquement un correctif à App\Models\User à l'aide d'un trait du paquet et écrit d'abord une sauvegarde horodatée
• la connexion, la déconnexion, l'avis d'installation, la protection de l'administration, la page d'accueil publique, les vues et les ressources appartenant au paquet suffisent désormais au premier parcours consommateur propre
• il ne s'agit toujours pas d'un dépôt starter distinct, et cela ne supprime pas encore la frontière User appartenant à l'application

L'arborescence réelle de l'application consommatrice Composer peut être minimale tant que l'exécution du CMS se charge depuis vendor/fklavyenet/webblocks-cms. Le dépôt de maintenance reflète désormais cette frontière de plus près : le app/ de la racine ne conserve plus par défaut de wrappers correspondant à ceux du paquet.

Catégories de wrappers supprimées :

• les commandes de console correspondant à celles du paquet, à l'exception de ProjectInitCommand, qui appartient à l'hôte
• les contrôleurs d'administration et publics du CMS ainsi que les middlewares correspondant à ceux du paquet dont les routes pointent désormais vers des classes du paquet, à l'exception du middleware de redirection d'installation du shell de maintenance
• les form requests d'administration et publiques correspondant à celles du paquet
• les mailables correspondant à ceux du paquet
• les modèles CMS correspondant à ceux du paquet
• les classes de support correspondant à celles du paquet dans les domaines des blocs, des médias, des pages, des sites, du système, des mises à jour, de la recherche, des visiteurs et du transfert/de la promotion opérationnels

Éléments volontairement encore détenus par la racine ou reportés :

• app/Models/User.php, le Controller.php de base et les service providers restent des fichiers du shell Laravel appartenant à l'hôte.
• les fichiers d'authentification, de profil et d'installation, y compris le middleware de redirection d'installation, restent détenus par l'hôte jusqu'à ce que la frontière starter/installation soit délibérément repensée.
• l'authentification, le profil, l'installation et la couche projet restent des frontières de l'hôte ou de la transition.
• les shims hérités pour les ressources Asset, AssetFolder, BlockAsset et App\Support\Assets\... ont été supprimés ; les modèles média et les classes de support du paquet constituent désormais la surface faisant autorité à l'exécution et pour les tests.
• App\Support\WebBlocks a été supprimé ; la configuration, les vues et les tests de la racine utilisent désormais WebBlocks\Cms\Support\WebBlocks comme source d'identité et de version du produit.
• les répertoires app/ vides de la racine correspondant à ceux du paquet sont supprimés plutôt que conservés comme marqueurs de transition.
• les migrations de la racine, les surcharges de configuration, le public/cms d'exécution, les wrappers de compatibilité Blade de la racine et les wrappers de seeders de la racine restent en dehors de ce nettoyage.

Ce nettoyage améliore la transition vers le paquet et la préparation du starter, car le dépôt de maintenance teste désormais la même hypothèse d'application minimale qu'un nouveau consommateur du paquet. Il ne rend toutefois pas le dépôt pleinement prêt en tant que starter : l'installation/authentification, User, l'autorité des migrations de la racine, l'autorité opérationnelle de mise à jour/d'installation de la racine et les chemins de compatibilité des ressources d'exécution de la racine restent les derniers obstacles.

Le flux de mise à jour à long terme devrait être géré par Composer et le paquet, et indépendant de Git.

L'architecture de mise à jour cible est la suivante :

• aucune copie de fichiers du cœur du CMS sur toute la racine
• cœur du CMS installé et mis à jour via des paquets Composer
• étapes contrôlées de mise à niveau à l'exécution après la mise à jour du paquet, migrations comprises
• vidage du cache lorsque c'est nécessaire
• réparation explicite du catalogue en tant que flux de maintenance distinct de l'opérateur, en cas de besoin
• publication ou synchronisation contrôlée des ressources uniquement lorsque c'est réellement nécessaire

Cela maintient les fichiers de la racine appartenant à l'installation séparés des fichiers du cœur du CMS appartenant au paquet et empêche les fichiers du cœur du CMS supprimés de subsister indéfiniment dans les installations en aval simplement parce qu'ils ont un jour existé à la racine.

Le paquet Composer et le dépôt de maintenance sont des consommateurs de ressources statiques, non des hôtes de chaîne de build frontend. WebBlocks CMS ne doit ni livrer ni exiger Vite, le plugin Vite de Laravel, Tailwind, npm, Node, des fichiers de verrouillage de paquets, public/build, public/hot ou des hooks d'exécution @vite pour les ressources appartenant au CMS.

Les ressources appartenant au CMS ont leur place dans le public/cms de la racine pour l'exécution de maintenance et dans le packages/webblocks-cms/public/cms du paquet pour les artefacts de version. WebBlocks UI reste un projet d'interface en amont, consommé au travers de ressources publiées et épinglées, et WebBlocks UI Manager reste le plugin opérateur first-party pour les flux de publication de versions et de CDN. Ne déplacez pas la compilation des sources de WebBlocks UI, les scripts de build npm, la génération de la dist ou les hypothèses relatives au fichier hot vers le cœur du CMS ou son paquet de version.

Chemins CMS cibles appartenant au paquet :

• packages/webblocks-cms/src/ pendant la phase de transition interne au dépôt
• plus tard vendor/fklavyenet/webblocks-cms/src/ dans les environnements installés
• config/ du paquet
• database/ du paquet
• resources/ du paquet
• routes/ du paquet
• public/ du paquet
• stubs/ du paquet

Chemins cibles de la racine de projet appartenant à l'utilisateur :

• app/
• config/
• database/
• public/site/
• resources/
• routes/
• storage/
• composer.json

Cette répartition laisse la propriété de l'application Laravel à l'installation, tandis que la propriété du produit CMS passe au paquet.

Les installations du CMS orientées paquet doivent préserver les frontières de l'application hôte lorsque le CMS est installé aux côtés d'un autre produit Laravel. Le CMS devrait éviter les collisions de routes, de configuration, de vues et de tables avec l'application hôte, et il ne doit pas supposer que la route /admin de l'application hôte lui appartient.

Le préfixe d'administration canonique du CMS est /webadmin, un préfixe configurable restant la direction cible pour davantage de souplesse de coexistence à l'avenir. La connexion appartenant à l'hôte et les décisions d'autorisation appartenant au CMS sont documentées dans Coexistence. Les ressources statiques du CMS restent sous public/cms et sont servies depuis /cms/....

Lorsque les routes d'authentification du CMS appartenant au paquet sont actives, /webadmin/login fait partie de la frontière du paquet. Sa surface Blade doit rester sous l'espace de noms de vues webblocks-cms::, utiliser le shell d'authentification invité de WebBlocks UI, charger le CSS/JS épinglé de WebBlocks UI ainsi que /cms/css/guest.css, et résoudre les ressources de marque et de logo du produit depuis /cms/brand. Les ressources de marque du produit CMS doivent fournir des variantes normale, pour surface sombre, sur accent/inversée et à contraste élevé pour le favicon et l'onglet du navigateur, afin que le contraste de l'authentification et du shell produit soit résolu par des ressources explicites plutôt que par des filtres CSS.

Les préfixes de routes d'administration ne doivent pas réutiliser des segments physiques de répertoires de ressources publiques. Le préfixe d'administration retiré /cms entrait en collision avec le répertoire de ressources actif public/cms, car try_files de Nginx peut résoudre /cms/ comme un répertoire avant que Laravel ne reçoive la route. L'architecture en paquet actuelle conserve donc /webadmin/... pour l'administration du CMS et les routes de connexion du paquet, réserve /cms/... aux seules ressources statiques et interdit les alias /cms, les redirections /cms et les routes /admin appartenant au CMS qui seraient rétablies. L'ancien relais public/cms/index.php ne fait pas partie de la frontière du paquet et doit rester absent des ressources publiques de la racine comme de celles du paquet.

Présentez le plan d'architecture en paquet et créez un squelette de paquet dans le dépôt sans encore déplacer le code d'exécution. Le comportement de l'application racine reste inchangé.

Ajoutez le service provider du paquet et le câblage Composer par chemin local afin que le paquet existe comme une véritable unité installable dans le dépôt. Gardez la logique d'amorçage volontairement minimale et évitez de modifier le comportement à l'exécution.

Affinez le service provider du paquet afin qu'il définisse le contrat d'amorçage des futures ressources appartenant au paquet, sans encore rendre ces ressources faisant autorité.

Dans cette phase, le provider peut préparer sans risque le chargement protégé et l'enregistrement de publication pour les config/, routes/, resources/views/, database/migrations/, public/ et stubs/ du paquet, mais uniquement lorsque de véritables fichiers du paquet existent.

Le comportement actuel de la racine à l'exécution reste inchangé, car le squelette du paquet ne contient que des espaces réservés. Tant que les fichiers d'exécution ne sont pas réellement déplacés dans le paquet lors des phases ultérieures, l'application Laravel de la racine reste la source faisant autorité pour les routes, vues, configurations, migrations et ressources publiques actives du CMS.

Le premier chemin de configuration par défaut appartenant au paquet a désormais démarré avec le config/webblocks-updates.php du paquet. Pendant la transition, ce fichier du paquet fournit les valeurs par défaut appartenant au CMS, tandis que le config/webblocks-updates.php existant à la racine reste en place comme surcharge au niveau de l'installation et fichier de configuration applicative rétrocompatible.

Les fichiers actuels de config/ à la racine se répartissent en deux groupes de transition.

Candidats aux valeurs par défaut du produit CMS :

• webblocks-cms.php
• cms.php
• contact.php
• demo_media.php
• webblocks-updates.php

Configuration appartenant à l'application Laravel ou à l'installation qui devrait rester détenue par la racine :

• app.php
• auth.php
• cache.php
• database.php
• filesystems.php
• logging.php
• mail.php
• queue.php
• services.php
• session.php

La règle de transition actuelle, à faible risque, consiste à ne déplacer la configuration par défaut appartenant au CMS que lorsque cela préserve un comportement produit stable et une sémantique de surcharge claire pour l'installation. L'ensemble des valeurs par défaut appartenant au paquet comprend désormais webblocks-cms.php, cms.php, contact.php, demo_media.php et webblocks-updates.php. Les fichiers de configuration de la racine relatifs au comportement existant du CMS restent en place pendant la transition, comme surcharges au niveau de l'installation et points d'entrée de configuration applicative rétrocompatibles. webblocks-cms.php est pour l'instant propre au paquet et porte les contrôles de transition : les routes de diagnostic, les routes de statut publiques, les routes de statut d'administration et le chargement des migrations du paquet restent désactivés par défaut, tandis que le chargement des routes d'administration du paquet est activé afin que les routes d'administration appartenant au paquet puissent faire autorité.

Commencez à déplacer le code source PHP appartenant au CMS vers le src/ du paquet par petites tranches examinables, en ne mettant à jour les espaces de noms et l'amorçage du service provider qu'au fur et à mesure que chaque zone déplacée est prête.

L'amorçage console du paquet est désormais également démontré par la commande de diagnostic en lecture seule webblocks:package-status. Cette commande appartient au paquet, n'est enregistrée que dans les contextes console et signale la présence de l'amorçage du paquet sans modifier les fichiers, l'état de la base de données, le cache, la configuration ou l'état de mise à jour.

Le premier déplacement de code source PHP devrait suivre des critères tout aussi prudents : appartenant au CMS, de petite taille, facile à appréhender, sans dépendance à la base de données ni à Eloquent, sans dépendance à un contrôleur ou à une request, et avec des mises à jour de références restreintes. La première classe déplacée est SearchTextNormalizer, un utilitaire pur de texte de recherche désormais détenu par le src/Support/Search/ du paquet.

Frontière actuelle du support de recherche :

• désormais propriété du package : SearchTextNormalizer, PublicSearchRebuildResult, PublicSearchIndexer, PublicSearchQuery, PublicSearchSchema, SearchablePageResolver, BlockSearchTextExtractorRegistry et ReindexesPublicSearch
• aucune classe de support de Search ne doit actuellement rester propriété de la racine pour des raisons propres au projet ; le shim racine App\Support\Search\ReindexesPublicSearch a été supprimé

Limite actuelle de l'audit du Support hors Search :

• aucun autre helper de Support hors Search n'a été déplacé lors de cette étape d'audit, car aucun des candidats examinés ne satisfaisait aux critères actuels de faible risque pour un passage au package
• MediaKindResolver est petit et déterministe, mais il dépend actuellement de constantes de App\Models\Media et il est référencé depuis un chemin de contrôleur ; il n'est donc pas encore assez indépendant pour cette phase
• DatabaseExecutionStrategyResolver reste pour l'instant propriété de la racine, car il affecte directement la stratégie d'exécution des dumps ou restaurations de base de données, l'inspection de l'environnement et la sûreté d'exécution des sauvegardes ou restaurations
• SiteHandle reste pour l'instant propriété de la racine, car il est utilisé par des modèles, des requests et les flux de transfert ou de clonage de site ; le déplacer maintenant franchirait trop tôt les limites de routage, de portabilité et de persistance
• SiteDomainNormalizer reste pour l'instant propriété de la racine, car il est encore utilisé par des modèles, des requests, la résolution de routes et des migrations, ce qui confirme l'évaluation de risque précédente

Limite du support Contact :

• désormais propriété du package : ContactMessageNotificationResult
• propriété de la racine pour l'instant : ContactMessageNotifier, car il porte encore les appels de transport de courrier, l'interaction avec le modèle de contact et la résolution des destinataires basée sur la configuration
• ContactMessageNotificationResult a pu être déplacé sans risque, car il s'agit d'un tout petit objet résultat immuable, sans couplage à des modèles, à la base de données, aux requests, à la configuration, au courrier, aux migrations ou à des charges utiles sérialisées, et n'exigeant qu'une mise à jour de référence limitée dans le notifier

Limite du support des types de blocs :

• désormais propriété du package : BlockTypeContract
• propriété de la racine pour l'instant : BlockTypeContractRegistry, car il dépend encore des modèles de blocs, des définitions de synchronisation du catalogue, du comportement du registre de traductions, de l'inspection des chemins de ressources et des flux d'audit ou d'administration de la racine qui consomment ces contrats résolus
• BlockTypeContract a pu être déplacé sans risque, car il s'agit d'un petit DTO de contrat dont l'état est fixé uniquement par le constructeur, avec une sérialisation en tableau déterministe et sans couplage à des modèles, à la base de données, aux requests, à la configuration, aux effets de bord de commandes, aux migrations ou à des charges utiles sérialisées

Limite du balisage de layout de page :

• propriété de la racine pour l'instant : LayoutMarkup
• LayoutMarkup n'a pas été déplacé lors de cette étape car, bien qu'il soit petit et sans état, il est utilisé directement par les form requests de layout de page, par la logique du gestionnaire de layouts de page, par la résolution du wrapper de slots publics et par un formulaire Blade d'administration ; le déplacer maintenant franchirait les limites de validation des requests et de rendu public au sein du domaine plus large Pages ou PublicRendering, qui reste intentionnellement propriété de la racine

Limite du support de formatage :

• désormais propriété du package : InlineRichTextRenderer
• propriété de la racine pour l'instant : SafeRichTextRenderer, car il porte encore le contrat de nettoyage HTML le plus riche, le comportement des balises autorisées, les règles d'analyse du DOM et la sémantique de rendu public du texte enrichi
• InlineRichTextRenderer a pu être déplacé sans risque, car il s'agit d'un petit formateur déterministe, sans couplage à des modèles, à la base de données, aux requests, à la configuration, aux migrations ou à des charges utiles sérialisées, et n'exigeant qu'une mise à jour de référence limitée dans Blade et dans les tests unitaires

Carte de migration des sources de Support :

• Search : propriété du package pour le support d'exécution actuel, y compris le trait de réindexation utilisé par les modèles du package. Les shims racine App\Support\Search\... ne doivent pas être rétablis.
• Formatting : candidat après isolement des dépendances. InlineRichTextRenderer est désormais propriété du package en tant que helper de formatage à faible risque, tandis que SafeRichTextRenderer reste propriété de la racine car il définit le comportement de nettoyage à risque plus élevé.
• BlockTypes : candidat après isolement des dépendances. BlockTypeContract est un petit objet valeur, mais l'espace de noms est ancré par BlockTypeContractRegistry, par des routes d'administration et par une commande d'audit console à la racine.
• BlockTypes : candidat après isolement des dépendances. BlockTypeContract est désormais propriété du package au titre d'un déplacement limité d'objet valeur, mais l'espace de noms reste ancré par BlockTypeContractRegistry, par des routes d'administration et par une commande d'audit console à la racine.
• Media and Assets : les modèles média et les classes de support appartenant au package font autorité à la place des anciens shims d'assets supprimés. Le travail restant sur les médias doit éviter de rétablir les wrappers racine Asset, AssetFolder, BlockAsset ou App\Support\Assets\....
• Pages and PublicRendering : propriété de la racine jusqu'à une phase de migration dédiée. Ces classes contrôlent la résolution des routes, la sélection du layout, les assets de page, les wrappers de slots, les presenters publics, la duplication ou l'import de pages et le comportement de rendu public, avec un couplage aux modèles et aux requests de bout en bout.
• Pages and PublicRendering : propriété de la racine jusqu'à une phase de migration dédiée. LayoutMarkup a été examiné comme exception possible, mais il reste propriété de la racine car il repose encore directement sur les requests de layout de page, sur la résolution des wrappers de slots et sur le rendu des vues d'administration, même si sa propre logique est sans état.
• Blocks : propriété de la racine jusqu'à une phase de migration dédiée. Ce domaine porte les écritures de payload de blocs, la persistance des traductions, la suppression de blocs, la synchronisation du catalogue, l'extraction de HTML approuvé et les registres publics à portée de request, qui reposent directement sur la persistance des blocs et sur les contrats du renderer.
• SharedSlots and Revisions : propriété de la racine jusqu'à une phase de migration dédiée. Ces classes dépendent des arbres de blocs, des tables de révisions, des contrôles de schéma, des lignes de traduction et de la sémantique de restauration ou d'instantané.
• Sites, Sites\\ExportImport et SitePromotion : propriété de la racine jusqu'à une phase de migration dédiée. Ces domaines sont étroitement couplés aux modèles, au routage, à la portabilité, aux archives, aux charges utiles de transfert sérialisées, aux flux de clonage ou de suppression, aux sauvegardes de sûreté lors de la promotion et à la résolution des sites publics.
• System and System\\Updates : propriété de la racine jusqu'à une phase de migration dédiée. Ces classes portent la persistance des réglages, l'état de la version installée, la sauvegarde ou la restauration, la validation SQL, le flux de téléchargement ou d'extraction des mises à jour et la stratégie d'exécution de la base de données.
• Install and ProjectLayer : ne pas déplacer pour l'instant. Ces classes touchent au flux de l'installeur, aux écritures dans .env, au chargement des routes ou des providers, aux vérifications de l'état d'installation et aux limites de personnalisation de la racine du projet.
• Navigation, Locales, Users, Visitors, Contact and Icons : candidats après isolement des dépendances. Chaque groupe contient quelques helpers ou objets résultat plus petits, mais les implémentations actuelles reposent encore sur des modèles, l'authentification, le courrier, l'inspection de schéma, des appels HTTP ou un comportement d'exécution adossé aux réglages.
• Navigation, Locales, Users, Visitors, Contact and Icons : candidats après isolement des dépendances. ContactMessageNotificationResult est désormais propriété du package au titre d'un déplacement limité d'objet valeur, tandis que les groupes restants reposent encore sur des modèles, l'authentification, le courrier, l'inspection de schéma, des appels HTTP ou un comportement d'exécution adossé aux réglages.
• Admin, Audit and Database : candidats après isolement des dépendances. AdminPagination, CurrentActorResolver et DestructiveDatabaseCommandGuard sont petits, mais chacun dépend encore des réglages de la racine, de l'authentification ou des hooks de sûreté de l'application.
• WebBlocks : WebBlocks\Cms\Support\WebBlocks, propriété du package, est désormais la source d'identité et de version du produit, tant pour les consommateurs du package que pour la racine du dépôt de maintenance.

Note sur le point de contrôle des sources de la phase 2 :

• les premiers déplacements à faible risque de helpers et d'objets valeur se sont achevés correctement jusqu'à v1.31.60
• l'environnement de développement local câblé au package a été mis à jour avec succès après v1.31.60, ce qui confirme que le point de contrôle reste compatible avec le flux de travail local maintenu
• les déplacements opportunistes de sources PHP à faible risque sont désormais volontairement suspendus
• ne poursuivez pas le déplacement de classes fortement liées à l'exécution sans un plan de phase dédié et un audit des dépendances

Blocages actuels pour les groupes à risque plus élevé :

• couplage direct à App\Models\... ou à des requêtes Eloquent dans Search, Pages, Blocks, Sites, Navigation, Locales, Icons, Visitors et System
• couplage aux requests, routes, contrôleurs ou vues dans Admin, Pages, PublicRendering, Formatting et certains helpers de BlockTypes
• vérifications de schéma, de forme des migrations ou d'existence de tables dans Search, SharedSlots, Revisions, Visitors, Install et System
• couplage à la configuration, à l'environnement, à HTTP, au courrier, au système de fichiers, aux processus, aux sauvegardes, aux mises à jour et à l'exécution locale dans Contact, Icons, Install, System et Updates
• couplage à des charges utiles d'archive ou de transfert sérialisées dans Sites\\ExportImport, SitePromotion, l'import de pages et les helpers de compatibilité des anciens assets

Déplacez vers les dossiers de ressources Laravel du package la configuration, les routes, les vues, les migrations, les seeders, les assets publics et les stubs qui appartiennent clairement au package. Introduisez le comportement de chargement et de publication du package de manière incrémentale plutôt que d'un seul coup.

La tranche de seeders actuelle de la phase 3 couvre désormais la limite des seeders de catalogue appartenant au package, ainsi que leur agrégateur appartenant au package :

• désormais propriété du package : CoreCatalogSeeder, IconCatalogSeeder, PageTypeSeeder, LayoutTypeSeeder, SlotTypeSeeder sous packages/webblocks-cms/database/seeders/
• les points d'entrée de compatibilité de la racine restent dans database/seeders/ afin que les installations existantes, les tests et les points d'entrée actuels d'exécution ou de mise à jour puissent continuer d'appeler Database\Seeders\...
• le CoreCatalogSeeder appartenant au package reste un simple transfert de propriété : il délègue toujours à PageLayoutSeeder et BlockTypeSeeder, propriété de la racine, et le DatabaseSeeder racine actuel ainsi que les points d'entrée de mise à jour appellent toujours le wrapper de compatibilité de la racine
• restent propriété de la racine pour l'instant : PageLayoutSeeder, BlockTypeSeeder, DatabaseSeeder et les commandes post-installation actives de System Update
• à cette phase, la propriété des seeders par le package ne concerne que la migration des espaces de noms et des limites, et non un changement de l'autorité de mise à jour actuelle de la racine

Le prochain axe de la transition après v1.31.60 est la propriété des ressources du package, et non de nouveaux déplacements opportunistes de helpers.

Le point de contrôle v1.31.62 transforme la limite des ressources du package en un pilote plus explicite et testable, sans transférer encore la propriété active à l'exécution.

• les répertoires routes/, resources/views/, database/migrations/, public/ et stubs/ du package existent désormais comme répertoires de limite du package explicitement réservés, avec des fichiers marqueurs qui documentent l'intention de propriété future
• les valeurs de configuration par défaut du package restent propriété du CMS, sous le config/ du package
• les fichiers de configuration correspondants à la racine restent la couche de surcharge au niveau de l'installation et les points d'entrée de configuration applicative rétrocompatibles
• le service provider du package conserve une publication explicite et taguée, mais la publication reste inerte tant qu'un développeur n'exécute pas intentionnellement vendor:publish
• l'espace de noms de vues du package webblocks-cms est désormais enregistré comme pilote sûr de limite du package, sans modifier la résolution actuelle des vues d'administration ou publiques de la racine
• les routes, vues, migrations, assets publics et stubs du package ne constituent pas encore une propriété d'exécution faisant autorité à cette phase
• webblocks:package-status signale désormais, de façon strictement en lecture seule, l'état des ressources du package : réservées ou renseignées

Ce pilote ne déplace ni les routes, vues, migrations ou assets publics actifs de la racine, ni les contrôleurs, requests, modèles, services ou le comportement de System Update.

Le point de contrôle v1.31.63 transforme l'espace de noms de vues du package, jusqu'ici réservé, en une limite de diagnostic concrète et testable appartenant au package, sans changer la propriété active à l'exécution.

• le fichier resources/views/diagnostics/package-status.blade.php du package existe désormais comme véritable vue Blade de diagnostic interne appartenant au package
• la vue de diagnostic n'est rendue qu'au travers de l'espace de noms webblocks-cms:: et n'est exposée par aucune route publique ou d'administration
• webblocks:package-status peut désormais exécuter en option --view-check pour rendre cette vue de diagnostic de façon strictement en lecture seule et confirmer que l'espace de noms de vues du package se résout correctement
• la sortie par défaut de webblocks:package-status reste légère et en lecture seule, tandis que la vérification optionnelle de la vue n'effectue toujours aucune écriture de fichier, de cache, de configuration ou de base de données, ni aucun changement d'état d'installation
• les vues d'administration et publiques actives de la racine restent celles qui font autorité, et aucun chemin de vue racine ni aucune propriété de route à l'exécution ne change à cette phase

Ce pilote démontre le chargement de l'espace de noms de vues du package avec un fichier Blade réel appartenant au package, tout en évitant délibérément tout déplacement des vues d'administration ou publiques actives de la racine.

Le point de contrôle v1.31.64 transforme la limite de routes du package, jusqu'ici réservée, en un pilote de route de diagnostic concret et testable, sans changer la propriété active des routes.

• le fichier routes/diagnostics.php du package existe désormais comme véritable fichier de routes de diagnostic appartenant au package, pour de futurs diagnostics internes au package
• le service provider du package maintient le chargement des routes de diagnostic du package explicitement protégé derrière webblocks-cms.diagnostics.load_routes, de sorte que les routes de diagnostic du package ne sont pas chargées par défaut dans l'exécution normale
• webblocks:package-status signale désormais la présence de la limite de routes du package, l'état du fichier de routes du package, l'existence du fichier de routes de diagnostic attendu, l'état protégé du chargement des routes et si la route de diagnostic est actuellement chargée
• les routes d'administration et publiques actives de la racine restent celles qui font autorité, et aucun fichier de routes d'administration ou publiques de la racine n'a été déplacé ou modifié à cette phase

Ce pilote démontre la limite de routes du package avec un fichier de routes de diagnostic réel appartenant au package, tout en évitant délibérément toute migration de la propriété des routes d'administration ou publiques actives.

Le point de contrôle v1.31.65 achève les pilotes de limite du package restants hors exécution pour les migrations, les assets publics, les stubs et la cible du flux de mise à jour géré par Composer, sans déplacer la propriété active à l'exécution.

• les répertoires database/migrations/, public/ et stubs/ du package conservent désormais une documentation plus claire des marqueurs de frontière réservée pour leurs futurs rôles appartenant au package
• le chargement des migrations du package est désormais explicitement désactivé par la garde webblocks-cms.boundaries.load_migrations, de sorte que les migrations du package restent inertes tant qu'une phase de runtime ultérieure et ciblée ne les branche pas intentionnellement
• la publication des assets publics et des stubs du package reste explicite et associée à des tags de package ; elle publie désormais le premier marqueur d'asset appartenant au package et les stubs de démarrage sans remplacer les assets de runtime de la racine ni l'installateur actuel
• webblocks:package-status signale désormais l'état de la frontière des migrations, celui de la frontière des assets publics, celui de la frontière des stubs, la note sur la cible de mise à jour gérée par Composer, ainsi que la règle toujours en vigueur selon laquelle le runtime de la racine reste faisant autorité
• le comportement actuel de Composer à la racine, le chargement du runtime de la racine et le comportement de System Update restent inchangés à ce point de contrôle

Ce point de contrôle achève la phase pilote des frontières de package. Le dépôt dispose désormais de frontières de package concrètes et testables pour les routes, les vues, les migrations, les assets publics, les stubs et l'intention de mise à jour gérée par Composer, tandis que la propriété du runtime actif demeure dans l'application racine.

• choisissez une seule tranche de runtime restreinte, clairement détenue par le package et suffisamment peu risquée pour être déplacée de bout en bout
• ne la déplacez que lorsque les règles de propriété des routes, vues, migrations, assets ou runtime sont explicites pour cette tranche
• vérifiez la rétrocompatibilité et les attentes d'installation avant qu'une quelconque autorité de runtime actif ne passe de la racine au package
• conservez le comportement de System Update inchangé jusqu'à ce qu'une phase ultérieure dédiée au flux de mise à jour le repense intentionnellement

La version v1.32.0 est le premier point de contrôle comportant une tranche de runtime réelle appartenant au package. Elle amorce le travail de runtime détenu par le package avec trois tranches protégées volontairement petites, qui prouvent la propriété du runtime par le package sans déplacer le runtime actuel du CMS.

Phase 1 : tranche de runtime de diagnostic du package, protégée

• le fichier routes/diagnostics.php du package pointe désormais vers un contrôleur appartenant au package situé sous packages/webblocks-cms/src/Http/Controllers/Diagnostics/PackageDiagnosticsController.php
• ce contrôleur restitue la vue de diagnostic existante du package webblocks-cms::diagnostics.package-status
• la route de diagnostic reste désactivée par défaut derrière webblocks-cms.diagnostics.load_routes
• il s'agit intentionnellement d'un chemin interne réservé au package uniquement, qui ne remplace aucune route de runtime d'administration ou publique de la racine

Phase 2A : première tranche ciblée d'administration du package

• le fichier routes/admin.php du package a introduit à l'origine une petite tranche d'état de runtime d'administration appartenant au package : admin.webblocks-cms.runtime-status, désormais montée sur /webadmin/_webblocks-cms/runtime-status
• cette route d'état utilise un contrôleur et une vue Blade appartenant au package, situés sous packages/webblocks-cms/resources/views/admin/runtime-status.blade.php
• le chargement des routes d'administration du package est désormais activé par défaut et l'arbre de routes d'administration actif du CMS est chargé depuis le fichier routes/admin.php du package
• la route réservée d'état d'administration reste elle-même désactivée par défaut derrière webblocks-cms.admin.load_status_route
• les routes d'administration du package conservent, le cas échéant, les exigences habituelles de middleware d'installation, d'authentification, d'accès à l'administration et d'accès système super admin
• la propriété du runtime d'administration actif revient désormais au package pour Pages, Blocks, Media, Shared Slots, Navigation, Block Types, Page Layouts, Sites, Site Domains, Site Variables et Locales, tandis que Users, System, l'installation/mise à jour, la sauvegarde/restauration, l'export/import, la promotion, l'authentification/profil, les migrations et les assets de runtime de la racine restent la propriété de la racine

Phase 2B : première tranche publique ciblée du package

• le fichier routes/public.php du package a introduit à l'origine une petite tranche d'état de runtime public appartenant au package : webblocks-cms.public.runtime-status sur /_webblocks-cms/runtime-status
• cette route utilise un contrôleur et une vue Blade appartenant au package, situés sous packages/webblocks-cms/resources/views/public/runtime-status.blade.php
• le chargement des routes publiques du package est désormais activé par défaut et l'arbre de routes publiques actif du CMS est chargé depuis le fichier routes/public.php du package
• les contrôleurs d'entrée publics appartenant au package gèrent désormais l'accueil, l'accueil localisé, la recherche, la recherche localisée, la recherche JSON, l'affichage de page, l'affichage de page localisé, l'envoi des messages de contact, la synchronisation du consentement de confidentialité et les endpoints internes de domaine admin-api.*
• les vues d'entrée publiques appartenant au package couvrent désormais les modèles d'entrée de page et de recherche via webblocks-cms::public.pages.show et webblocks-cms::public.search.show
• la route réservée d'état public du package reste elle-même désactivée par défaut derrière webblocks-cms.public.load_status_route
• l'autorité de runtime sur les assets publics et les frontières d'installation/mise à jour restent la propriété de la racine en dehors des tranches publiques de route, de modèle, de support et de vue explicitement déplacées vers le package

Pourquoi ces tranches restent partiellement protégées

• le runtime de la racine reste faisant autorité pour les installations en dehors des tranches déplacées intentionnellement vers le package
• les chemins réservés du package évitent les conflits de nom de route et de chemin avec le runtime d'administration et public existant
• les routes d'état protégées séparément permettent de tester le bootstrap du package, le chargement des routes, le chargement des vues, le comportement des middlewares et le rapport d'état sans imposer ces chemins de diagnostic réservés au runtime normal
• l'autorité de runtime déplacée reste intentionnellement partielle, de sorte que les groupes à haut risque comme les modèles, la plupart des classes d'implémentation d'administration, les couches de support plus larges, les migrations, les assets et le comportement de System Update échappent à une propriété prématurée par le package

• ne poursuivez la réduction du chargement de compatibilité des routes à la racine qu'après avoir déplacé, ou intentionnellement laissé à la racine, les implémentations d'administration et publiques restantes situées derrière les fichiers de routes du package
• gardez les routes réservées de diagnostic et d'état de runtime explicitement protégées, même lorsque les arbres de routes d'administration et publiques normaux du CMS font autorité depuis le package
• préservez les noms de routes, les chemins, les middlewares et le comportement des redirections tant que l'autorité de routage du package devance l'extraction plus profonde du runtime
• traitez le futur nettoyage des routes comme une phase de réduction de la compatibilité, et non comme la preuve que le CMS est déjà prêt en tant que package consommable

• ne déplacez de véritables vues appartenant au package que lors de phases de suivi ciblées, regroupées par domaine de runtime : par exemple d'abord le diagnostic détenu par le package, puis une propriété des vues d'administration ou publiques soigneusement auditée
• gardez la propriété des routes et celle des vues alignées, afin qu'une vue déplacée à l'avenir ne soit introduite que lorsque le chemin de runtime propriétaire est intentionnellement géré par le package
• préservez des règles claires de surcharge à l'installation et d'autorité de la racine jusqu'à ce que chaque phase de propriété de route ou de vue soit explicitement conçue et vérifiée

• Le répertoire config/ du package doit continuer à définir les valeurs par défaut appartenant au CMS.
• Le config/ de la racine reste la couche de surcharge appartenant à l'installation pendant la transition.
• Un fichier de configuration du package ne devrait pas faire autorité pour le comportement à l'exécution tant que la logique de surcharge et le câblage du bootstrap ne sont pas explicites et stables.

• Les migrations du package doivent rester non faisant autorité tant que de véritables migrations appartenant au package n'existent pas et que leur propriété n'est pas déplacée intentionnellement.
• Lorsque la propriété des migrations débutera, privilégiez le chargement depuis le package pour les fichiers de migration appartenant au CMS, et des consignes de publication explicites uniquement là où une personnalisation locale à l'installation est réellement nécessaire.
• Ne mélangez pas le travail sur les frontières de migration avec des refactorisations de runtime sans rapport.
• Le répertoire database/migrations/ de la racine reste la couche de compatibilité et d'autorité pour les installations maintenues depuis les sources. Le chemin de mise à jour maintenu depuis les sources exige le signal d'autoload Composer à la racine du dépôt de maintenance pour WebBlocks\\Cms\\ => packages/webblocks-cms/src/ ; il ne suffit pas qu'une installation consommatrice possède un répertoire packages/webblocks-cms. Les mises à jour des installations consommatrices du package doivent utiliser des migrations de mise à jour explicites appartenant au package et ne doivent pas exécuter implicitement les migrations de l'application Laravel hôte.
• Les nouvelles installations consommatrices du package utilisent le schéma database/migrations/fresh appartenant au package via webblocks:install. L'installateur contrôle au préalable les tables CMS partielles avant l'exécution de ce schéma, s'arrête avec un diagnostic par défaut et ne renomme les tables partielles vides que lorsque l'opérateur fournit --repair-partial.
• PageLayoutSeeder et BlockTypeSeeder restent pour l'instant la propriété de la racine, car ils traversent encore le catalogue des page layouts, la synchronisation des block types et des frontières plus larges du runtime de Pages ou Blocks. DatabaseSeeder reste également la propriété de la racine en tant que point d'entrée actif de l'installation et rédacteur de la version installée.

• La propriété des routes par le package est désormais active pour les arbres de runtime d'administration et public du CMS via les fichiers routes/admin.php et routes/public.php du package.
• Le fichier routes/web.php de la racine est maintenant réduit à l'installation, à l'authentification, au profil et au chargement de compatibilité de ces fichiers de routes CMS appartenant au package.
• Les déplacements de routes doivent continuer à préserver les middlewares, les liaisons, les noms, les chemins, les flux modaux, les redirections et les attentes d'installation en aval.
• Les routes de diagnostic, d'état du runtime d'administration et d'état du runtime public demeurent des chemins réservés protégés séparément et ne font pas partie de la surface de routes CMS toujours active.
• L'autorité sur les routes n'implique pas encore une propriété complète du runtime par le package, car de nombreux gestionnaires derrière ces routes dépendent toujours des modèles, du code de support, des vues et des assets de la racine.

• Le répertoire resources/views du package possède désormais la vue de diagnostic, les vues protégées d'état du runtime d'administration et public, les vues d'administration du catalogue d'icônes, la coque de layout public, les coques publiques de page et de recherche, la fenêtre modale de recherche publique et les vues d'entrée de slot appartenant au package.
• Le resources/views de la racine conserve désormais des enveloppes de compatibilité pour les vues déplacées de layout, de page, de slot et d'entrée de recherche publiques, tout en restant faisant autorité pour la plupart des écrans d'administration et pour l'arbre de compatibilité plus large du moteur de rendu public des blocs, qui n'a pas encore été entièrement extrait.
• Les déplacements de vues doivent rester alignés sur le chemin de runtime propriétaire, afin que l'autorité de routage du package ne devance pas trop la couche réelle de vues et de contrôleurs propriétaire.
• Les vues de la racine restent la voie de compatibilité pour la majorité du rendu CMS actif en dehors des surfaces webblocks-cms:: déplacées intentionnellement.

• Le répertoire public/ du package devrait à terme posséder les assets publiables appartenant au CMS.
• Le travail de transition doit distinguer les assets de package appartenant au CMS des surcharges public/site/... appartenant à l'installation.
• La publication ou la synchronisation des assets ne devrait avoir lieu que lorsque de véritables assets de package existent et que le flux de mise à jour définit clairement quand la publication est requise.
• L'intention de publication actuelle reste explicite et associée à des tags de package. public/cms/package-boundary.json est le premier asset publiable appartenant au package et peut être publié via webblocks-cms-assets.
• Le répertoire public/cms/ du package porte désormais aussi le CSS et le JS du layout public utilisés par le layout public déplacé appartenant au package, mais les URL d'assets public/cms/... actuelles de la racine restent faisant autorité dans le runtime actif pour des raisons de compatibilité, tandis que les assets public/site/... appartenant à l'installation restent faisant autorité pour les surcharges par site.
• Le public/cms/ du package ne doit pas contenir de index.php ; l'entrée d'administration du CMS est /webadmin, et non un pont de contrôleur frontal depuis le répertoire d'assets statiques.
• L'épinglage du CDN WebBlocks UI et la source de synchronisation du manifeste d'icônes par défaut restent inchangés à cette phase.

• Le répertoire stubs/ du package doit être réservé aux modèles réutilisables de fichiers générés qui relèvent du comportement du produit CMS.
• L'échafaudage propre à une installation ou à un projet ne doit pas migrer par défaut vers les stubs du package CMS.
• Les stubs orientés démarrage de projet résident désormais sous stubs/starter/ dans le package, mais le comportement actuel de l'installateur et l'échafaudage du projet racine restent faisant autorité jusqu'à ce qu'un package starter dédié les adopte intentionnellement.

• webblocks-cms-config est réservé à la publication, à la racine de l'installation, des fichiers de configuration CMS par défaut appartenant au package, lorsqu'un développeur a intentionnellement besoin de ce flux de travail.
• webblocks-cms-assets publie les assets publics CMS appartenant au package dans le chemin de compatibilité du runtime actif, public/cms.
• webblocks-cms-stubs publie les stubs de démarrage appartenant au package.
• Ces tags ne modifient pas à eux seuls le comportement à l'exécution et restent inertes tant que vendor:publish n'est pas exécuté explicitement.

• La cible à long terme reste des mises à jour de paquet gérées par Composer, suivies d'étapes d'exécution contrôlées.
• Les étapes prévues après mise à jour pourront plus tard inclure des migrations, la synchronisation des types de blocs, le vidage du cache ou la publication ou synchronisation des assets, mais seulement lorsque ces ressources détenues par le paquet seront réelles et intentionnellement câblées.
• L'artefact de publication canonique est désormais la racine du paquet elle-même, et non la racine du dépôt de maintenance. Les ZIP de mise à jour sont valides lorsque la racine de l'archive, ou un unique répertoire d'enveloppe de premier niveau, contient le composer.json du paquet ainsi que la structure src/, config/, resources/, database/, routes/ et public/ attendue par fklavyenet/webblocks-cms.
• L'ancienne forme d'archive d'updater gérée depuis la racine est volontairement abandonnée pour les mises à jour modernes natives au paquet. Elle ne reste valide que comme artefact passerelle explicite pour les installations antérieures au modèle natif au paquet, telles que 1.31.53, dont l'updater ne sait pas encore valider des ZIP à racine de paquet.
• Les métadonnées de publication à racine de paquet doivent exiger un updater capable de servir de passerelle (minimum_client_version de 1.32.18 ou plus récent). Les installations plus anciennes doivent d'abord recevoir la passerelle compatible, puis utiliser l'artefact moderne à racine de paquet une fois que la passerelle a installé la validation et le code d'application natifs au paquet.
• Pendant la transition actuelle, l'application Laravel racine reste détenue par l'installation et continue d'exécuter le mode maintenance, les migrations, les seeders, les commandes de synchronisation, les vidages de cache et la persistance de la version installée depuis la racine d'installation.
• Les mises à jour dans l'application appliquent désormais l'artefact de paquet validé dans packages/webblocks-cms/ et, lorsque l'autoload de Composer montre que l'exécution consommatrice active charge encore WebBlocks\Cms\ depuis vendor/fklavyenet/webblocks-cms/..., dans la racine d'exécution sûre correspondante du paquet vendor. Elles n'écrasent pas le shell racine détenu par l'installation, les surcharges de configuration de la racine, les migrations de la racine, project/, storage/, .env ni public/site/.
• Les archives passerelles gérées depuis la racine ne sont pas un assouplissement de la validation moderne. Une archive passerelle doit conserver l'ancienne forme avec artisan plus le composer.json racine uniquement pour la compatibilité avec les clients hérités, et doit installer un code d'updater capable d'imposer ensuite la forme stricte à racine de paquet de fklavyenet/webblocks-cms.
• Le point de contrôle d'achèvement des limites v1.31.65 n'en fait qu'une note d'objectif. Le comportement actuel de Composer à la racine et le flux de mise à jour à l'exécution font toujours autorité tant que la première véritable portion d'exécution détenue par le paquet n'existe pas.

Flux d'installation cible une fois la séparation paquet-starter prête :

• composer require fklavyenet/webblocks-cms
• la racine Laravel au niveau de l'installation reste responsable de .env, du composer.json racine, de storage/, des surcharges de configuration détenues par l'installation et de toute personnalisation propre à l'installation dans project/ encore présente pendant la transition
• la découverte de paquets doit charger WebBlocks\Cms\WebBlocksCmsServiceProvider
• les diagnostics du paquet tels que webblocks:package-status doivent confirmer que le paquet est prêt sans modifier l'état

Flux de mise à jour cible une fois que les mises à jour de paquet gérées par Composer feront autorité :

• composer update fklavyenet/webblocks-cms
• exécuter les migrations
• vider les caches là où c'est nécessaire
• publier ou synchroniser les assets du paquet uniquement lorsque de vrais assets du paquet l'exigent
• exécuter les diagnostics du paquet tels que webblocks:package-status
• synchroniser l'état de la version installée uniquement lorsque la mise à jour correspond à une véritable limite de publication
• exécuter séparément la réparation explicite du catalogue lorsque les lignes du catalogue livré nécessitent une maintenance

Règle de compatibilité actuelle :

• aujourd'hui, ces notes sur les flux d'installation et de mise à jour ne sont que la documentation de l'état cible
• le comportement actuel de Composer à la racine, le comportement de l'installateur et le comportement de System Update dans l'application font toujours autorité tant qu'une phase ultérieure dédiée au flux de mise à jour ne les modifie pas intentionnellement

• L'orientation à long terme reste un projet starter distinct qui dépend de fklavyenet/webblocks-cms en tant que paquet.
• Le paquet actuel présent dans le dépôt existe pour établir les limites et les responsabilités avant de tenter cette séparation.
• La séparation du starter ne doit intervenir qu'une fois les limites restantes de la racine repensées : l'exécution installation/authentification/profil, le modèle User détenu par l'application, l'autorité sur les migrations de la racine, l'autorité opérationnelle de mise à jour/installation à la racine et le chemin actif des assets d'exécution public/cms de la racine.

• Déplacez un type de ressource à la fois de la limite réservée vers la propriété active du paquet.
• Ne commencez que lorsque la règle exacte de chargement à l'exécution, la gestion des surcharges d'installation et le comportement de publication/mise à jour sont clairs pour ce type de ressource.
• Préférez des plans de phase ciblés — vues du paquet, migrations du paquet ou assets publics du paquet — plutôt que de mélanger plusieurs types de ressources d'exécution dans un même point de contrôle.
• Gardez les déplacements de code lourds en exécution derrière des audits de dépendances dédiés, au lieu de les fondre dans le travail pilote sur les limites de ressources.

Faites évoluer le comportement de mise à jour vers des mises à jour du paquet CMS gérées par Composer, complétées d'étapes post-mise à jour contrôlées telles que migrations, vidage du cache et publication ou synchronisation des assets lorsque nécessaire. La réparation du catalogue reste un flux de maintenance explicite de l'opérateur plutôt qu'une étape de mise à jour par défaut.

Le point de contrôle de maturité actuel comprend désormais :

• l'autoload Composer du paquet pour WebBlocks\Cms\Database\Seeders\
• le câblage de développement conservé par dépôt de chemin à la racine vers packages/webblocks-cms
• la documentation explicite indiquant que le comportement actuel de System Update à la racine fait toujours autorité tant qu'une phase ultérieure dédiée au flux de mise à jour ne le modifie pas intentionnellement

Introduisez l'orientation de projet starter distinct, telle que fklavyenet/webblocks-cms-starter, afin que les nouvelles installations partent d'une racine Laravel détenue par l'utilisateur qui dépend du paquet CMS, au lieu de cloner le dépôt du cœur du CMS dans la racine du projet.

Le point de contrôle actuel n'ajoute que le travail préparatoire sur les limites en vue de cette future séparation :

• davantage de seeders détenus par le CMS vivent désormais dans le paquet plutôt que dans le namespace de l'application racine
• davantage d'aides d'exécution à faible risque vivent désormais dans src/Support/ du paquet
• les wrappers de compatibilité de app/ à la racine ne sont plus conservés par défaut ; les wrappers PHP homologues du paquet ont été supprimés, tandis que les chemins de compatibilité Blade, seeders et assets d'exécution de la racine subsistent là où ils restent nécessaires
• les métadonnées composer du paquet, la découverte du provider, le câblage de développement par dépôt de chemin et le flux cible documenté composer require ou composer update forment désormais la base de maturité de la fondation starter

Les installations existantes auront besoin d'un chemin de migration prudent :

• garder les installations actuelles fonctionnelles tant que la transition vers le paquet est incomplète
• éviter les grands déplacements en une seule étape qui mêlent refactorisations d'exécution et changements d'empaquetage
• préserver les fichiers racine propres à l'installation en tant qu'état de projet détenu par l'utilisateur
• cesser de s'appuyer sur le remplacement des fichiers du cœur du CMS dans toute la racine comme mécanisme de mise à jour
• introduire des consignes claires pour supprimer les fichiers obsolètes du cœur du CMS gérés à la racine une fois leurs remplaçants détenus par le paquet en place

La transition doit privilégier une progression incrémentale à faible risque plutôt qu'une réécriture unique.

La consolidation de la transition vers le paquet est terminée pour tout le code source détenu par le CMS déplaçable sans risque dans ce dépôt.

• L'autorité du paquet couvre désormais les domaines de code d'exécution déplaçables sans risque : routes, vues, modèles, seeders, partials partagés, layout d'administration et support du CMS.
• Les classes App\... homologues du paquet ont été retirées de l'arborescence app du dépôt de maintenance ; les fichiers Blade de la racine, les seeders de la racine et les copies d'exécution public/cms/... de la racine restent volontairement en place comme wrappers ou chemins de compatibilité.
• Les URL des assets d'exécution actifs utilisent encore les chemins de compatibilité public/cms/... de la racine, même là où des fichiers sources homologues détenus par le paquet existent sous packages/webblocks-cms/public/cms/....
• Les limites finales restantes sont l'exécution installation/authentification/profil, le modèle User détenu par l'application, l'autorité sur les migrations de la racine, l'autorité opérationnelle de mise à jour/installation à la racine et la conception de la future séparation starter.
• En raison de ces blocages, le paquet n'est pas encore prêt pour la séparation starter, même si le travail sûr de consolidation du code détenu par le CMS est terminé.

Cette modification du dépôt n'est que la première étape de transition à faible risque :

• elle ajoute de la documentation d'architecture
• elle crée le squelette du paquet dans le dépôt sous packages/webblocks-cms/
• elle ajoute un composer.json minimal pour le paquet
• elle ajoute un WebBlocks\Cms\WebBlocksCmsServiceProvider
• elle câble le projet racine pour exiger le paquet localement par chemin

Le provider définit désormais le contrat d'amorçage du paquet pour les futures ressources du paquet, mais ces ressources ne font pas encore autorité car les fichiers d'exécution actuels du CMS résident toujours dans l'application racine.

Le pilote v1.31.62 rend ces limites de ressources du paquet plus concrètes en ajoutant des fichiers marqueurs de limite réservés explicites sous routes/, resources/views/, database/migrations/, public/ et stubs/ du paquet. Ces répertoires existent désormais comme cibles documentées détenues par le paquet pour les phases ultérieures, mais leur contenu reste un espace réservé non faisant autorité à ce point de contrôle.

Le pilote v1.31.63 ne fait avancer que la limite du namespace de vues du paquet, en ajoutant une véritable vue Blade de diagnostic interne sous resources/views/diagnostics/package-status.blade.php du paquet et une sonde de rendu optionnelle en lecture seule webblocks:package-status --view-check. Cela prouve le chargement de vues par namespace de paquet avec une vraie vue détenue par le paquet, tout en laissant faire autorité la résolution des vues d'administration et publiques de la racine.

Le pilote v1.31.64 ne fait avancer que la limite des routes du paquet, en ajoutant un véritable fichier de routes de diagnostic du paquet sous routes/diagnostics.php, tout en gardant le chargement des routes explicitement désactivé en exécution normale. Cela prouve les limites de propriété des fichiers de routes du paquet sans déplacer aucune route active d'administration ou publique de la racine.

Le point de contrôle v1.31.65 achève les pilotes de limites inertes restants en gardant les migrations du paquet explicitement désactivées par garde, en confirmant que la publication des assets publics et des stubs du paquet reste inerte tant qu'aucun fichier réel détenu par le paquet n'existe, et en documentant les mises à jour de paquet gérées par Composer comme limite cible sans modifier le flux de mise à jour actuel de la racine.

La version v1.32.0 amorce ce déplacement prévu avec les phases 1-2 de migration d'exécution protégées par des gardes :

• la portion d'exécution des diagnostics du paquet est réelle et détenue par le paquet de bout en bout, via un contrôleur du paquet plus la vue de diagnostic existante du paquet, mais elle reste désactivée par garde par défaut
• une portion ciblée d'exécution d'administration est désormais détenue par le paquet de bout en bout via routes/admin.php, src/Http/Controllers/Admin/PackageAdminStatusController.php et resources/views/admin/runtime-status.blade.php du paquet, mais elle reste désactivée par garde par défaut sur un chemin réservé
• une portion ciblée d'exécution publique est désormais détenue par le paquet de bout en bout via routes/public.php, src/Http/Controllers/Public/PackagePublicStatusController.php et resources/views/public/runtime-status.blade.php du paquet, mais elle reste désactivée par garde par défaut sur un chemin réservé
• webblocks:package-status rend désormais compte de la portion d'exécution des diagnostics, de la portion admin du paquet, de la portion publique du paquet et des gardes de routes explicites, toujours en lecture seule
• les routes et les vues de la racine font toujours autorité pour l'exécution CMS existante en dehors de ces chemins réservés au paquet et protégés par des gardes
• le config/webblocks-cms.php du paquet détient désormais des valeurs de configuration de transition explicites : diagnostics, routes publiques d'état, routes admin d'état et chargement des migrations du paquet restent désactivés par défaut, tandis que le chargement des routes admin du paquet est activé pour donner une autorité active aux routes d'administration détenues par le paquet

Les notes de points de contrôle historiques ci-dessous décrivent comment l'autorité du paquet a été introduite. Là où elles mentionnent des wrappers App\... de la racine, le nettoyage global actuel de l'application racine remplace cet état : les wrappers PHP homologues du paquet sont désormais volontairement absents, sauf mention dans l'état actuel de nettoyage de l'application racine ci-dessus.

Le point de contrôle actuel d'autorité d'exécution de l'étape 1 étend encore cette limite :

• les routes d'administration actives du CMS se chargent désormais depuis routes/admin.php du paquet, tandis que routes/web.php de la racine est réduit au chargement de l'installation, de l'authentification, du profil et de la compatibilité
• les routes publiques actives du CMS se chargent désormais depuis routes/public.php du paquet, y compris l'accueil, l'accueil localisé, la recherche, la recherche localisée, la recherche JSON, l'affichage de page, l'affichage de page localisé, les envois de contact, la synchronisation du consentement de confidentialité et admin-api.*
• des contrôleurs publics détenus par le paquet sous-tendent désormais cette portion d'entrée publique sous packages/webblocks-cms/src/Http/Controllers/Public/
• un ContactMessageRequest détenu par le paquet et des vues d'entrée publique détenues par le paquet sous-tendent désormais les points d'entrée des routes publiques déplacées
• les App\Http\Controllers\PageController, PublicSearchController, ContactMessageController, PublicPrivacyConsentController et App\Http\Requests\ContactMessageRequest de la racine ont ensuite été supprimés en tant que wrappers homologues redondants du paquet
• les modèles et classes de support de la racine ne subsistent que là où ils servent des domaines détenus par l'hôte ou en transition explicite ; Users, installation/profil/authentification, les chemins d'exécution des assets publics/admin de la racine, les migrations et le comportement de System Update restent des limites, si bien que le paquet n'est pas encore prêt à servir d'exécution starter pleinement indépendante sans une extraction plus profonde

Le point de contrôle actuel de rendu public de l'étape 2 étend encore l'autorité du paquet derrière ces routes publiques déjà détenues par le paquet :

• le fichier du paquet resources/views/layouts/public.blade.php détient désormais la coque de layout public active sous l'espace de noms webblocks-cms::
• les fichiers du paquet resources/views/pages/show.blade.php, resources/views/search/show.blade.php, resources/views/search/partials/modal.blade.php et pages/partials/slot*.blade.php détiennent désormais la coque de page publique active, la coque de recherche publique, la fenêtre modale de recherche publique et la couche de rendu des entrées de slot
• les fichiers racine resources/views/layouts/public.blade.php, resources/views/pages/show.blade.php, resources/views/search/show.blade.php, resources/views/search/partials/modal.blade.php, resources/views/pages/partials/slot.blade.php et resources/views/pages/partials/block.blade.php ne subsistent plus que comme des enveloppes de compatibilité pointant vers les vues à espace de noms détenues par le paquet
• la prise en charge du rendu public détenue par le paquet comprend désormais PageRouteResolver, PublicPagePresenter, PublicSharedSlotResolver, SlotWrapperResolver, SiteAssetResolver, PublicSearchQuery, PublicOverlayRegistry, PublicBodyEndRegistry, TrustedHtmlOverlayExtractor, SiteResolver, ResolvedSite et VisitorEventLogger
• les classes racine App\Support\... correspondant à ces aspects du rendu public ont été supprimées ensuite, une fois que les composants internes du paquet et les routes n'en avaient plus besoin
• le répertoire du paquet resources/views/pages/partials/blocks/* détient désormais l'arborescence complète des partials du moteur de rendu public des blocs livrés, comme un seul lot cohérent du paquet
• les fichiers racine resources/views/pages/partials/blocks/ subsistent désormais comme de fines enveloppes de compatibilité qui délèguent aux vues webblocks-cms::pages.partials.blocks. correspondantes
• Block::publicRenderView() résout désormais les types de bloc du cœur livrés en priorité vers les partials de bloc à espace de noms détenus par le paquet, tandis que les moteurs de rendu de bloc racine propres à l'installation ou personnalisés restent disponibles via le chemin de repli racine existant lorsqu'aucun partial correspondant n'existe dans le paquet
• la base du modèle public réside désormais sous src/Models/ du paquet ; les enveloppes racine App\Models\... correspondantes ont été supprimées ensuite, après que les tests du paquet et de consommateurs neufs ont prouvé qu'elles étaient inutiles
• Page, PageTranslation, PageSlot et Block résident désormais eux aussi sous src/Models/ du paquet, sans enveloppes racine correspondantes
• User reste volontairement détenu par l'application et par la racine et ne fait pas partie de la cible de migration des modèles vers le paquet
• le répertoire public/cms/ du paquet contient désormais les fichiers CSS et JS d'exécution publique actifs nécessaires à la couche de layout public et de rendu des blocs déplacée dans le paquet, et vendor:publish --tag=webblocks-cms-assets publie désormais ces véritables ressources du paquet dans le chemin de compatibilité racine public/cms
• l'exécution active continue de servir public/cms/... depuis l'installation racine pour des raisons de compatibilité, l'installation et System Update rafraîchissant dans ce chemin les ressources CMS détenues par le paquet
• les migrations racine restent faisant autorité pour les copies maintenues depuis les sources avec le signal d'autoload Composer explicite à la racine, tandis que les System Updates natives du paquet ignorent les migrations de l'application Laravel hôte et n'exécutent que les migrations de mise à jour dédiées au paquet lorsqu'elles existent
• System Update, le flux d'installation, la sauvegarde ou la restauration et, plus largement, l'exécution de la couche projet restent inchangés dans ce lot
• la validation par des consommateurs ou des paquets de démarrage n'est toujours pas réaliste après ce point de contrôle, car l'exécution dépend encore des migrations racine, des chemins de ressources de compatibilité racine, des flux d'administration et d'installation/mise à jour détenus par la racine, et de la frontière volontaire du modèle User racine détenu par l'application

Le point de contrôle actuel de l'exécution d'administration de Site et Locale déplace une tranche cohérente supplémentaire de l'administration derrière l'arborescence de routes d'administration détenue par le paquet :

• des contrôleurs détenus par le paquet gèrent désormais l'administration de Site, la gestion de Site Domain, la gestion de Site Variable et l'administration de Locale sous packages/webblocks-cms/src/Http/Controllers/Admin/
• les Form Requests détenues par le paquet, les modèles SiteLocale et SiteVariable ainsi que les services de support directement liés à Site ou Locale résident désormais sous src/ du paquet, sans enveloppes racine App\... correspondantes
• les répertoires du paquet resources/views/admin/sites/, resources/views/admin/sites/domains/, resources/views/admin/domains/ et resources/views/admin/locales/ détiennent désormais les arborescences Blade actives d'administration de Site, Domain et Locale via l'espace de noms webblocks-cms::
• les fichiers Blade racine de Site, Domain et Locale subsistent désormais comme de fines enveloppes de compatibilité qui rendent les vues correspondantes détenues par le paquet
• ce lot ne déplace volontairement ni les migrations, ni les flux d'installation/mise à jour, ni la sauvegarde/restauration, ni la propriété de l'authentification/du profil/de User, ni la propriété de la configuration racine, ni l'autorité sur les ressources public/cms

La configuration par défaut détenue par le paquet a désormais démarré pour webblocks-updates, tandis que le fichier de configuration racine reste faisant autorité comme surcharge de l'installation pendant la transition.

La configuration par défaut détenue par le paquet a désormais démarré également pour contact, tandis que le fichier de configuration racine reste faisant autorité comme surcharge de l'installation pendant la transition.

La configuration par défaut détenue par le paquet a désormais démarré également pour demo_media, tandis que le fichier de configuration racine reste faisant autorité comme surcharge de l'installation pendant la transition.

La configuration par défaut détenue par le paquet a désormais démarré également pour cms, tandis que le fichier de configuration racine reste faisant autorité comme surcharge de l'installation pendant la transition.

L'amorçage console détenu par le paquet est désormais également démontré par la commande de diagnostic en lecture seule webblocks:package-status.

L'espace de noms de vues du paquet webblocks-cms est désormais lui aussi enregistré de manière sûre comme pilote de la frontière du paquet, et v1.31.63 démontre cet espace de noms avec une véritable vue de diagnostic détenue par le paquet. La résolution des vues racine actives reste faisant autorité, car aucune vue d'administration ou publique active de l'exécution du CMS n'a été déplacée dans le paquet.

La frontière de routes du paquet est désormais elle aussi démontrée par un véritable fichier de routes de diagnostic détenu par le paquet, mais la résolution des routes d'administration et publiques racine actives reste faisant autorité, car les routes de diagnostic du paquet restent désactivées par des gardes en exécution normale et aucun fichier de routes racine actif n'a été déplacé dans le paquet.

Les frontières de migration, de ressources publiques et de stubs du paquet sont désormais également achevées de manière explicite en tant que pilotes réservés et inertes, et la frontière du flux de mise à jour géré par Composer n'est documentée que comme direction cible. Aucune migration racine active, aucune ressource publique racine, aucun comportement de stubs racine ni aucun comportement du flux de mise à jour racine n'est encore passé sous l'autorité du paquet.

Le premier déplacement de source PHP détenu par le paquet est désormais achevé pour SearchTextNormalizer, déplacé de app/Support/Search/ vers src/Support/Search/ du paquet, avec un comportement inchangé.

La frontière du support Search reste volontairement étroite à cette étape : SearchTextNormalizer et le petit objet valeur de résultat PublicSearchRebuildResult sont désormais détenus par le paquet, tandis que l'indexation de la recherche et l'orchestration des requêtes restent détenues par la racine jusqu'à ce que leurs dépendances à la base de données et à l'exécution soient migrées délibérément.

Le premier audit de Support hors Search est lui aussi désormais documenté : MediaKindResolver, DatabaseExecutionStrategyResolver, SiteHandle et SiteDomainNormalizer ont été examinés, et aucune classe supplémentaire n'a été déplacée, car chacune franchit encore au moins une frontière de risque propre à cette phase initiale.

Le premier déplacement de source du support Contact est désormais lui aussi achevé pour ContactMessageNotificationResult, déplacé de app/Support/Contact/ vers src/Support/Contact/ du paquet, avec un comportement inchangé, tandis que le service de notification et le flux d'exécution des contacts restent détenus par la racine.

Le premier déplacement de source du support BlockTypes est désormais lui aussi achevé pour BlockTypeContract, déplacé de app/Support/BlockTypes/ vers src/Support/BlockTypes/ du paquet, avec un comportement inchangé, tandis que le registre, le chemin de la fenêtre modale des contrats dans l'administration et la commande d'audit restent détenus par la racine.

LayoutMarkup a lui aussi été audité comme déplacement possible et circonscrit d'un utilitaire de Pages et reste détenu par la racine pour l'instant, car ses références actuelles franchissent encore la validation des requêtes de page layout, le rendu des formulaires d'administration et le comportement public des conteneurs de slot.

Le premier déplacement de source du support Formatting est désormais lui aussi achevé pour InlineRichTextRenderer, déplacé de app/Support/Formatting/ vers src/Support/Formatting/ du paquet, avec un comportement inchangé, tandis que SafeRichTextRenderer et son contrat d'assainissement restent détenus par la racine.

Le point de contrôle suivant, à faible risque, du support d'exécution est désormais lui aussi achevé pour quatre utilitaires circonscrits qui restent proches de l'état des requêtes d'administration et de la pagination :

• AdminPagination réside désormais dans src/Support/Admin/ du paquet
• BlockTypeIndexState réside désormais dans src/Support/BlockTypes/ du paquet
• MediaIndexState réside désormais dans src/Support/Media/ du paquet
• PageIndexState réside désormais dans src/Support/Pages/ du paquet
• les enveloppes racine App\Support\... de ces utilitaires ont été supprimées ensuite ; les imports du paquet font autorité

Le premier déplacement de la frontière des seeders détenus par le paquet est désormais lui aussi achevé pour les catalogues à faible risque :

• désormais détenus par le paquet : IconCatalogSeeder, PageTypeSeeder, LayoutTypeSeeder, SlotTypeSeeder
• désormais détenu par le paquet également : CoreCatalogSeeder, comme déplacement de la frontière de l'agrégateur de catalogues
• les classes racine Database\Seeders\... subsistent comme enveloppes de compatibilité
• CoreCatalogSeeder maintient toujours la stabilité des points d'entrée racine en déléguant via l'enveloppe racine, tout en continuant d'appeler PageLayoutSeeder et BlockTypeSeeder, détenus par la racine
• PageLayoutSeeder, BlockTypeSeeder et l'amorçage actif de System Update restent détenus par la racine jusqu'à une phase dédiée ultérieure

Le lot d'exécution isolé suivant détenu par le paquet est désormais lui aussi achevé pour la gestion du catalogue d'icônes :

• désormais détenus par le paquet : SyncWebBlocksUiIconsCommand, IconCatalogController, IconCatalogItemUpdateRequest, IconCatalog et WebBlocksIconManifestSyncer
• les classes racine App\Http\Controllers\Admin\IconCatalogController, App\Http\Requests\Admin\IconCatalogItemUpdateRequest, App\Support\Icons\... et App\Console\Commands\SyncWebBlocksUiIconsCommand ont été supprimées ensuite en tant qu'enveloppes redondantes de leurs homologues du paquet
• les routes d'administration actives du catalogue d'icônes pointent désormais directement vers le contrôleur du paquet, et icons:sync-webblocks-ui est désormais enregistrée par le service provider du paquet avec la classe de commande du paquet
• les définitions actives des routes d'administration du catalogue d'icônes résident désormais dans routes/admin.php du paquet au lieu de routes/web.php à la racine
• les enveloppes PHP racine du catalogue d'icônes ne sont plus disponibles ; l'autorité active sur les routes et la console réside dans le paquet
• désormais détenues par le paquet également : les vues Blade actives d'index et de fenêtre modale d'édition du catalogue d'icônes dans l'administration, sous packages/webblocks-cms/resources/views/admin/system/icons/
• les fichiers Blade racine du catalogue d'icônes subsistent comme enveloppes de compatibilité qui incluent les vues à espace de noms du paquet, mais le contrôleur du paquet rend directement webblocks-cms::admin.system.icons.index
• ce lot reste circonscrit à l'administration et à la synchronisation du catalogue d'icônes et ne déplace volontairement pas la propriété d'exécution plus large de Pages, Blocks, l'indexation Search, Sites, Updates, Install, Backup ou Restore, Export ou Import, ni du rendu public
• webblocks:package-status signale désormais les fichiers d'exécution des icônes détenus par le paquet ainsi que l'absence des enveloppes PHP racine correspondantes, dans le cadre du diagnostic de transition en lecture seule

Le lot d'extraction plus vaste de l'exécution d'administration est désormais lui aussi achevé pour les principales surfaces de gestion éditoriale et de catalogue :

• routes/admin.php du paquet fait désormais autorité non seulement pour la gestion du catalogue d'icônes, mais aussi pour les gestionnaires actifs des routes d'administration de Pages, Blocks, Media, Shared Slots, Navigation, Block Types et Page Layouts
• désormais détenus par le paquet : les contrôleurs d'administration faisant autorité pour ces tranches, sous packages/webblocks-cms/src/Http/Controllers/Admin/
• désormais détenues par le paquet : les form requests d'administration faisant autorité pour ces tranches, sous packages/webblocks-cms/src/Http/Requests/Admin/
• désormais détenus par le paquet : les services de support des blocs, des médias, de la navigation, des pages, des page layouts et des shared slots, sous packages/webblocks-cms/src/Support/
• désormais détenues par le paquet : les arborescences Blade d'administration actives sous packages/webblocks-cms/resources/views/admin/blocks/, admin/media/, admin/navigation/, admin/block-types/, admin/pages/, admin/shared-slots/, admin/page-layouts/ et admin/page-layout-slots/
• les enveloppes PHP racine App\Http\Controllers\Admin\..., App\Http\Requests\Admin\... et App\Support\... de ces tranches déplacées ont été supprimées ensuite en tant qu'enveloppes redondantes de leurs homologues du paquet
• les fichiers racine resources/views/admin/... de ces arborescences déplacées subsistent désormais comme enveloppes de compatibilité qui incluent les vues webblocks-cms::admin.* correspondantes
• une exception reste volontairement concrète à la racine : resources/views/admin/blocks/types/partials/rich-text-editor.blade.php conserve encore le balisage réel, car la couverture de compatibilité lit ce fichier racine directement au lieu de le résoudre uniquement via l'espace de noms du paquet
• ce lot ne déplace volontairement ni Users, ni les sauvegardes, ni les mises à jour, ni les réglages système, ni le flux d'installation, ni les migrations, ni les chemins de ressources d'exécution racine, ni le modèle User détenu par l'application
• webblocks:package-status, ainsi qu'une couverture d'amorçage ciblée, signalent désormais les fichiers d'exécution d'administration détenus par le paquet, plus nombreux, et l'absence des enveloppes PHP racine correspondantes

Le lot ciblé de l'exécution opérationnelle d'administration est désormais lui aussi détenu par le paquet :

• les contrôleurs appartenant au paquet gèrent désormais l'interface Dashboard, celle de revue des Contact Messages dans l'administration, celle des Visitor Reports et celle de statut ou de reconstruction de System Search, sous packages/webblocks-cms/src/Http/Controllers/Admin/
• les classes de support appartenant au paquet incluent désormais le service de requêtes des rapports de visiteurs et l'assistant léger d'état du schéma de recherche publique ; l'architecture complète d'indexation de la recherche et le comportement de la commande search:rebuild restent inchangés derrière les points d'entrée de compatibilité de la racine
• dans le paquet, resources/views/admin/dashboard.blade.php, admin/contact-messages/*, admin/reports/visitors/index.blade.php et admin/system/search.blade.php sont désormais propriétaires des surfaces Blade opérationnelles actives de l'administration via l'espace de noms webblocks-cms::
• les fichiers de contrôleur, de support et Blade de la racine pour ces surfaces opérationnelles restent de simples enveloppes de compatibilité
• ce lot ne déplace volontairement pas System Update, System Backup, la sauvegarde/restauration, l'export/import de site, la promotion de site, l'installateur, la propriété auth/profil/User, les migrations ni la propriété de la configuration racine, pas plus que l'autorité sur les ressources de public/cms à la racine

Le suivi sûr restant des routes opérationnelles actives est lui aussi terminé :

• les contrôleurs appartenant au paquet gèrent désormais aussi Slot Types et System Settings sous packages/webblocks-cms/src/Http/Controllers/Admin/
• les Form Requests appartenant au paquet incluent désormais aussi SystemSettingsRequest sous packages/webblocks-cms/src/Http/Requests/Admin/
• dans le paquet, resources/views/admin/slot-types/index.blade.php et resources/views/admin/system/settings.blade.php sont désormais propriétaires des surfaces Blade actives via l'espace de noms webblocks-cms::
• à la racine, App\Http\Controllers\Admin\SlotTypeController, App\Http\Controllers\Admin\SystemSettingsController, App\Http\Requests\Admin\SystemSettingsRequest ainsi que les fichiers Blade correspondants de la racine restent des enveloppes de compatibilité
• ce suivi ne déplace toujours pas volontairement l'implémentation de System Update, la sauvegarde ou la restauration, l'installateur, la propriété auth/profil/User, les migrations ni la propriété de la configuration racine, pas plus que l'autorité sur les ressources d'exécution de public/cms à la racine

L'état du shell d'administration et de la frontière des ressources est le suivant :

• les vues d'administration appartenant au paquet étendent webblocks-cms::layouts.admin, et l'enveloppe de compatibilité de la racine resources/views/layouts/admin.blade.php a été supprimée, de sorte que les erreurs d'espace de noms chez les consommateurs du paquet échouent localement
• dans le paquet, public/cms/ contient aussi les fichiers source CSS et JS d'administration correspondant au jeu de ressources d'administration actif de la racine, tandis que les chemins public/cms/... de la racine restent la couche de compatibilité d'exécution
• les migrations, l'updater, la sauvegarde/restauration, l'export/import, la promotion, auth/User, l'installateur, la configuration racine et l'autorité sur les ressources d'exécution restent en dehors de la frontière immédiate du shell d'administration du paquet

Les lots sélectionnés de partials et de composants partagés de l'administration appartiennent désormais au paquet :

• désormais propriété du paquet : webblocks-cms::admin.partials.page-header, flash, listing-filters, page-actions, pagination et audit-actor
• désormais propriété du paquet : webblocks-cms::components.admin.form-actions, consommé depuis les vues du paquet via <x-webblocks-cms::admin.form-actions>
• désormais propriété du paquet : webblocks-cms::layouts.admin, consommé depuis les vues d'administration appartenant au paquet via @extends('webblocks-cms::layouts.admin', ...)
• à la racine, resources/views/admin/partials/{page-header,flash,listing-filters,page-actions,pagination,audit-actor}.blade.php restent des enveloppes de compatibilité
• à la racine, resources/views/layouts/admin.blade.php n'existe plus ; les vues d'administration des plugins et du paquet ne doivent pas utiliser le chemin historique layouts.admin
• à la racine, resources/views/components/admin/form-actions.blade.php reste l'enveloppe de compatibilité pour l'usage existant de <x-admin.form-actions>
• les vues d'administration appartenant au paquet privilégient désormais l'espace de noms du paquet pour le layout d'administration et pour ces partials et composants partagés sélectionnés
• webblocks:package-status signale désormais la frontière sélectionnée des partials et composants partagés de l'administration, ainsi que l'inventaire des vues d'administration à l'exécution, qui inclut désormais le layout d'administration appartenant au paquet et son enveloppe à la racine
• les URL des ressources d'administration de la racine et l'autorité d'exécution sur public/cms, les ressources de marque, les frontières auth/profil/installation/app/guest, les migrations, l'updater, la sauvegarde/restauration et le travail de publication et de version restent inchangés

Le balayage des frontières du paquet en v1.32.15 ajoute un audit statique, en garde-fou de publication, pour les références d'administration à l'exécution appartenant au paquet :

• l'audit analyse packages/webblocks-cms/src/*/.php, packages/webblocks-cms/resources/views/*/.blade.php et packages/webblocks-cms/routes/*/.php
• il échoue sur les références d'administration propres à la racine telles que view('admin.'), View::make('admin.'), response()->view('admin.'), @include('admin.'), @includeIf('admin.'), @extends('layouts.admin'), <x-admin., <x-auth-password-field, component('admin.') et les références directes admin.blocks.types. d'administration de blocs à la racine
• les seules exceptions admises sont des entrées exactes de fichier et de motif dans la liste d'autorisation, où le code d'exécution du paquet vérifie d'abord le nom webblocks-cms::... et n'utilise le nom de la racine que comme repli de compatibilité explicite pour les surcharges existantes spécifiques à l'installation

Le point de contrôle initial à faible risque sur le code source des helpers et des objets valeur est désormais considéré comme réussi et terminé pour cette phase. L'environnement de développement local s'est également mis à jour avec succès après v1.31.60, ce qui confirme que le câblage actuel du paquet fonctionne dans l'environnement de développement maintenu.

Les déplacements opportunistes supplémentaires de code PHP à faible risque sont désormais suspendus. Les futurs déplacements de code fortement liés à l'exécution nécessitent un plan de phase dédié et un audit des dépendances, plutôt que d'autres petites migrations opportunistes.

Il ne déplace pas encore le code d'exécution existant du CMS, ne change pas le comportement de System Update, ne crée pas de projet starter et ne modifie pas les frontières de propriété d'exécution actuellement actives.

L'étape 1 a transféré au paquet l'autorité sur les routes actives du CMS, pour l'administration comme pour l'exécution publique, et elle a aussi transféré la tranche d'entrée des routes publiques pour les requêtes de page, de recherche, de message de contact et de consentement de confidentialité. Le prochain lot devrait réduire la plus grande zone de double propriété restant derrière cette autorité de routes du paquet, plutôt que de lancer un autre pilote restreint.

Modèles qui bloquent encore une exécution indépendante du paquet :

• restent temporairement propriété de la racine avec une dépendance au paquet documentée : modèles de contenu d'administration tels que BlockType, Media, SharedSlot, PageAsset, PageLayout, PageRevision, NavigationItem, SiteExport et SiteImport
• propriété du paquet avec des enveloppes de compatibilité à la racine : Locale, Site, SiteDomain, SiteLocale, SiteVariable, Page, PageTranslation, PageSlot, Block, ContactMessage, PublicSearchIndex, VisitorEvent et SystemSetting
• probablement prêts pour le paquet prochainement, en suivi restreint d'une tranche déjà détenue par le paquet : IconCatalogItem
• doit rester propriété de l'application : User

Frontières de vues qui bloquent encore une exécution indépendante du paquet :

• le layout public du paquet, le shell de page, le shell de recherche, la fenêtre modale de recherche, les vues d'entrée de slot et l'arbre livré de partials de rendu public des blocs font désormais autorité via l'espace de noms webblocks-cms::
• à la racine, resources/views/pages/partials/blocks/* reste volontairement présent comme couche d'enveloppes de compatibilité, afin que les moteurs de rendu de blocs spécifiques à l'installation à la racine et les références directes aux vues de la racine continuent de fonctionner pendant la transition
• le rendu d'administration du paquet fait désormais autorité pour admin/pages/, admin/blocks/, admin/shared-slots/, admin/media/, admin/navigation/, admin/block-types/, admin/page-layouts/, admin/page-layout-slots/, admin/sites/, admin/domains/ et admin/locales/* via l'espace de noms webblocks-cms::, tandis que les fichiers Blade correspondants de la racine restent des enveloppes de compatibilité
• le rendu d'administration de la racine fait toujours autorité pour les écrans non encore déplacés, en particulier les enveloppes d'installation/auth/profil et les cas limites d'utilisateur appartenant à l'application, tandis que le rendu du paquet fait autorité pour les écrans actifs de transfert et de promotion de sites via webblocks-cms::

Frontières de support et de services qui bloquent encore une exécution indépendante du paquet :

• désormais propriété du paquet pour la tranche de rendu public : résolution des routes, présentation des pages, présentation des Shared Slots, résolution des enveloppes de slot, extraction des superpositions HTML de confiance, registres de superposition publique ou de fin de body, orchestration des requêtes de recherche publique, résolution du site public, résolution des ressources de site et journalisation des événements de visiteurs
• à déplacer seulement après le déplacement des modèles : les couches restantes Pages ou PublicRendering, Blocks, indexation de Search, Navigation, SharedSlots ou Revisions qui reposent encore directement sur des modèles de la racine ou sur des flux d'administration plus larges
• à conserver pour l'instant à la racine : Media, les flux de portabilité de Sites, l'assainissement de Formatting et les helpers Admin ou Audit
• doit rester propriété de la racine d'installation : Install, System ou Updates, la sauvegarde ou la restauration et les writers de version installée et d'environnement

Blocages liés aux requêtes, commandes, ressources, migrations et flux de mise à jour :

• de nombreuses Form Requests d'administration pourront être déplacées plus tard avec des enveloppes à la racine, une fois déplacés les lots correspondants de page, de bloc, de Shared Slot, de médias, de site et de navigation
• de nombreuses Form Requests éditoriales de l'administration ont déjà été déplacées avec des enveloppes à la racine, mais les requêtes de système, de portabilité de site, de mise à jour, de sauvegarde, d'installation et les autres orientées exploitation restent propriété de la racine
• les commandes de mise à jour, de sauvegarde, d'import, d'export, de promotion et d'installation utilisées par le paquet doivent rester explicitement délimitées, car elles dépendent encore de l'environnement, du système de fichiers, des archives, de Composer, des migrations et de l'état d'installation
• à la racine, public/cms/* contient toujours les ressources qui constituent les chemins d'exécution actifs faisant autorité, même si public/cms/ contient désormais aussi le CSS et le JS du layout public déplacés et peut les publier via webblocks-cms-assets
• les migrations de la racine font toujours autorité pour les checkouts maintenus depuis les sources, avec l'autorité d'autoload Composer à la racine du dépôt de maintenance ; les nouveaux consommateurs natifs du paquet installés avec webblocks:install ne doivent pas exécuter les migrations de l'application Laravel hôte pendant System Update
• WebBlocks UI Manager n'est plus livré dans l'exécution du paquet CMS. Son code source se trouve sous plugins/webblocks-ui-manager pour les builds de maintenance, et les opérateurs l'installent manuellement sous forme de ZIP de plugin lorsqu'ils ont besoin des flux de publication ou CDN de WebBlocks UI.
• la préparation des paquets de plugins de la Phase 5 garde les classes, vues, routes, commandes, configuration, espaces de noms de réglages et préfixes de base de données appartenant au plugin attribuables aux identifiants de plugin ; les plugins désactivés ou incompatibles restent inertes et ne deviennent pas la responsabilité du cœur du CMS
• chez les consommateurs du paquet, System Updates n'exécute que les migrations de mise à jour dédiées appartenant au paquet depuis vendor/fklavyenet/webblocks-cms/database/migrations/updates lorsqu'elles sont présentes, et saute sinon l'exécution des migrations sans marquer comme exécutées des migrations arbitraires de l'hôte
• System Update reste une phase distincte car ses blocages sont la mutation de l'environnement, les écritures sur le système de fichiers, l'exécution de Composer, les sauvegardes, les migrations, la persistance de la version installée et l'état d'exploitation de la racine, et non la propriété des routes ou des contrôleurs

• Consolidation sûre du code appartenant au CMS : terminée
• Nettoyage restant de l'inversion des helpers déplacés : terminé (WebBlocks\Cms\Support\Blocks\BlockTranslationWriter et CoreBlockTypeCatalogSyncer possèdent désormais l'implémentation ; les classes App\Support\Blocks\... de la racine ne restent que des enveloppes de compatibilité)
• Consolidation des URL de ressources d'exécution actives : volontairement incomplète ; public/cms/... à la racine reste le chemin de compatibilité d'exécution
• Préparation de la séparation du starter : pas prête
• Frontières finales restantes : l'exécution installation/auth/profil, le modèle User appartenant à l'application, l'autorité de migration à la racine, l'autorité de mise à jour et d'installation à la racine et la future conception de la séparation du starter

Lot recommandé : effectuer un nettoyage ciblé de la compatibilité des modèles et du support pour les tranches d'exécution déjà détenues par le paquet, ou lancer la prochaine passe de stratégie de ressources et de marque de l'administration maintenant que le layout d'administration et les fichiers source CSS ou JS d'administration appartiennent au paquet. Conservez l'autorité active sur les ressources d'administration de public/cms à la racine tant que la stratégie de ressources d'administration n'est pas explicite.

Périmètre achevé à ce point de contrôle :

• shell public et vues de page : layouts.public, pages.show, search.show et search/partials/modal
• les partials de rendu des entrées de slot de page sous resources/views/pages/partials/slot*.blade.php
• les partials livrés de rendu public des blocs sous resources/views/pages/partials/blocks/*
• la couche de support du rendu public pour la résolution des routes, la présentation des pages publiques, la présentation des Shared Slots, la résolution des enveloppes de slot, l'extraction des superpositions HTML de confiance, les registres de superpositions, l'orchestration des requêtes de recherche, la résolution du site, la résolution des ressources de site et la journalisation des événements de visiteurs
• les enveloppes de compatibilité à la racine là où les références de routes, de contrôleurs, de requêtes ou de vues nécessitent encore des points d'entrée rétrocompatibles à la racine

Périmètre volontairement reporté pour ce lot :

• l'extraction des modèles Eloquent appartenant au paquet pour Locale, Site, SiteDomain, Page, PageTranslation, PageSlot, Block, ContactMessage, PublicSearchIndex, VisitorEvent et SystemSetting
• les URL de ressources d'exécution du paquet faisant autorité et leur flux de publication
• la refonte de l'autorité de migration à la racine
• l'extraction de System Update et du flux d'installation et de mise à jour

Pourquoi ce lot vient ensuite :

• l'autorité du paquet sur les routes, contrôleurs, requêtes, support et vues d'administration existe déjà dans les principales tranches d'exécution de l'administration
• les partials et composants partagés d'administration sélectionnés, ainsi que leurs cas limites restreints, ont désormais été déplacés, laissant les frontières plus larges de shell et de ressources
• le layout d'administration appartenant au paquet ainsi que les fichiers source CSS ou JS d'administration appartenant au paquet dépendent encore du chargement actif des ressources et de la marque à l'exécution depuis la racine : la prochaine étape devrait donc être une stratégie délibérée de ressources et de marque pour l'administration, plutôt qu'un nouveau déplacement de shell
• le prochain travail d'extraction à forte valeur consiste à réduire les hypothèses de compatibilité restantes des modèles et du support, ou à concevoir la stratégie de ressources et de marque de l'administration, sans se lancer dans les migrations, l'updater, la sauvegarde/restauration, l'export/import, la promotion, auth/User, l'installateur, la configuration racine ou l'autorité sur les ressources

• lot de portabilité des sites : Export ou Import ainsi que Promotion devraient attendre que leurs limites d'archivage, de sauvegarde et de transfert soient explicitement auditées
• les migrations, les ressources d'exécution actives, l'installateur, la sauvegarde/restauration, l'authentification/User et System Update doivent rester des phases dédiées et distinctes

Lot de repli : un nettoyage ciblé de la compatibilité restante des modèles et du support pour les portions d'exécution déjà détenues par le paquet.

Il s'agit du repli uniquement si les partials partagés révèlent un couplage inattendu avec l'authentification, l'updater, la sauvegarde ou l'installation, qui rendrait un motif de wrapper léger à la racine trop bruyant pour un petit lot d'implémentation.