Symfony 2, la promesse de CMS maintenables
De plus en plus de CMS se développent ou migrent sur Symfony 2. Ces nouvelles architectures peuvent-elles réconcilier les développeurs web et les CMS ?
Le CMS ou la hantise des développeurs web
Le CMS est là pour simplifier la vie des éditeurs de contenu. Avec des interfaces plus ou moins « user-friendly » tous les CMS remplissent leur rôles avec pour chacun des fonctionnalités plus ou moins avancées et une finalité différente (multi-langue, multi-site, workflow). Le choix d’un CMS doit tenir compte de ces fonctionnalités. Mais souvent le choix du développeur ou du prestataire est restreint par la connaissance d’un CMS. Il préférera choisir cette solution qu’il maîtrise plutôt que de s’aventurer dans l’inconnu.
J’ai ces dernières années eu l’occasion d’utiliser ou d’étudier un certains nombre de CMS : WordPress, Drupal, Ezpublish, Sonata, PrestaCMS, Liferay, Kuntsmann, VictoireDCMS. Les CMS les plus populaires (Worfpress, Drupal, ezpublish) ont tous une architecture et un code vieillissant…en clair l’horreur pour un développeur d’aujourd’hui. Si vous avez déjà eu à reprendre un projet sur CMS qui date vous comprenez de quoi je parle.
Framework Symfony 2 à la rescousse
Ezpublish et Drupal ont compris ces dernières années l’intérêt de migrer vers un framework orienté objet et de faire évoluer leur plateforme. Malheureusement à l’heure de cet article malgré les promesses de ces éditeurs la migration est loin d’être aboutie. Pour ezpublish toute la partie Back Office est encore gérée sous l’ancien noyau. La version ezpublish 6 full Symfony2 ne sortira pas avant l’été 2015. L’utilisation d’une version 6.0 étant risquée il faudra donc attendre 2016 pour espérer utiliser ezpublish v6 (initialement prévu dédut 2015). Pour Drupal le choix a été de ne pas adopter l’approche full stack qui consiste à utiliser le framework et développer des modules (bundles). Cette approche est pour ma part pas très adaptée pour deux raisons :
- le développeur doit se former à l’architecture propre au CMS
- les pages ou modules indépendants ne peuvent pas être codés « en Symfony2 »
CMS Symfony 2 full stack
Symfony2 est un framework très utilisé avec une communauté croissante. Nul doute que le nombre de développeurs formés à cet outils et à ses bonnes pratiques va encore augmenter ces prochaines années. Trouver un prestataire pour la maintenance ou l’évolution d’un projet CMS sur Symfony2 devient donc de plus en plus facile. En effet, un CMS développé avec un framework garantie une structuration du code et une compréhension par le plus grand nombre de l’architecture. Les CMS utilisant leur propre structuration comme WordPress nécessitent une connaissance spécifique au produit. Le moindre besoin de modification ou création d’extension nécessite un temps d’apprentissage et abouti le plus souvent par un code peu maintenable. Quand j’aborde un nouveau projet Symfony2 (CMS ou autre) la structure que je connais bien me permet de comprendre rapidement la plupart des composants. Il devient alors beaucoup plus aisé de se familiariser avec un nouveau CMS pour peu qu’il soit un peu documenté. Pour les prestataires, l’intérêt réside dans le temps réduit de formation sur le nouvel outil à partir du moment ou ladocumentation est complète et bien rangée (cf. les how-to rajoutés avec les versions successives @ezpublish).Pour un bon développeur le choix ne se résume donc plus dans la seule connaissance du CMS et de son architecture spécifique.
Aujourd’hui les projets web ne se résument plus en de simples sites vitrines. On a de plus en plus besoin de s’intégrer à un système d’information ou à une architecture tiers. Les nombreux bundles (=plugins ou module Symfony2) comme FR3DLdapBundle permettent de gagner un temps important vis-à-vis des besoins spécifiques à chaque projet mais finalement très courant.
Un petit exemple concret : pour ezpublish le Back Office est toujours développé sur l’ancien noyau (legacy). Pour les besoins d’un projet j’ai développé une médiathèque sur symfony2 et j’ai créé une extension sur l’ancien noyau pour pouvoir récupérer un média quand on édite par exemple un article. J’ai passé ¾ du temps à développer cette extension pourtant ultra simpliste et seulement ¼ pour la médiathèque côté Symfon2. Bon ok l’utilisation de la médiathèque sonata et l’extension tilleul m’a grandement aidé. Mais c’est ça aussi Symfony2, un grand nombre de librairies appelées bundles qui permettent de développer des fonctionnalités très rapidement.
L’intérêt d’utiliser un CMS n’étant plus à démontrer, beaucoup se sont essayés au développement d’un CMS avec Symfony 2. Peu de projets aboutissent car bien que cela paraissent assez simple, développer un CMS complet est une tâche complexe qui demande beaucoup de temps. Parmi tout les projets existants (voir la liste ci-dessous) je vais donc écrire des articles afin de présenter et tester les diffférents CMS Symfony 2 Full Stack.
Les projets CMS existant sur Symfony2
La liste des CMS sur Symfony2 est longue. Des bundles permettant de gérer du contenu naissent tous les jours. Cependant peu d’entre eux survivent dans les temps. Voici une liste de projets intéressants que j’ai utilisé ou testé (si j’en ai oublié, n’hésitez pas à le proposer en commentaire) :
- REDKIT CMS Bundle => aucune mise à jour depuis 2 ans (uniquement testé sur le site avec la génération). Projet KO
- SONATA => pas réellement un CMS (initialement pour gérer des CRUD)
- Symfony2 CMF => aide au développement de CMS (module de routing utilisé par ezpublish par exemple)
- Presta CMS => plus de mise à jour
- BackBee => non Full Stack
- Kuntsmaan
- Ezpublish
- VictoireDCMS
Parmi ces projets j’ai décidé de m’attarder et de comparer trois projets: Kuntsmaan, Ezpublish, VictoireDCMS. Mais pour le verdict il faudra attendre un prochain article 🙂 .
J’ai oublié votre projet ? Faite m’en part dans les commentaires.
