Implémenter une gestion des "brouillons" d'articles

Le problème avec les générateurs de sites statiques, c'est qu'ils n'intègrent pas nativement de système de brouillons :

1. Tous les fichiers créés passent à la moulinette et génèrent une page (même si leur contenu n'est pas prêt pour être mis en ligne)
2. Aucun mécanisme de partage ou d'accès temporaires pour permettre à un relecteur ou une relectrice externe de consulter l'article inachevé.

Le premier point est particulièrement gênant lorsque je veux faire des mises en production alors que des articles sont en cours de rédaction. Ça m'oblige à jongler entre différentes branches sur Git (ou à jouer avec le stash si l'article n'est pas commité). Sans ça, le ou les articles inachevés finiraient en production (ainsi que tous les liens vers ceux-ci).

Le premier point est assez facile à adresser, la communauté Eleventy regorge d'approche différentes pour gérer ça, en revanche le second est moins évident…

La partie facile : prévenir la génération d'une page "en prod"

Pour cette partie, je peux simplement reprendre un exemple donné sur le site officiel d'Eleventy : Preprocessors – Example: Drafts(Opens in a new window)⎋

Il ne me reste ensuite plus qu'à définir une variable d'environnement dans mon script de build et le tour est joué. Mon petit ajout, c'est que j'en profite pour exclure les brouillons des collections à cette étape :

// in package.json
{
  …,
  "scripts": {
    …,
    "build": "MY_ENVIRONMENT=prod npx @11ty/eleventy --watch"
  },
  …
}

// in eleventy.config.js
eleventyConfig.addPreprocessor("drafts", "*", (data, content) => {
  if(data.draft && process.env.MY_ENVIRONMENT === "prod") {
    data.eleventyExcludeFromCollections = true
    return false // prevents the generation of the content
  }
});

Questions existentielles

Mais avant de poursuivre sur la seconde partie, il faut que j'aborde quelques questions bien ardues, afin de définir la meilleure marche à suivre.

Servir des pages encryptées ? Ou protéger côté serveur ?

Quand j'ai commencé à réfléchir à ce sujet, j'ai envisagé d'utiliser une bibliothèque^[2] qui permet de servir une page avec un contenu encrypté afin d'avoir un système de "prévisualisation avec mot de passe" qui marche quelque soit le type de serveur utilisé (Apache, Nginx, …) mais il y a plusieurs problèmes avec cette approche :

• Sécurité : la page est quand même trouvable et son URL ou ses métadonnées peuvent "dévoiler" des informations sur son contenus
• Éco-conception : charger de la donnée encrypter puis la faire décrypter en local, ce n'est quand même pas génial (alors qu'on pourrait juste bloquer l'accès côté serveur)
• Accessibilité : Il est peu probable que l'accessibilité du contenu "temporaire" et de son interface de validation généré par la bibliothèque soit accessible, et je n'ai pas l'impression que celle-ci permette de le personnaliser.

Ayant pour l'instant opté pour un hébergement mutualisé classique avec un serveur Apache, je choisi de partir sur la voie ancestrale du duo .htaccess/.htpasswd (simple et confortable) et de bloquer les accès côté serveur. (J'ai eu quelques surprises en implémentant le fichier .htpasswd qu'il faudra que je détaille plus tard^[3]).

Articles publiés : État par défaut ou acte explicite ?

En réfléchissant à la façon dont nous allons écrire et alimenter notre blog, je suis arrivé assez rapidement à la question du statut initial d'un article :

• Est-ce qu'un article doit par défaut "publié" (c'est à dire que si déclenche une génération il apparaît en ligne) ?
• Ou est-ce qu'il est au contraire en mode "brouillon" (donc ignoré lors de la génération du site) ?

Concrètement cela se traduit par soit :

• Surveiller l'ajout d'une propriété draft: true^[4] pour masquer l'article
• Surveiller l'ajout d'une propriété published: true pour autoriser la génération de l'article

Intuitivement, je préfère la seconde car si je compare les impacts d'un oubli de ces propriétés :

• Si j'ai oublié de marquer mon article comme un brouillon, il apparaît inachevé en ligne ! 😱
• Si j'ai oublié de marquer mon article comme publier, je vais juste m'étonner de ne pas le trouver en ligne… et je serais probablement le seul à savoir que j'ai fait une boulette car le reste du monde ignore tout simplement que j'étais en train d'écrire un article.

Le premier cas (l'article publié par erreur) est d'autant plus embêtant qu'il est hautement probable que je ne pense pas à aller vérifier sa présence.

Malgré tout j'ai commencé à implémenter la première approche, simplement parce que c'est celle la plus proche du fonctionnement natif des générateur de sites statiques (en tout cas d'Eleventy) : Un fichier présent est destiner à "passer dans la moulinette". En être exclu reste l'exception.

Néanmoins, en essayant d'expliquer dans cette entrée les inconvénients d'implémenter le comportement "Publication volontaire uniquement" sur Eleventy, je me rend compte que ce n'est pas si évident… Cette approche, en plus d'être plus sûre que l'autre, est peut-être tout à fait viable… il va falloir que j'essaye des trucs avant de continuer…

Affaire à suivre !

---

1. C'est à dire un environnement disponible en ligne (la "prod") mais en accès restreint. ↩︎

2. Il s'agit de la bibliothèque pagecrypt(Opens in a new window)⎋, conseillée dans cet article du blog Sandtoken(S'ouvre dans un nouvelle fenêtre)⎋ ↩︎

3. En plus des surprises déjà évoquées sur le .htaccess dans mon entrée précédente ↩︎

4. Ce motif est le plus fréquent au sein de la communauté Eleventy ↩︎