October, un CMS pour les geeks

La « philosophie » ambitieuse du CMS peut être lue ici et là. En voici l’élément clé :

Le développement web est en fait très facile, beaucoup de gens connaissent déjà les bases du HTML. Les sites web sont également simples par nature, ils sont basés sur des fichiers texte. Quelque part sur la route, les gens ont oublié cela. La vision que nous avons est de rendre le développement web [de nouveau] simple et de prouver que faire des sites web n’est pas une science compliquée, c’est quelque chose pour tout le monde. Nous voulons revenir à l’essentiel, au point de départ, en conservant les choses évidentes, naturelles et utiles.

On sourcillera probablement face à une telle déclaration, car s’en tenir de nos jours au langage HTML est un pari risqué. Le web demeure encore, sinon davantage, l’affaire des spécialistes. Pour preuve, la popularité de sites tels Wix, Wordpress.com, Weebly, Shopify, etc. qui répondent à cette nécessité d’éloigner l’utilisateur du moteur sous le capot (là où même les mécaniciens du web en perdent leur latin). Cela dit, allons voir ce qu’October a à offrir à ceux et celles qui connaissent les bases HTML.

Une interface élégante

Après une installation sans faille et bien faite, on se voit présenter l’arrière-boutique (backend), qui se divise en cinq sections de base. Selon les permissions qui lui sont accordées ou les modules installés, l’usager pourrait voir autre chose.

La partie CMS est le nerf de la guerre pour la programmation. On y trouve les pages, les partials, les layouts, le content, les médias et les composantes. (Cliquez sur les captures d’écran pour en voir une version plus large.)

On peut observer ici le soin apporté à l’interface. C’est élégant, bien segmenté et les programmeurs peuvent intervenir directement dans le code.

La partie Media est le dépôt usuel d’un CMS pour les fichiers, les images, les vidéos, les fichiers audio, etc.

La partie Pages est la section de contenus réservée à l’usager administrateur. Elle comprend les sous-sections Pages, Menus, Content et Snippets. Mais, me direz-vous, on a déjà vu une section Pages dans la partie CMS ? Exact ! Dans les deux sections, on voit les pages différemment. Là où ça se complique est quand vous installez un module de blogue. Celui-ci aura son propre onglet. Du coup, le contenu se voit attribuer deux sections…

La partie Pages possède des sous-sections identiques à la partie CMS. À ne pas confondre. La section de code a disparu au profit d’onglets.

La partie Settings groupe tout ce qui est réglage tant pour les permissions que pour la plomberie usuelle d’un CMS.

Si la plupart de ces sections héritent d’une belle interface, on se pose au second regard des questions sur les choix esthétiques qui nuisent à la compréhension et même à l’utilisation du CMS.

Notons par exemple cette grosse bande orange qui contient le titre d’une page et son chemin. Elle occupe une place indue et, pour des noms très longs, on perd le nord. La gestion des langues est aussi compliquée. Chaque champ est accompagné d’un indicateur de langue si bien qu’on peut travailler à la fois sur une partie française qu’une partie anglaise au point qu’on mélange rapidement le tout.

Une interface soignée, agréable à utiliser, mais qui souffre d’un bandeau de titre énorme et des sélecteurs de langue qui fonctionnent indépendamment.

Les fichiers plats à la base du CMS

October est un CMS utilisant un système de fichiers plats (flat files). Cela signifie que tout le contenu est conservé dans des fichiers textes sur le serveur. Rouler un site mû par October ne nécessite donc pas une base de données pour le contenu. Cependant, le CMS en a besoin d’une pour ses opérations internes, notamment pour la gestion des usagers et de leurs mots de passe. Nous avons aussi vite remarqué que le module blogue, lui, emmagasine de l’information dans la base de données ! Dans la plupart des situations, on se retrouvera donc avec un mélange de fichiers plats et de contenus qui échappe au contrôle d’un système de versionnage.

Avec des fichiers plats, quand il y en a…, on se retrouve vite avec une pléthore de petits fichiers… dupliqués pour toutes les langues du site.

À noter également que les fichiers de contenu sont placés directement sous le thème adopté. Advenant la migration vers un autre thème, il faut carrément déplacer tous ces fichiers vers le nouveau parent. Cela se fait-il sans heurts ?

La codification des fichiers plats

On l’aura remarqué dans l’illustration précédente, le fichier plat contient plus que du contenu. La structure est simple, chaque section divisée par le symbole « == ».

[viewBag]
title = "English Title"
url = "/new-root"
layout = "content"
is_hidden = 0
navigation_hidden = 0
localeUrl[fr] = "/titre-francais"
==
  
    code...
    code...
  
==
  

Emplacement du contenu HTML (Twig) 

La première section est réservée aux spécifications d’une page (métadonnées), la seconde permet d’inclure du code PHP, une sorte de partie contrôleur supplémentaire, et enfin, la dernière section relève du contenu en soi. Cette dernière partie est ce que voit l’usager administrateur dans la section Pages.

Mystérieux bogue

Durant mon analyse, j’ai installé un thème préconfiguré (avec blogue, sections, etc.) afin de bien comprendre le niveau de complexité que le CMS pouvait atteindre. Le thème est une boutique fictive de chaises. On a déjà parlé de la portion blogue qui enregistre son contenu dans la base de données. J’ai pris au hasard une page, les High chairs et j’ai comparé ce que je trouvais à la fois comme fichiers et ce qui réside dans le CMS.

Le thème choisi (un peu vieillot quand on considère la modernité du CMS. On remarque deux colonnes de contenu.

Comme on pouvait s’y attendre, un fichier chairs-high-chairs.htm réside dans le thème. On y voit la séparation attendue. Mais tout de même un peu différente du concept : les déclarations sont bien dans le haut et le contenu est bel et bien dans le bas, sauf que ce qui est réservé au PHP contient… du contenu en code Twig.

.

Le fichier chairs-high-chairs.htm. Le code du milieu n’est pas du PHP, mais du Twig.

Je décide d’aller voir dans le CMS dans la section Pages (vous me suivez ?). J’y vois traduites en onglet les deux sections Content et Sidebar avec aussi Header par contre. C’était défini où, ça ?

Le fichier chairs-high-chairs.htm traduit dans la section Pages de l’usager. Puisque nous avons affaire à un fichier plat, je me serais attendu à voir dans ledit fichier les fameux onglets.

Bon, allons voir du côté programmeur… Les ennuis commencent. Il manque des portions ! Comble de malchance, je décide de modifier le titre H3 à partir de cette section et je reviens voir mon site. Pouf ! La colonne de droite a disparu du code.

Le fichier chairs-high-chairs.html traduit dans la section CMS

Le fichier chairs-high-chairs.html modifié dans la section CMS. Des portions ont disparu.

J’ai eu beau retourner en tous sens, je n’ai pas compris ce qui se passait. On pourrait penser que c’est une erreur de programmation qui provoque ce chambardement. Or, qu’une telle défaillance puisse exister donnera des sueurs à tout utilisateur du CMS. J’ai laissé un message d’aide sur le canal Slack de la compagnie et je n’ai obtenu que des commentaires d’usagers qui ne comprenaient pas ce bogue. Je pense que ce thème proposé par October est issu d’une ancienne version instable du CMS. J’ajouterai un post-scriptum si j’obtiens des éclaircissements. Un de mes neveux travaille dans une petite boîte montréalaise qui utilise ce CMS. Il m’a avoué n’avoir jamais eu ce genre de problèmes avec October tout en me précisant qu’ils ne partaient jamais d’un thème.

Conclusion

Rien ne vaut l’essai d’un CMS avant de s’en faire une véritable opinion. Je l’avoue volontiers, cet article manque de la profondeur d’analyse qui vient avec l’expérience. Il ne m’a pas fallu longtemps pour comprendre les principes inhérents à ce CMS et, de ce côté, le retour à la simplicité est réussi. Cependant, la réalité nous rattrape vite quand il s’agit de solutions logicielles. Ce qui paraît simple ne l’est jamais vraiment. Et October n’y échappe pas. Mû par Laravel, il en possède la puissance. La solution est jeune et prometteuse. À ce stade, October demeure un CMS pour les geeks. La véritable simplicité est tributaire d’une codification qui va au-delà de la philosophie annoncée. Si on s’en tient aux fichiers plats, on peut certes bâtir rapidement de petits sites web, ce que l’on appelle des sites vitrine. Au-delà d’un certain nombre de pages, surtout si on doit composer avec plusieurs langues, on aura sans doute le réflexe d’opter pour une solution Laravel en bonne et due forme (custom) ou l’utilisation d’un CMS plus mature.