Quand lightweight signifie son contraire : les CMS file-based

Note préalable

Ceci est plus un billet d’humeur qu’un comparatif objectif. Il a été écrit pendant une nuit où je cherchais désespéremment un CMS simple, après avoir goûté aux déceptions que sont Grav et Phile.

Oh, et j’entends bien entendu par backend toute interface d’administration permettant de gérer le contenu affiché en frontend. Il s’agit ici plus d’éviter les longues répétitions.

Préambule

J’adore quand quelque chose de simple devient complexe… Les CMS file-based, j’aime bien. C’est facile à mettre en place, ça s’installe partout, et les sauvegardes se font rapidement.

Habituellement, j’utilise pour ça PluXML. C’est une valeur sûre. Pour les sites statiques, sans blog par exemple, j’utilise plutôt GetSimple que je trouve plus rapide à appréhender pour un client (ajouter une page se fait en un clic, on modifie le menu en glissant-déposant, là où il faut une manipulation tirée d’un autre âge pour PluXML sur ce point).

Mais j’ai voulu voir un peu la concurrence, trouver encore plus simple, si possible avec un éditeur Markdown et sans fioritures (si je veux un blog ou un flux RSS, ce doit être un plugin).

Eh bien, c’est un peu le parcours du combattant.

Le but

Disons que je cherche un CMS avec une administration, pour deux raisons.

La première, c’est que si les CMS sans backend sont intéressants dans le cadre d’une utilisation d’un contenu édité en groupe (cas d’une documentation mise sur serveur git, par exemple) ou seul sur une même machine, ils sont bien moins intéressants quand on est sans cesse en déplacement d’une machine à l’autre ou si le groupe en question n’a pas accès au serveur.

Un exemple parlant : lorsque je suis sur une autre machine que la mienne, pour prendre des notes, j’aime bien utiliser mon Shaarli en mode privé. Ainsi, je ne laisse pas de trace chez mon hôte, et j’évite de déconnecter son Facebook/Gmail/etc. pour simplement prendre quelques notes. C’est impossible à réaliser avec un CMS sans backend.

La seconde raison, c’est que si je voulais faire un site sans backend, autant le faire en local, tout en HTML/PHP ou avec les outils qui vont bien (Hugo je pense à toi). Le seul intérêt des CMS flat file sans administration, c’est de mettre l’accent sur le contenu, en simplifiant l’écriture de celui-ci à sa base : un simple écrit dans un fichier texte.

Au cas où, StaticGen liste les générateurs de site statique, et code.makery a écrit un article intéressant sur le sujet : Making Content Editor and Web Developers Happy Again.

Durant les recherches effectuées pour écrire cet article, je suis également tombé sur Sculpin, un générateur de site statique en PHP fonctionnant de manière similaire à Composer. Utile si vous ne voulez pas vous farcir du Ruby, du Node.js, du Python ou du Go…

Comparatif subjectif

xkcd - Standards

Prenons comme base de comparatif PluXML. PHP, 200 fichiers, taille nu 1,1 Mo. Template PHP. Flux RSS, blog, pages statiques, pagination, commentaires, plugins, panneau d’administration, multi-utilisateurs, pages privées, gestionnaire de fichiers, multi-langues, thèmes, sitemap… Bref, assez complet.

Pour info, encore à des fins comparatives, WordPress : PHP + MariaDB, 1330 fichiers, 20,9 Mo. Template PHP. Niveau fonctionnalités, assez proche de PluXML, auxquelles on peut ajouter : plus de plugins, plus de thèmes, plus grande communauté, quick-post, et quelques améliorations au niveau typographie…

Note sur la méthodologie

Pourquoi regarder le nombre de fichiers ? Tout simplement parce qu’il est bien plus simple de comprendre comment fonctionne un code qui tient en 8 fichiers qu’en 2500. Si comprendre et pouvoir maintenir un minimum le code que vous faites tourner sur votre serveur ne vous intéresse pas, pour moi ça a son importance.
Pourquoi regarder la taille ? Sur certains hébergements, ça a son importance. Ici, cela va surtout servir à démontrer un point : ce n’est pas en faisant plus de lignes de codes que vous aurez plus de fonctionnalités, il semble même que ce soit l’inverse…
Le template est donné à titre indicatif uniquement. Généralement ils ne sont guère complexes.

Grav

Je commence par Grav, très eye candy, sympathique. PHP, 1540 fichiers, taille nu 8,9 Mo. Template Twig.

Déjà il y a quelque chose qui cloche. Avec un poids pareil, on pourrait s’attendre à trouver plus de fonctionnalités que PluXML. Eh bien… Non. Ça, c’est juste pour parser des fichiers Markdown et les afficher en un site statique (ou un blog, en jouant avec les sous-dossiers).
Vous voulez un flux RSS ? Ajoutez 300 ko.
Vous voulez un sitemap ? Ajoutez 10 ko.
Etc. On se retrouve avec bien 10 Mo pour à peine le tiers des fonctionnalités d’un CMS qui en fait 10 fois moins… Et le meilleur ? Avec tout ça, il n’y a même pas d’administration ! Certes, c’est le principe des flat file CMS, mais on aurait pu s’attendre à ce qu’un plugin soit présent pour justifier tout ça…

Donc je surveillerai Grav, mais pour le moment il me semble bien trop volumineux pour pouvoir clamer être « léger ».

Dropplets

Dropplets est un blog. Rien de plus. PHP, 47 fichiers, 1,4 Mo. Template PHP.

Pas de flux RSS, pas de plugins, mais il a un panel d’administration, lui ! Celui-ci se résume à quelques variables habituelles (mot de passe, nom du site…) et un formulaire d’envoi de fichier. Vous devez donc écrire en local avant d’envoyer via le panel. Concept intéressant, auquel je vois deux bémols : 1. Il n’y a pas possibilité d’envoyer une image ou un quelconque media par le panel, donc obligation d’utiliser autre chose pour le faire. 2. Dropplets renomme le fichier envoyé en utilisant la première phrase. Ça m’a valu de ne pas pouvoir supprimer ces fichiers sur mon FTP pour une raison que j’ignore. Il a fallu que je passe par la console SSH pour arriver à faire un rm -rf propre. Pourquoi ne pas utiliser un timestamp, comme tout le monde ?

Donc minimaliste, et aucune possibilité de modification…

Phile

Phile est amusant. Il commence comme un fork de Pico. PHP, 710 fichiers, 2,0 Mo. Template Twig.

Juste un site statique. Comme pour Grav, on peut jouer avec les sous-dossiers pour arriver à faire un blog. Et comme pour Grav, tout se passe dans les plugins. Là où ça devient hilarant, c’est sur le plugin d’administration (PhileAdmin).

D’une, il n’y a que son créateur qui semble arriver à le faire fonctionner. De deux, que l’on essaie de l’installer avec Composer (méthode recommandée par l’auteur) ou manuellement, on se retrouve avec un plugin qui pèse 30 Mo. Oui, vous avez bien lu. 30 Mo pour un backend qui ne sert qu’à ajouter, modifier ou supprimer des pages. Oh, et l’éditeur Markdown pour ce panel n’est même pas inclut, c’est un plugin supplémentaire ! Bien entendu, aucun support pour les images et autres médias en administration… Là je trouve que c’est du grand art. La faute à des dépendances Symfony qui semblent indispensables pour l’auteur, quand du code PHP pur lui donnerait le même résultat en quelques 300 Ko maximum.

Donc Phile, c’est bien, mais encore une fois il faut passer par la case FTP/Git.

Pico

Pico est souvent cité comme une référence. PHP, 909 fichiers, 2,6 Mo. Template Twig.

Site/Blog qui se dit « simple & blazing fast ». Tellement « simple » qu’il faut :

  1. Cloner le dépôt git ou télécharger l’archive,
  2. Télécharger Composer et le lancer,
  3. Envoyer le tout sur le serveur.

Parce que proposer une release zippée avec toutes les dépendances, c’est so-2012 …

Encore une fois, tout se passe dans les plugins. Et là, pour le coup, rien à dire. Le panel d’admin fonctionne, il fait 1,1 Mo, mais avec ça vous avez un file manager, un upload des images et un éditeur Markdown. M’enfin, si vous voulez, il y a aussi possibilité de passer par Draft.

Kirby

Kirby est génial. PHP, 670 fichiers, 5,6 Mo. Template PHP.

Backend intégré d’office, système de template ultra-simplifié, exactement de quoi tomber amoureux… Si ce n’est qu’il est payant (entre 15 et 79€ selon l’utilisation).

Stacey

Stacey est très léger. PHP, 150 fichiers, 858 Ko. Template perso simple.

Pas de backend, et n’est plus maintenu depuis 2 ans, mais je voulais en parler juste pour montrer que parser du Markdown en un blog avec flux RSS, sitemap, pages statiques, cache, pagination, pouvait se faire en-dessous du mégaoctet.

Yellow

Yellow reste léger. PHP, 47 fichiers, 347 Ko. Template PHP.

Le projet a l’air prometteur, souvent mis à jour, bien qu’un peu limité au départ. De base, parse le Markdown pour en faire des pages, avec possibilité de les éditer directement depuis le site web (malheureusement, juste du texte, aucun support pour les images de ce côté-là). Assez nu, mais est disponible dans 12 langues et les plugins foisonnent (du flux RSS à l’intégration Youtube en passant par SmartyPants ou FontAwesome).

Simple, net, efficace, mais vraiment sec à l’utilisation.

Automad

Automad. PHP, 218 fichiers, 6,6 Mo. Template perso simple à utiliser mais incroyablement profond.

Cache, tags, sitemap, galerie, plugins. Et il y a un backend ultra-simple d’utilisation pour le client lambda (drag&drop des images, par exemple), ainsi que la possibilité d’avoir plusieurs utilisateurs ! Aurais-je trouvé ma perle rare ?

Peu de plugins pour le moment, pratiquement pas de communauté, par défaut les utilisateurs ont tous des droits d’admin. Bien qu’il soit plus complet et léger que Grav, sa taille relativement importante n’est toujours pas justifiée.
EDIT : On réalité, le contenu par défaut prend pas mal de place. Une fois mis à nu, Automad se rapproche plus des 3,9 Mo.

Parvula

Parvula ne semble pas fonctionner. PHP, 85 fichiers, 584 Ko. Template PHP. Enfin, quand je dis qu’il ne semble pas fonctionner, c’est qu’il faut modifier le .htaccess en changeant RewriteRule ^(.*)$ index.php/$1 [L] par RewriteRule . index.php [L].

Ainsi, on évite les Page not found. L’administration est simple mais efficace, divisée en deux parties : à gauche l’éditeur Markdown, à droite son résultat WYSIWYG. Possibilité d’ajouter, de modifier ou de supprimer des pages, mais c’est tout. Vraiment dommage qu’il n’y ait rien pour les images. Ne semble pas gérer les sous-dossiers, donc difficile (mais pas impossible) d’en faire autre chose qu’un CMS pour site statique (et là-dessus, il bat Pico au niveau de la simplicité d’utilisation et de la légèreté). Néanmoins, aucun plugin, aucune communauté.

Oh, et sans pêcher par excès de chauvinisme, le développeur semble être français. À garder sous le coude pour de petits sites très simples.

Et tous les autres

Des CMS sans base de données, il en existe des paquets. J’en ai même codé un, fut un temps, c’est dire comme c’est simple à réaliser.

Ce comparatif n’est pas exhaustif, et n’a pas prétention à l’être. Parmi les outils que j’ai écarté, certains méritent une mention :

Étude de cas

Prenons maintenant un exemple concret.

Pour un projet perso, j’ai un cahier des charges comme suit :

Thème simple HTML5 responsive support mobile

Pas de titre sur les billets

Pages statiques affichées comme un blog sans commentaires

2 utilisateurs différents, aucun des deux n’ayant accès au FTP ou au dépôt Git du serveur

2 styles différents selon l’auteur

2 modes de tri (ascendant/descendant par date)

trois possibilités d’écrire un article :

  • manuellement (Markdown) -> drag & drop ou éditeur
  • envoyer une photo -> drag & drop ou bouton classique
  • whiteboard -> écrire quelque chose au stylet qui est converti en image (vraiment optionnel)

Possibilité de se connecter en cliquant sur un lien Répondre

Syndication RSS/Atom

Donc, grosso modo, un Tumblr à deux collaborateurs. Ça parait bête comme chou, dit comme ça, non ?

On se retrouve donc avec des CMS qui font entre 1 et 2 Mo capables de réaliser ce que d’autres pesant entre 3 et 9 Mo sont incapables de produire. Le problème étant que les premiers ne sont pas aussi simples d’utilisation que les seconds.

Conclusion

Simple, les CMS file-based ? C’est mitigé. Ceux qui stockent leurs données en XML, plus anciens, semblent être bien plus complets et rapides à déployer, lorsque ceux basés sur du Markdown se concentrent sur la vitesse au détriment de fonctionnalités de base.

Si tout ce dont vous avez besoin, c’est d’un éditeur Markdown, quitte à devoir coder vos propres plugins, regardez du côté de Pico, Parvula et Automad.

Si au contraire vous avez besoin de fonctions « exotiques » telles qu’une barre de recherche, une syndication RSS, une pagination ou même le support des hébergements sans mod_rewrite, tournez-vous vers PluXML, Nibbleblog, GetSimple.

Maintenant, pour aller plus loin, il serait intéressant de jeter un œil aux divers scripts PHP qui, tenant en un seul fichier, permettent l’envoi de fichiers et leur gestion sur l’hébergement qui les accueillent. Je suis certain qu’en travaillant un peu là-dessus, on pourrait arriver à une interface d’administration flexible et portable d’un CMS à l’autre. Il ne manque qu’un dossier admin potable à Pico, Phile, Grav, Dropplets, Stacey, pour qu’on puisse réellement les considérer comme des CMS modernes. En somme, one backend to rules them all.

Note finale

Cet article a été écrit avec l’éditeur Markdown de Parvula, je n’ai eu qu’à récupérer le HTML généré pour le coller dans PluXML. Je pense l’adopter pour de petits projets, lui au moins il est léger…