Bonjour à tous·tes
J’aimerai aborder quelques points sur l’état d’évolution de SPIP 5 et le calendrier actuellement prévu (1er juillet).
Il y aurait différents points à discuter relativement à l’architecture du code PHP et JS ; je vais essayer de créer différents chapitres pour résumer quelques points.
Sur le code
A. État actuel
SPIP 5 à ce jour n’a pas vraiment de grosses nouveautés fonctionnelles : il y a différentes petites améliorations, mais (à ma connaissance) pas d’éléments fondamentalement nouveaux ou modifiés pour les rédacteurices, l’éditorial, ou l’écriture de squelettes.
L’essentiel du travail en cours et réalisé par certain·es est dans les coulisses, sur l’architecture du code.
SPIP 5 actuellement a reçu une grosse refonte du code javascript via les travaux de @placido ; l’ensemble semble fonctionnel, il pourrait y avoir une documentation plus détaillée, et il reste quelques points au moins à traiter. Éventuellement il y a un projet de déplacer du code dans un dépôt spip/frontend (je n’ai pas suivi cette partie là), qui n’est pas réalisée non plus à ce jour.
Côté PHP, SPIP 5 a commencé un découpage plus conséquent en dépots Composer plus autonomes (en classes, testés), dans spip-league/* , avec différents éléments de logger, de cache, de filesystem, notamment. Une évolution bienvenue mais qui reste très contenue également.
Enfin quelques modifications envoyées (notamment sur la méthode de sérialisation des configurations) peuvent déjà impacter les migrations et des plugins devront s’adapter à cela — tout comme ils devront s’adapter possiblement aux modifications de JS.
B. Avancée intégrable
Une série de PR sont en cours sur Refactor bootstrap SPIP avec composants symfony (#6087) · Issues · spip / spip · GitLab où l’état, bien que non définitif et non appliqué sur l’ensemble du code encore (notamment les plugins-dist), apporte un usage plus approfondi de briques Symfony, notamment le http-kernel, l’event-dispatcher, l’injection de dépendances, une commande CLI intégrée.
De nos tests et quelques retours, on est assez contents de ce premier pas d’évolution (James & moi en tout cas) : une bonne partie du legacy continue de fonctionner alors que des éléments « modernes » peuvent être utilisés, tel que des paramètres de configuration DI, des attributs comme #[AsPipelineListener] et l’injection de dépendance dans des classes de plugins. C’est une étape transitoire, mais qui apporte une première base pour avancer. Je n’entre pas dans les détails ici.
Les « refactors » amenés par ces PR sont assez conséquents. Nous avons également — disclaimer — utilisés des outils d’IA contrôlés et dirigés pour nous aider : le volume de code de SPIP et ses plugins est conséquent et nous sommes à peine 2 sur ces sujets PHP ; cela nous a aussi un peu remotivés après différentes tentatives locales avortées tant la tache de déspaghettification est fastidieuse…
C. Futurs possibles
Je parle côté PHP uniquement, mais la PR précédente n’est qu’une première étape. Idéalement il faudrait pouvoir
- se passer de la majorité des variables globales (et constantes variables ^^) dans SPIP qui posent différents soucis sur l’architecture du code et les tests, empêchent une injection de dépendance correcte dans un conteneur de services, empêchent d’utiliser notamment symfony/runtime en mode worker (bon, ça on en est très loin)
- pour cela avoir des objets PHP dédiés en priorité pour les config/meta (un gros chantier déjà) et pour l’API SQL (autre gros chantier, et sans utiliser Doctrine) ; et d’autres éléments que je n’ai pas en tête là et dont beaucoup sont très spécifiques à une globale donnée.
- générer et gérer des objets Response (a minima dans les actions) ; (on triche un peu dans la PR précédente en attendant mieux).
- permettre d’avoir un unique point d’entrée public/index.php sur lequel pointerait le vhost : c’est probablement une étape très compliquée car l’imbrication « route / url » vs « chemin physique » de SPIP est très forte et confondue à différents endroits du code.
Sur le calendrier
La date du 1er juillet 2026 initialement prévue (d’une date déjà reportée plusieurs fois depuis le 1er janvier 2025) arrive à grand pas. Plusieurs possibilités sont discutables pour la suite en fonction des motivations et énergies de la communauté.
Un petit vote pour avoir quelques opinions (clôture le 25 mai)
- Maintenir la date, conserver l’état actuel (« on » stabilise sans prendre trop de risques)
- Maintenir la date, merger les PR 6087, pas plus (on n’est pas à l’abri de surprises, de bugs, mais on suppose que ça va dans le bon sens)
- Repousser la date, merger les PR 6087, pas plus (ça va dans le bon sens, mais on laisse le temps de stabiliser un peu, sans aller plus loin)
- Repousser la date, merger les PR 6087 et aller plus loin. Faire disparaître ces globales, autres services injectables (config, sql…)
- Arrêter avec Symfony (vous nous faites chier avec votre lubie architecture PHP / Composer / Symfony / Injection de dépendances / obsession Globales → allez jouer ailleurs)
- Arrêter avec l’IA (vous nous faites chier avec votre usage de l’IA ; c’est trop problématique → allez jouer ailleurs)
Merci de votre lecture & participation.
N’hésitez pas à commenter et contribuer à la réflexion !
