Statamic, un CMS à fichiers plats
Avec son nom rigolo, Statamic est un sympathique CMS à fichiers plats mu par Laravel. Contrairement à son concurrent le plus direct, October, Statamic nous apparaît plus abouti. Voyons voir.
D’abord, rappelons ce que sont les CMS à fichiers plats (flat files). Ils n’utilisent en principe aucune base de données. Toutes les données reposent sur de simples fichiers textes faciles à comprendre. On n’a donc besoin que d’un serveur roulant la dernière mouture PHP. Puisqu’il n’existe aucune requête vers un serveur de base de données, le temps de réponse devrait être très rapide. Autre avantage, tant le code que le contenu du site peuvent être archivés dans un système de versionnage comme Git. Ce qui sera affiché sur le web est des pages dites statiques (contrairement aux pages dites dynamiques, construites à la volée, après plus ou moins de requêtes vers une base de données).
Il existe de nombreux CMS de ce type. On peut en voir des listes ici et là. Conçu en 2012 par l’entreprise américaine Wildeborn, Statamic n’est pas gratuit. Il en coûte 199 USD par site. On peut toutefois développer en local gratuitement tant et aussi longtemps qu’on ne met pas en ligne.
Installation aisée, interface sobre et efficace
D’entrée de jeu, l’installation du CMS est simple, tout comme sa documentation. La compagnie offre un cours complet sur YouTube. L’humour n’est jamais très loin ; l’équipe est jeune et répond rapidement aux questions sur Slack.
L’installation par défaut vient avec un premier thème et quelques pages. Cela permet de se familiariser vite avec l’outil.
Redwood, le thème installé par défaut par Statamic. Le CSS est construit avec SASS.
Si on veut débuter avec un site vierge, rien de plus simple. Une série de commandes en mode terminal permet de tout construire, du thème aux champs associés pour chaque page. On peut connaître la liste des commandes en tapant please. Ainsi, php please site:clear vide entièrement le site, même le thème. Afin de reconstruire celui-ci dans sa plus simple expression, on tape : php please make:theme. Pour créer des usagers : php please make:user, etc.
Un extrait des commandes de Statamic sur terminal.
L’interface est sobre, plaisante à utiliser et on s’y retrouve très facilement. Trois grandes sections seulement : Content, Tools et Configuration (une version complète française de l’interface vient d’arriver au moment d’écrire ces lignes).
L’interface d’administration permet une gestion dépourvue de cachettes. Tout est clair.
Parcours de l’interface
Il existe deux grands types de contenus, les pages et les collections (textes classés comme un blogue). Au moment de la création du contenu, l’usager se voit offrir des modèles (templates) polyvalents (voir plus loin). Cette section peut prêter à confusion, car elle permet d’intégrer des collections. Voyons donc plutôt la section Pages comme l’arborescence du site.
La section des pages. On y voit deux collections qui se différencient des autres pages par le menu latéral permettant d’ajouter des enfants.
L’édition d’une page. Ici, il n’existe que le titre et le contenu (en syntaxe markdown). L’ensemble des champs est déterminé par le modèle que l’on choisit au moment de la création de la page. Si on veut par la suite changer de modèle, parce qu’on s’est trompé, il faudra modifier le fichier plat résultant. Quant aux collections, elles groupent des pages sous un modèle bien précis. On peut y créer des contenus aux champs complexes comme pour un blogue, ou des listes de toutes sortes. Je passe les détails de l’éventail des possibilités de cette fonctionnalité.
La section des collections. Dans l’exemple, deux collections existent.
La collection « blog ».
L’édition d’une page de collection. On remarquera dans l’exemple ci-dessus que le champ de contenu n’est plus en markdown, mais bénéficie d’un éditeur WYSIWYG complexe : Bard.
Une jolie addition est la prévisualisation en direct de l’édition. On peut ainsi offrir à l’utilisateur lambda une interface conviviale, ce qui fait de Statamic une belle alternative à Wordpress.
La prévisualisation dans Statamic.
Outre les types de pages, Statamic possède une gestion des médias, un système taxonomique, un utilitaire très bienvenu de création de formulaires, etc. J’ai particulièrement aimé la section média et surtout la possibilité de choisir un point focal pour chaque image. L’interface nous montre ainsi la photo dans plusieurs contextes d’affichage selon le point focal retenu. Le recadrage se code dans les modèles (template) de page en utilisant la librairie intégrée Glide.
La section médias.
La gestion d’une image.
Choisir le point focal assure un rendu toujours significatif.
La structure des fichiers
À première vue, la structure des fichiers suit le même désir de simplicité. Le contenu est dans content, le thème dans themes.
L’arborescence de Statamic.
La syntaxe par défaut du texte est le Markdown, d’où l’extension « .md » des fichiers. Il est possible de toutefois de régler pour la syntaxe plus courante HTML. Nous y reviendrons.
Les types de pages. Pour le type « page », le texte traduit est placé côte à côte.
Comme il s’agit de fichiers plats, on peut très bien écrire les pages dans son éditeur préféré en autant qu’on les numérote convenablement. La syntaxe du fichier est un mélange de YAML et de Markdown (ou HTML selon le réglage).
Il est facile d’écrire un fichier de contenu. On commence par l’en-tête de métadonnées entre les symboles « --- », ce qui comprend le titre, le modèle de page et le groupe de champs utilisés. Par la suite, on insère le contenu du champ... « content ».
Autre exemple de composition de page. On remarque la notation YAML de la partie supérieure de l’en-tête. Dans cet exemple, il y a donc le titre, le sous-titre, l’image par défaut (il s’agit d’un article de blogue), la taxonomie. L’identifiant unique de la page (id) est ajouté automatiquement par Statamic.
Les modèles de page ou « Templates »
La construction d’un modèle se divise en deux. Ainsi, il y a les maquettes générales (layouts). On y trouve généralement la structure HTML de base. Par défaut, il existe deux layouts : default.html et feed.html. Une variable template_content servira d’appel au contenu à proprement parler.
L’arborescence des maquettes.
La variable « template_content » appelle l’ensemble du contenu issu des champs choisis pour la page.
Dans le « template », la mise en page des champs.
Et d’où proviennent ces champs ? Des « fieldsets » qui résident dans le répertoire Settings.
Chaque fieldset est une recette de champs (« fieldtypes » dans le langage Statamic) inscrite en YAML. La simplicité (ou la complexité, c’est selon votre appréciation) de ce système permet de configurer en dehors de l’interface un paquet de recettes que l’on peut partager entre projets comme d’autres se transmettent des recettes de muffins.
Le répertoire « fieldsets ».
Une recette de champs.
Le multilinguisme
Comme il a été mentionné plus haut, les fichiers traduits résident dans le même répertoire que le texte original. Il faut tout de même créer, en dehors du répertoire content, un répertoire pour chaque langue et qui sera nommé selon le code de langue. Ces répertoires sont à la racine et contiennent le même fichier index.php que pour le site de base. Il faut ensuite adapter les variables à l’intérieur de ce fichier. Le concept de dupliquer un fichier index.php est un peu étrange et semble aller à l’encontre de cet autre concept cher aux programmeurs, le DRY (Don’t Repeat Yourself). Il faut aussi paramétrer le fichier principal de configuration, system.yaml.
Le fichier principal de configuration où on définit les langues.
Le répertoire « fr » doit être créé à l’extérieur du contenu (placé dans le répertoire « site »).
Autre irritation : on remarquera dans l’avant-dernière image que la racine qui contient la langue anglaise ne possède pas « /en » dans l’URL. Bien que l’on puisse en théorie ajouter cette particule, le système brise aussitôt. Il doit exister une entourloupette, mais il y a certainement un travail à faire de ce côté pour rendre le multilinguisme plus naturel.
En conclusion
J’ai l’impression de n’avoir fait qu’effleurer le CMS. Je me suis attardé à en décrire sa structure pour montrer la rigueur sur lequel est construit l’édifice. Les concepteurs de Statamic ont réussi à allier simplicité et utilisabilité.
Statamic est basé sur Laravel, la programmation peut donc aller au-delà d’un site ordinaire. On peut utiliser une base de données pour les sites plus complexes où les pages sont beaucoup trop nombreuses. Les fichiers plats ont leurs avantages qui se résument probablement à la capacité de « versionner » le contenu. Toutefois, les CMS usant de base de données sont depuis longtemps munis de moteurs de rendu statique et, il faut bien l’admettre, un jour où l’autre, quand on migrera son contenu dans un autre CMS, on sera bien content de pouvoir recourir à une requête d’exportation. Pas aussi simple avec une multitude de petits fichiers... Encore une fois, tout est possible en informatique et il s’agit de programmer les bons outils. On est avec Laravel après tout !
Statamic souffre comme bien d’autres systèmes de ce genre de ne posséder qu’une bien petite part de marché et de ne pas avoir non plus de portail de modules tiers. On nous promet dans le pied de page du site, un prochain Marketplace.
Bien qu’il se targue d’être une solution plus sûre que Wordpress, Statamic exige le recours d’un programmeur ou d’un artisan doué du web, car l’interface ne couvre pas tout. Pouvoir tout construire à partir de fichiers YAML ou MD est un attrait en soi, mais ce n’est pas donné à tout le monde. Le CMS est un bon choix pour des sites simples, les vitrines. L’administrateur devra être confortable à jouer dans les fichiers eux-mêmes. Le CMS est très polyvalent et je peux comprendre qu’on aime programmer avec cet outil. Il peut, par exemple, être un bon point de départ pour une programmation plus poussée avec Laravel.
