Après des mois de développement, Sulu vient de franchir une étape importante avec la sortie de sa version 3.0. Cette nouvelle mouture marque un changement d'approche radical dans la façon dont le CMS gère et stocke le contenu. L'équipe de développement n'y est pas allée par quatre chemins : plus de 265 000 lignes de code supprimées, 153 000 nouvelles lignes ajoutées.
Ce qu'il faut retenir, c'est que Sulu abandonne PHPCR, son système de stockage historique, pour basculer sur Doctrine ORM avec des champs JSON. Un choix qui vise à simplifier la vie des développeurs Symfony tout en améliorant sensiblement les performances. Le résultat est là avec un débit environ deux fois supérieur et une latence divisée par deux par rapport à l'ancienne architecture.
Au-delà du système de stockage, cette version 3.0 apporte son lot de nouveautés. Flysystem passe à la version 3 avec beaucoup plus d'adaptateurs disponibles, le bundle Article n'a plus besoin d'Elasticsearch pour tourner, et le système de recherche interne laisse place à SEAL avec Loupe comme moteur par défaut. Des changements qui répondent à des demandes concrètes de la communauté et qui devraient faciliter le déploiement sur différents types d'infrastructures.
Un changement d'architecture majeur pour le CMS
Sulu 3.0 marque un tournant dans l'évolution du CMS open source. L'équipe a ajouté plus de 153 000 lignes de code tout en en supprimant 265 000, ce qui donne une idée de l'ampleur de la refonte. Le résultat est un système plus rapide, plus facile à débugger et qui s'appuie sur des outils que les développeurs connaissent déjà.
Le changement le plus notable concerne le système de stockage du contenu. PHPCR avait du sens quand il a été choisi, avec son support natif pour les hiérarchies de contenu, le multilingue et le versioning. Mais le paysage du développement web a évolué et les bases de données relationnelles ont fini par proposer des champs JSON assez performants. Surtout, l'équipe s'est rendu compte que demander aux développeurs d'apprendre SQL2 et les concepts de PHPCR créait des frictions inutiles.
Doctrine ORM et champs JSON à la place de PHPCR
Le nouveau système utilise des champs JSON dans votre base de données relationnelle, gérés par des entités Doctrine ORM. Les pages, articles et snippets sont maintenant des entités Doctrine standard. On peut écrire des requêtes SQL ou DQL classiques pour analyser le contenu, regarder directement dans les tables pour débugger. Ça change vraiment la donne au quotidien.
Pour gérer la complexité du multilingue, des versions et des brouillons, le système introduit les "dimensions". Un même contenu peut exister dans plusieurs dimensions en même temps, avec différentes langues et différents états de publication. Le système fusionne automatiquement les bonnes dimensions au moment du rendu, ce qui permet par exemple à une page en allemand d'hériter des données non traduisibles de la dimension de base tout en affichant le contenu spécifique à l'allemand.
Les gains de performance sont substantiels. Les benchmarks montrent environ le double de débit et la moitié de latence par rapport au stockage PHPCR. Mais au-delà de la vitesse, l'expérience développeur s'améliore drastiquement parce que tout repose sur des patterns Doctrine familiers. Quand quelque chose ne marche pas, on examine les tables de base de données, on écrit des requêtes de test en SQL, on utilise les outils habituels.
Flysystem 3 et plus de flexibilité pour le stockage
La mise à jour de Flysystem de la version 1 à la version 3 apporte le support d'un nombre beaucoup plus important d'adaptateurs de stockage. Avant, on était limité au système de fichiers local, AWS S3, Azure et Google Cloud. Maintenant on peut utiliser n'importe quel adaptateur supporté par Flysystem, que ce soit FTP, SFTP, WebDAV, MongoDB GridFS ou des services tiers comme Dropbox et OneDrive.
Ça élimine une contrainte de déploiement importante. Que vous tourniez sur un hébergement traditionnel, des plateformes cloud ou des environnements hybrides, vous pouvez désormais stocker vos fichiers médias là où ça a du sens pour votre infrastructure et votre budget.
Les bundles réécrits et l'Article bundle libéré d'Elasticsearch
Tous les bundles qui dépendaient de PHPCR ont été complètement réécrits. Ça inclut les bundles Page, Article, Snippet et CustomURL. Ça signifie plus de travail pour les projets existants lors de la migration, mais ces bundles suivent maintenant les pratiques Symfony modernes et s'intègrent naturellement avec le nouveau système de stockage.
L'un des changements les plus demandés concernait le bundle Article qui nécessitait Elasticsearch pour fonctionner. C'était logique pour les scénarios de publication à gros volume, mais ça créait une barrière pour les projets plus modestes. Le nouveau bundle Article fonctionne parfaitement avec juste votre base de données. Pour ceux qui ont besoin des capacités avancées d'Elasticsearch, un bundle séparé SuluArticleViewDocumentBundle fournit la même intégration qu'avant.
SEAL et Loupe pour le système de recherche
Le système de recherche interne a été remplacé par SEAL, un projet collaboratif qui fournit un accès unifié à plusieurs moteurs de recherche. SEAL fonctionne comme Doctrine pour les bases de données ou Flysystem pour le stockage de fichiers : une API cohérente qui marche avec Elasticsearch, Meilisearch, Algolia, Solr et d'autres.
Par défaut, Sulu 3.0 utilise Loupe comme adaptateur de recherche. Loupe est un moteur de recherche en PHP pur qui utilise SQLite, créé par Yanick Witschi du projet Contao CMS. Il offre la tolérance aux fautes de frappe, la recherche de phrases, le filtrage et le support géographique sans nécessiter de services additionnels. Pour la majorité des installations Sulu, Loupe élimine le besoin de faire tourner une infrastructure de recherche séparée tout en offrant une expérience bien meilleure que des requêtes SQL basiques.
Si votre projet dépasse les capacités de Loupe (il gère efficacement jusqu'à environ 50 000 documents), passer à Meilisearch, Elasticsearch ou d'autres moteurs supportés par SEAL ne demande qu'un changement de configuration.
Paysage des versions et support
Avec la sortie de Sulu 3.0, le paysage des versions a évolué. Sulu 1.6 a officiellement atteint sa fin de vie et ne reçoit plus aucune mise à jour ni correctif de sécurité. Si vous tournez encore sur une installation 1.x, c'est le moment de planifier votre migration.
Sulu 2.6 devient la version LTS et recevra les correctifs de sécurité et les corrections de bugs critiques jusqu'à l'arrivée de Sulu 4.0. Ça donne aux équipes une base stable et bien maintenue pendant qu'elles évaluent leur calendrier pour migrer vers la nouvelle architecture. Sulu 3.0 est la version actuelle activement maintenue, qui reçoit des mises à jour régulières, de nouvelles fonctionnalités et des améliorations continues.
Migrer vers Sulu 3.0
Passer à Sulu 3.0 demande plus de travail qu'une mise à jour mineure habituelle, mais des outils ont été développés pour automatiser les parties les plus complexes. Le Sulu PHPCR Migration Bundle gère la conversion de votre contenu PHPCR existant vers le nouveau format de stockage, incluant toutes vos pages, articles, snippets et données d'URL personnalisées. La migration tourne comme une commande console qu'on peut tester sur des environnements de développement avant de l'exécuter en production.
Pour les migrations complexes ou les intégrations personnalisées, l'équipe de développement de Sulu peut évaluer votre situation spécifique et gérer le processus de mise à niveau. Les canaux de support communautaire restent actifs, avec un Slack pour l'aide en temps réel et GitHub Discussions pour les questions plus longues.
Pour conclure
Sulu 3.0 représente un pari audacieux pour l'équipe de développement. Refondre entièrement le système de stockage de contenu n'est pas une décision qu'on prend à la légère, surtout quand ça implique de réécrire tous les bundles principaux et de demander aux utilisateurs existants un effort de migration conséquent.
Mais les bénéfices semblent justifier cette rupture. En abandonnant PHPCR pour Doctrine ORM, Sulu se rapproche des pratiques standard de l'écosystème Symfony et réduit la courbe d'apprentissage pour les nouveaux développeurs. Les gains de performance sont réels et mesurables. L'ajout de SEAL et Loupe simplifie la gestion de la recherche pour les projets de taille moyenne qui n'ont pas forcément les ressources pour maintenir Elasticsearch.
Pour les équipes qui tournent encore sur Sulu 1.6, la migration devient urgente maintenant que cette version n'est plus maintenue. Celles qui préfèrent attendre peuvent s'appuyer sur Sulu 2.6 LTS qui restera supporté jusqu'à la version 4.0. Le bundle de migration automatisé devrait faciliter la transition, même si les projets avec beaucoup de code custom demanderont probablement un accompagnement.
Reste à voir comment la communauté va accueillir ces changements dans les mois qui viennent. Les fondations sont posées pour de nouvelles fonctionnalités et l'architecture semble plus pérenne. Sulu fait le pari que cette refonte lui permettra d'évoluer plus facilement dans les années à venir, ce qui n'est pas négligeable pour un CMS qui vise le long terme.
De notre côté, nous allons procéder à la migration de nos bundles communautaires de manière progressive.