D’un CMS dynamique à un serveur statique

Par les années passées, j’ai entretenu deux blogues desservis par des systèmes de distribution de contenu gratuites. En dehors des raisons qui m’aient fait abandonner la rédaction de ces blogues, j’ai été insatisfait de ces plate-formes.

1. Je me sers d’un blogue avant tout pour rédiger des articles. Par conséquent, si le système de gestion du contenu comporte une interface compliquée ou alourdie par un paquet de caractéristiques dont je n’ai pas besoin, je suis agacé.
2. Bien qu’il soit possible de changer le design visuel du site rendu par ces systèmes, ça ne m’apparaît pas particulièrement simple. Il faut prendre le temps de comprendre les classes de style exposées et comment le fil de textes s’y insère. Il m’apparaît beaucoup plus simple de mettre en place mon propre gabarit HTML et CSS dans lequel insérer mes textes.
3. La performance technique de ces plate-formes n’est pas impeccable. J’ai rencontré un nombre surprenant de pannes de service avec Tumblr, et certains éléments de Wordpress ne fonctionnaient pas très bien (particulièrement l’interface de traitement des images, que je n’ai pas réussi à utiliser pour recadrer mes photos). Considérant que je ne désire que publier des textes avec quelques images statiques, je veux bien relever le pari de monter mon propre serveur de distribution et pour en tirer une performance plus consistante.
4. Finalement, depuis les deux ans que je travaille pour Arcadia Labs, j’ai découvert via The Exploit Database un nombre alarmant de problèmes de sécurité concernant plusieurs tels systèmes, notamment Wordpress. Ces services étant d’ailleurs utilisés par des milliers de gens, ils m’apparaissent constituer une cible alléchante en regard du vol d’information, par opposition à un simple serveur web soutenant un petit nombre de sites fréquentés par un petit nombre de gens distingués et cultivés.

En plus, ça faisait un long moment que j’avais programmé quelque chose juste pour moi. Plus j’y pense, plus je suis convaincu qu’il s’agit là de la meilleure justification pour coder mon propre système de blogue.

La structure envisagée

Je désire rédiger un blogue en français, sujet illimité. La structure de ce blogue est la séquence d’articles en ordre chronologique inverse (le fil), accompagné d’un certain nombre de liens vers des pages statiques (e.g. projets, recettes, etc.). Le fil ne comporte que le résumé d’un article: en cliquant sur le titre, on navigue à une page qui comporte le texte entier.

Les articles sont classifiés par étiquettes (tags), ce qui permet aux textes d’appartenir à de multiples catégories parmi lesquelles le lecteur voudrait chercher. Chaque étiquette est associée à un fil spécifique, qui liste l’ensemble des articles comportant l’étiquette.

Comme la rédaction directe en HTML est pénible, les articles et les pages statiques seront rédigés au format Markdown. Il me faut donc un script d’assemblage du blogue qui, à partir de ces sources, génère:

1. chacune des pages respectivement associée à un fichier Markdown;
2. le fil des articles les plus récents, qui sera index.html pour le blogue;
3. les fils d’articles associés respectivement à toutes les étiquettes marquant chacun des articles.

Ces fils et pages doivent constituer le contenu principal à gauche d’un gabarit qui ramène dans sa partie de droite une barre de navigation comportant des éléments d’identification de l’auteur et une liste des étiquettes pertinentes.

La description d’un texte

L’assemblage à partir de gabarits HTML et des divers fils d’articles nécessite l’ajout d’un ensemble de méta-informations à chacun des fichiers Markdown en entrée:

1. titre de l’article;
2. URL où on navigue quand on clique sur le titre (ce qui permet de faire de courts articles de commentaire)
3. auteur (ce qui me permet d’inviter des contributeurs à ma convenance);
4. date de publication (pour la composition du fil principal);
5. liste des étiquettes rattachées à la page;
6. mention de si le fichier correspond ou non à une page statique (pour éviter de l’inclure dans le fil dans ce dernier cas).

Les directives de méta-données sont aussi utilisées pour distinguer le résumé du texte entier de l’article. Ces directives doivent pouvoir être articulées de manière à ce que le résumé soit facultatif: certains articles courts n’en nécessiteront pas.

Avant même d’entreprendre la programmation du script d’assemblage du blogue, j’avais une idée de la façon d’encoder de telles méta-informations assez simplement dans mes fichiers Markdown. J’avais déjà considéré l’implantation de ce script en Ruby, qui comporte une librairie de traitement des documents dynamiques nommée erb. Cette librairie permet d’insérer des énoncés de code Ruby à même un fichier texte. Lorsqu’un tel fichier est traité à l’aide d’erb, le code Ruby est exécuté, lequel permet d’accumuler des informations et d’insérer du texte dynamique à la place des énoncés; le reste du contenu du fichier est rendu tel quel, sans modification.

Cette approche permet en particulier de définir des fonctions permettant le stockage des méta-informations en effet secondaire du traitement du fichier. Par exemple, un article pourrait se présenter de la manière suivante:

% titre "Gâteau à la noix de coco"
% date  "2013-04-01 14:00"
% etiq  "Recette", "Gâteau", "Coco"

Voici ma super recette de gâteau à la noix de coco.

# Ingrédients
...

Le résultat du traitement du fichier par erb donnerait simplement le code Markdown suivant:

Voici ma super recette de gâteau à la noix de coco.

# Ingrédients
...

Cependant, le traitement aurait aussi exécuté les fonctions Ruby titre(), date() et etiq(), qui auraient pu entrer les méta-informations concernant cet article dans une structure de données facilitant la composition des fils.

Publication du blogue

Le script d’assemblage du blogue génère donc un ensemble de pages HTML, qui s’ajoutent à une collection d’images et de fichiers CSS statiques. Pour publier le blogue, il suffit donc de le téléverser sur mon hôte. Comme j’ai accès SSH à cet hôte, il est aisé d’utiliser la commande rsync pour téléverser seulement les éléments changés depuis le dernier assemblage du blogue, en fixant les droits d’accès aux fichiers mis en place. Considérant qu’on veuille répliquer le contenu du sous-répertoire www du répertoire courant, la commande est

rsync -atvz --chmod=ugo+rX --rsh=ssh www/* hote.com:

Dans la seconde partie de cet article, je décrirai le design et l’implantation du script d’assemblage du blogue, nommé blog.rb.