Cas d’étude pour un projet : pourquoi remplacer Wordpress ?
La réalisation d’une application pour un nouveau client a été l’occasion d’affiner un système de gestion de contenu de nouvelle génération.
La vieille garde
Wordpress bien qu'efficace et très répandu est devenu au fil du temps victime de sa complexité. Codé en PHP à l'aube de l'ère des blogs, c'est maintenant un mastodonte, difficile à manœuvrer dés que le projet dépasse une certaine taille ou incorpore des modules exotiques. De plus, la myriade de thèmes disponibles, auparavant abordables, a développé un modèle de paiement récurrent par mois, ce qui peut être un inconvénient pour certains clients.
La plupart des thèmes sont très cadrés et ajouter des sections personnalisées demande de comprendre la logique du code utilisé par chaque thème. Ceci peut ralentir considérablement la modification d'un thème, puisqu'il faut s'adapter au style de code de l'auteur. L’évolution éventuelle du thème risque de mettre à mal la compatibilité avec vos modifications. C'est aussi, du fait de sa popularité, une cible de choix et l'administrateur doit scrupuleusement installer les mises à jour pour parer à toute faille de sécurité.
Il existe plusieurs alternatives, les plus connues étant :
Joomla est aussi un vétéran dans le domaine des CMS. Basé sur du code PHP, il comporte lui aussi une myriade de modules et de thèmes, mais son interface d'administration bien qu'ayant évoluée est toujours intimidante. Sa complexité nécessitera un temps d’adaptation au client pour son exploitation.
Django est plus modulaire et est codé en Python. Il permet d'interfacer facilement un grand nombre de modules de développeurs externes. Il partage les mêmes défauts que Joomla sur la complexité et son interface d’administration austère demande beaucoup de configuration.
Ghost utilise NodeJS. Il est plus récent et moderne, son interface est exemplaire de simplicité. Les articles peuvent être directement édités à même la page. Il s’agit principalement d’une application de blog facile d'utilisation. Un de ses handicaps est l’absence de gestion multilingue, en effet il ne gère qu’une seule langue à la fois et ne permet pas d’avoir plusieurs versions du site. Ce point faible peut s’avérer rédhibitoire pour un grand nombre de clients. Ghost est principalement un moteur de blog et rien n'est vraiment prévu pour le faire évoluer au-delà de cette fonction.
Du sang neuf
Nous avons donc cherché des applications plus récentes. Principalement en NodeJS car cela permettait d'avoir un frontend et un backend codé dans le même langage.
Apostrophe a alors attiré notre attention, un CMS avec une interface tout a fait décente. Le point négatif était un manque de popularité qui limitait le nombre de modules et de thèmes. Il existait une option payante qui permettait de gérer plusieurs sites avec la même instance et certaines options d'administration avancées comme la gestion des autorisations pour les utilisateurs.
Mais la version de base convenait à notre utilisation. L'interface d'administration était intégrée dans la page et facilement modifiable depuis le code via des fichiers de configuration par module. Il a alors été très facile de rajouter un champ, un widget ou un module.
Le système de base permettait de créer des modèles avec Nunjunks, un port de Jinja2. En utilisant ce système, les thèmes étaient liés au CMS. Cette solution aurait été problématique car liant le design général à ce backend.
La solution visait à rendre ce design indépendant du backend en le découplant de la partie frontend du CMS. Le backend devenait alors un système de gestion de contenu "headless" et il était possible d’y adjoindre la partie frontend de son choix.
AstroJS a été sélectionné car il est relativement simple à mettre en place et qu'il existait déjà un adaptateur pour Apostrophe. Il gère nativement Tailwind qui facilite la mise en forme et permet d'incorporer facilement des parties dynamiques gérées par les "iles" séparant les parties dynamiques et statiques.
Le stack final retenu était donc :
Backend: Apostrophe
Frontend: Astro
Reverse proxy: Nginx
Base de données: MongoDB
Réécriture de l’adaptateur
Il a fallu envisager un travail sur l'adaptateur entre Astro et Apostrophe car celui-ci ne comportait que le strict minimum.
Le module image de l'adaptateur s’est révélé insuffisant. Il ne gérait pas les différentes tailles générées par le CMS et ne prenait en compte aucune option. Il a été nécessaire d’ajouter toutes ces fonctions en se basant sur le modèle présent dans le CMS. Il faut noter que nous n’avions pas accès aux fonctions utilitaires du backend utilisées dans ses modèles. Cela nous a amené à les réimplémenter dans le frontend.
Evolution du CMS
Installation des modules
Les modules complémentaires existants nous intéressant on été installés, notamment le module SEO.
Mise en place d’un mode maintenance
Un mode maintenance est indispensable pour indiquer que le site subit une mise à jour ou une réparation et restreindre l'accès des utilisateurs. Ce mode interdit l'accès au contenu du site tout en affichant une page d'information. Ce mode a été ajouté au module global du CMS et a permis de pointer vers une page intégralement éditable dans l'interface.
Création d’une barre de navigation gérant les sections
Le site étant divisé en plusieurs sections, la navigation ne pouvait être commune à tout le site. Un module de navigation comportant des sections a été implémenté autorisant autant de barres de navigation que de sections. Plusieurs modèles de pages gérant les sections ont aussi été réalisés pour permettre un bon niveau de personnalisation.
Développement d’un module d’optimisation d'image
Le CMS gère les formats d'image modernes, mais ne fait pas de conversion automatique pour les optimiser. Il a fallut le modifier. Les images de type jpeg sont ainsi automatiquement converties en webp et avif. Le frontend indique au navigateur les images disponibles et celui-ci charge la plus appropriée.
Mise en production
Nginx a été utilisé comme proxy inverse avec un server Node. Nginx est devenu l'accès public qui servait de proxy à l'application frontend Astro. Cette dernière interagit avec le backend Apostrophe localement pour accéder au contenu. L’administration des deux applications (CMS, frontend) est faite via PM2 qui les convertit en services reconnus par systemd.
Conclusion
L'installation et l'implémentation d'une solution CMS n'est pas toujours évidente et doit toujours suivre les impératifs du client. Si celui-ci veut une interface simple, un design facile à modifier et une bonne extensibilité, une solution à base de NodeJS est séduisante. Cela limite les langages de programmation impliqués dans le projet et simplifie la gestion des applications. Nous avons sélectionné Apostrophe mais il y a d'autres choix de CMS NodeJS disponibles comme Strapi ou Keystone.
Cette personnalisation permet de s’adapter aux cahier des charges spécifique à chaque client.