Pourquoi j'ai quitté Wordpress et comment je l'ai remplacé ?

Dans le cadre des jolis articles invités, le camarade blogueur Chris Lefevre évoque ses folles aventures avec le sulfureux CMS que nous croisons tous à longueur de pixels ...

Wordpress, c’était d’abord une petite révolution dans le monde des blogs. Pouvoir monter aussi facilement un site, choisir un thème parmi un nombre inimaginable et implanter des plug-ins pour n’importe quel besoin, sincèrement, la magie de l’Opensource n’a jamais été plus évidente qu’à travers ce CMS.

L'usage de Wordpress a largement dépassé celui d’un CMS de blog. Aujourd’hui, de nombreux sites professionnels sont développés sur cette plateforme. De mon côté, j’ai même réalisé des sites d’émissions télévisées tels qu’Un Dîner presque parfait ou La nouvelle stars sur ce CMS pour la télévision belge.

Mais son point fort est également son point faible, Wordpress est devenu le CMS le plus utilisé sur le web, si bien qu’il est le CMS le plus hacké également. La sécurité sous WP est un vrai cauchemar. Il faut un bon nombre de plug-ins pour protéger le CMS alors que les failles du CMS sont souvent ouvertes par des plug-ins, justement ou même des thèmes. Ha oui, certains thèmes gratuits intègrent du code malicieux.

Avec le temps, WP est aussi devenu de plus en plus complet et évidemment, de plus en plus lourd. Pourtant, il garde de nombreuses faiblesses. Sa gestion linguistique est catastrophique et en Belgique, les sites sont très souvent multilingues. Une partie de la traduction est associée au thème, une autre avec un plug-in qui multiplie les champs des formulaires. Trop orienté publication, il est peu évident pour gérer, par exemple, une Landing page imaginée par un designer créatif.

En fait, beaucoup de développeurs de sites sous wordpress vont préférer customiser un thème existant plutôt que d’en créer un à zéro. Ils vont souvent contourner la logique du CMS et associer des plug-ins plutôt que d’intégrer des fonctionnalités de galerie, de listes, d’agenda, de portfolio, de shopping directement dans le site.

Wordpress est finalement une machine à plug-ins qui se comporte de plus en plus comme une usine à gaz dès que vous en associez trop. Ajoutez l’obligation de maintenir tous ces plug-ins pour garantir la sécurité et vous vous retrouvez avec un outil de publication lourd et compliqué.

Le CMS sans DB.

De temps en temps, il m’est arrivé que l’on me demande si je pouvais mettre en place, à bas prix, des sites de quelques pages plus ou moins statiques. C’est à ce moment-là que j’ai pensé à chercher une solution plus légère, un CMS sans DB permet, notamment, de pouvoir configurer et composer le site sur mon ordi nateur et ensuite tout pousser sur un hébergeur mutualisé via FTP. Bien plus simple que l’installation et configuration d’un WP qui en plus va nécessiter des modifications dans la DB si les pages contiennent des images ou des liens qui pointent vers « localhost ».

Mais après en avoir testé quelques-uns, j’ai compris que développer mon propre CMS sans DB serait une bonne idée. Il serait mieux adapté à mes besoins.

J’ai donc construit un CMS qui devait, d’une part, avoir une interface de publication moderne sous bootstrap avec des éditeurs de textes complets. Il devait s’adapter à plusieurs types de projets, et pour ça, j’ai imagé un concept de modèles inspiré des systèmes MVC que l’on trouve dans des CMS tels que Symphony tout en restant très simple à configurer. Le modèle sert donc à définir la structure des données pour la base de donnée sauvée dans des fichiers .json, les champs, listes, fonction d’upload en DB, et la couche de vérification des données pour la sécurité.

L’un des points forts de cette mécanique est de pouvoir modifier la structure des données à tout moment.

Swalize est né : un CMS flexible qui supporte n’importe quel type de contenu et qui pourra s’attacher à un site réalisé en HTML avec une totale abstraction des fonctionnalités du CMS. En effet, le CMS ne gère pas le thème, le design, l’affichage, mais uniquement les données et assets.

En fait, ce système fonctionnait si bien que j’ai voulu l’améliorer avec deux fonctions stratégiques :

Pour commencer, la traduction simplifiée. C’est une table de traduction sauvée en .json accessible avec une méthode de class dans le template du site. En encodant la totalité des textes de cette façon $sw->_(‘this is my text’); chaque traduction est insérée automatiquement dans l’admin. Celà signifie donc que lorsque j’insère du texte dans le template, je n’ai pas à me soucier de son insertion dans une collection, tout est automatisé et c’est le client qui s’occupera de traduire le site depuis son admin. Cette intégration est inspirée de Gettext.

Viennent ensuite le blog et ses déclinaisons (produits, emplois, membres, vidéos, …). Alors là, c’était un choix important. Insérer un blog et ses équivalents dans le CMS, c’était risquer de le rendre plus complet et donc plus complexe. C’est un peu vrai, j’ai dû souvent faire des concessions pour la partie blog, produit, mais le CMS a évolué progressivement et il m’a au final permis de réaliser rapidement des développements presque impossibles avec Wordpress sans une collection de plug-ins.

Le passage de Wordpress à Swalize

Si j’ai ici un CMS qui est plus flexible que WP pour créer un site vitrine sur mesure, il n’est pas pour autant un CMS orienté publication de news. À force de développer sur autre chose que du Wordpress et après de nombreux problèmes de sécurités, j’ai décidé de chercher un CMS moins connu. J’aurais pu prendre Drupal, mais c’est aussi un CMS assez lourd à intégrer. J’étais plus attiré par les CMS en NodeJS comme Ghost.

Et oui, pour moi, NodeJS est le successeur logique de PHP et j’aime beaucoup ce langage. Un peu déçus lors des tests.

Entre temps, j’avais réalisé quelques progrès avec la partie news du site, surtout avec la version 2.0 de Swalize. Elle s’appuie désormais sur un moteur SQL/Json . Concept original qui me permet de simuler du noSQL sur un hébergement LAMP classique.

Le Moteur Sql sert d’index pour pouvoir réaliser des recherches rapidement, ordonner, trier. Les objets articles, catégories, produit, portfolio, etc. seront toujours sauvés dans des fichiers json en suivant les modèles prédéfinis. Par défaut le moteur SQL est Sqlite, mais il peut également tourner sur MySql. Le stockage de données en json permet d’éviter les jointures et donc de gagner en rapidité.

C’est bien beau, mais est-ce qu’un CMS avec un moteur en grande partie noSql est performant pour un site avec beaucoup de contenu? Et c’est là que j’ai décidé de développer un script d’import des articles de mon blog vers ce nouveau CMS. 10 ans d’articles, un nombre suffisant pour tester la fiabilité du système et oui, ça fonctionne et même très bien. le moteur SQL/Json de Swalize est la brique qui me manquait pour pouvoir abandonner Wordpress.

Pourquoi je vous explique tout cela? Non, je ne vous encourage pas à passer sur Swalize car j’ai décidé de le sortir de Github tant que je n’ai pas une documentation et des exemples complets pour l’utiliser.

Non, mais je pense que Wordpress n’est peut-être pas VOTRE solution, c’est juste devenu la solution par défaut. Créer la sienne n’est pas forcément compliqué lorsque l’on sait coder. En choisir une autre non plus. Il sort très régulièrement de nouveaux petits CMS sympas comme Swalize.