## Description de l’évolution Dans le cadre de SPIP 5 (ou ultérieur si trop ambitieux), nous souhaitons nous rapprocher du comportement de symfony pour sa gestion des requêtes HTTP, des réponses retournées, des configurations de conteneur, de gestion d’événements (équivalent à nos pipelines), système de routage (partiellement). Nous intégrons aussi une commande CLI directement (bin/spip), qui est un POC pour le moment avec peu de commandes. On souhaite permettre de l’injection de dépendance et renforcer l’utilisation du conteneur de service qui était embryonnaire sur la dev SPIP 5 actuelle (et SPIP 4.4). On va proposer une première phase de PR transitoire, qui pose des premières bases de travail. On arrive a une certaine stabilité dessus. Notons qu’on a utilisé des agents IA pour nous aider dans certaines taches, en orientant nos directives pour les guider vers nos objectifs. Cependant, un grand effort complexe reste à faire sur la gestion des variables globales d’une part, et la gestion des routes et répertoire physique public/ afin d’avoir un point d’entrée web unique (tout en permettant une compat avec un document root à la racine comme actuellement). Ces deux points vont amener encore beaucoup de perturbations dans le code, aussi, il nous paraît judicieux de faire un premiere vague de merge auparavant. ## Plugins dist Certains plugins-dist, mais pas tous ont quelques configurations modifiées pour valider le nouveau fonctionnement général, et particulièrement ont un répertoire config/ et src/ ; ## Plugins Pour les autres plugins (non chargés avec composer), notre gestion de plugin actuelle proposée va regarder l’autoloader déclaré du plugin (composer.json) et déclarer toutes les classes de son répertoire src/ dans un fichier tmp/cache/boot/classmap.php, de même qu’il lira des définitions dans config/services.php notamment si cela existe. Aparté: Un éventuel require dans composer.json d’un plugin ne sera **PAS** traité. ## Vérification du fonctionnement Il serait bien que certaines personnes habituées à Git et SPIP puissent tester et vérifier l’installation. Pour installer dans un dossier "refactor" ``` git clone -b plugin_config git@git.spip.net:spip/spip refactor cd refactor composer update ``` Démarrer votre server web dessus, vérifier l’installation de SPIP. Note: il y a un problème connu sur mediabox (spip/mediabox#4891), on n’a pas fait de branche dédiée pour lui pour l’instant. ---- Dans un premier temps, on ne demande pas une revue particulière sur le code, mais surtout de pouvoir s’assurer que l’ensemble fonctionne a peu près correctement dans un premier temps. La gestion du conteneur de service (compilé) est un point d’attention particulièrement, tout comme la gestion des pipelines.