Catégorie « À propos du blog »

Un des derniers points qui manquaient depuis la résurrection de ce blog était de faire refonctionner les anciennes URL des articles.

En effet, lors du passage sous Jekyll, d’une part le nommage des articles a été modifié (par défaut Jekyll les met en .html là où ma réécriture d’URL sous WordPress me les faisait juste finir par un /) et d’autre part j’ai changé de domaine, passant de wp.darathor.com à blog.darathor.net.

Il manquait donc deux opérations :

1. rediriger l’ancien domaine vers le nouveau
2. rediriger les anciennes URL vers les nouvelles

La première étape n’a rien de compliqué et se fait assez rapidement dans la configuration des VHOST d’Apache.

La seconde est un peu moins immédiate puisqu’il m’a fallu construire la table de correspondance des anciennes URL vers les nouvelles.

J’ai choisi comme stratégie de stocker une liste d’alias dans l’en-tête de chaque articles et de générer un fichier .htaccess à partir de ça.

Déclaration des alias

La déclaration des alias est assez simple et se limite à une liste d’URL relatives :

aliases:
- /?p=3
- /2007/05/01/ouverture-du-site/

L’avantage de fonctionner avec une liste d’alias en URL relatives c’est que cette même mécanique peut être ré-exploitée si je veux changer l’URL d’un article par la suite (notamment pour corriger une coquille).

Reste à l’alimenter dans mon cas de migration depuis WordPress.

Le script de migration de WordPress vers Jekyll m’avait extrait une entrée de la forme wordpress_url: http://wp.darathor.com/?p=10 contenant une des formes d’URL proposée par WordPress. Par contre il ne s’agissait pas de la forme générée par la réécriture automatique de WordPress qu’il m’a fallu reconstruire pour aboutir aux deux alias ci-dessous. J’ai finalement choisi de garder les deux URL à chaque fois étant donné que les deux pointaient sur le contenu et que je n’aime pas les liens morts.

Génération du fichier .htaccess

Dans mon cas j’utilise Apache comme serveur web, donc je peux passer par un fichier .htaccess ce qui a un gros avantage : tout reste stocké dans le code versionné et déployable automatiquement sans aller toucher au VHOST.

Pour générer ce fichier j’ai procédé comme pour le robots.txt via une simple page nommée htaccess (sans extension sinon à la génération Jekyll la colle arbitrairement derrière le permalien) :

---
layout: null
permalink: .htaccess
---

ErrorDocument 404 /404.html

{% for page in site.pages -%}
{%- if page.aliases -%}
{%- for alias in page.aliases -%}
  Redirect 301 {{ alias }} {{ page.url }}
{% endfor -%}
{%- endif -%}
{%- endfor -%}

{% for post in site.posts -%}
{%- if post.aliases -%}
{%- for alias in post.aliases -%}
  Redirect 301 {{ alias }} {{ post.url }}
{% endfor -%}
{%- endif -%}
{%- endfor -%}

On retrouve donc l’en-tête avec un layout: null pour que le fichier généré ne soit pas habillé d’une structure HTML et un permalink: .htaccess indiquant le nom du fichier à générer.

Ensuite le contenu consiste en une simple boucle sur les articles avec à chaque fois une boucle sur les alias pour générer les redirections 301.

J’en ai également profité pour ajouter la ligne ErrorDocument 404 /404.html qui dit à Apache d’utiliser une page 404 personnalisée plutôt que la page par défaut.

Ajout du 07/10/2018 à 12h30

Dans mon .htaccess je ne gérais les alias que pour les articles et pas pour les pages. J’ai mis à jour le code ci-dessus pour en tenir compte également.

La problématique

Dernier des gros points noirs relevés lors de ma bascule sur Jekyll : l’absence de moteur de recherche.

Forcément quand le site est statique, c’est plus compliqué de mettre en place un moteur de recherche. Il y a plusieurs approches possibles :

• faire une partie dynamique côté serveur pour la recherche : bof, le but c’est d’avoir maintenance côté serveur, donc non
• faire appel à une API tierce qui ferait l’indexation puis la recherche : bof aussi, ça permet certes de rester statique côté serveur mais délocaliser la chose n’est pas mieux (en plus ça veut dire maintenance sur l’utilisation de l’API) donc non
• déléguer complètement à un moteur externe type Google Search : ça existe sur certains sites (quoique ça fait un moment que je l’ai plus vu) sous la forme d’un formulaire de recherche redirigeant sur Google avec une recherche de type site:monsite.com ...… c’est mieux côté maintenance mais pire côté délocalisation puisqu’on quitte carrément le site, donc non

Reste la dernière : faire la recherche directement dans le navigateur en JS à partir d’un index fourni, solution finalement retenue.

Bon, c’est loin d’être parfait comme concept : ça ne passe évidemment pas à l’échelle notamment mais ce site reste un blog perso donc la volumétrie de devrait pas exploser…

L’index fait environ 500ko avec mes 156 articles actuels (représentant un peu plus de 10 ans) donc ça reste jouable, même si j’ai augmenté mon rythme ces derniers temps (notamment à cause des republications). Dans tous les cas on reste loin des pages d’accueil avec des gros carrousels d’images à 2Mo chacune qu’on trouve sur certains sites (notamment e-commerce) et ce n’est de toutes façons chargé que sur la page de recherche.

Donc c’est réaliste dans mon cas et vous pouvez le tester via le champ de recherche dans la colonne de droite.

Solution existante et adaptations

Je suis parti de cet article proposant une solution basée sur la bibliothèque Lunr mais comme souvent c’était loin d’être satisfaisant de base :

• forcément c’est en anglais, donc fallait au moins traduire
• ça ne permet pas de placer le champ de recherche sur toutes les pages (à moins d’inclure le code de recherche sur toutes les pages aussi, ce qui est exclus)
• visuellement le rendu ne me convenait pas du tout
• toutes les pages sont indexées, y compris les pages de catégories par exemple qui ne sont que des regroupements d’articles

Du coup j’ai réorganisé les choses différemment en :

• séparant l’index dans un fichier JS à part
• modifiant le formulaire pour qu’il fasse un simple GET vers une page dédiée au résultat de recherche
• modifiant le JS pour que le terme à rechercher soit cherché dans l’URL
• ajoutant dans l’en-tête des pages devant être indexées un paramètre searchable: true

La section suivante détaille la marche à suivre pour intégrer tout ça sur votre site.

Mise en œuvre

La bibliothèque Lunr

À récupérer ici et à ajouter dans le dossier assets/js.

Le code JS utilisant Lunr

Dans un fichier assets/js/search.js :

(function (window) {
	window.onload = function () {
		var idx = lunr(function () {
			this.ref('id');
			this.field('title');
			this.field('body');

			window.searchIndex.forEach(function (doc) {
				this.add(doc)
			}, this)
		});

		var resultsElement = document.getElementById('search-results');
		var HTML = '';
		var term = getQueryString('q');
		if (term) {
			document.getElementById('search-field').value = term;
			var results = idx.search(term);
			if (results.length > 0) {
				var plural = results.length > 1;
				HTML += '<p>' + results.length + ' résultat' + (plural ? 's' : '') + ' trouvé' + (plural ? 's' : '') + ' pour la recherche « ' + term + ' » :</p> <ul>';
				for (var i = 0; i < results.length; i++) {
					var result = window.searchIndex[results[i]['ref']];
					var url = result['url'];
					var title = result['title'];
					var date = result['date'];
					var body = result['body'].substring(0,160) + '...';
					var type = result.type === 'post' ? 'Article' : 'Page';

					HTML += '<li class="search-result"><p class="metadata"><a href="' + url + '" class="title">' + title + '</a>';
					HTML += ' <span class="type">' + type + '</span>';
					if (date) {
						HTML += ' <span class="date">publié le ' + date + '</span>';
					}
					HTML += '</p><p class="summary">' + body + '</p></li>';
				}
				HTML += '</ul>';
			}
			else {
				HTML += '<p>Aucun résultat trouvé poru la recherche « ' + term + ' ».</p>';
			}
		}
		else {
			HTML += '<p>Aucun terme à rechercher.</p>';
		}
		resultsElement.innerHTML = HTML;
	};

	/**
	 * Get the value of a query string.
	 * @param {string} field The field to get the value of
	 * @param {string=} url The URL to get the value from (optional)
	 * @return {string} The field value
	 */
	var getQueryString = function (field, url) {
		var href = url ? url : window.location.href;
		var reg = new RegExp( '[?&]' + field + '=([^&#]*)', 'i' );
		var string = reg.exec(href);
		return string ? string[1] : null;
	};
})(window);

Je n’ai pas cherché à extraire le rendu HTML du résultat de recherche, donc il faudra directement modifier ce fichier pour l’arranger.

Le fichier d’index : search-index.js

Dans un fichier search-index.html à la racine du projet :

---
layout: null
permalink: search-index.js
---

(function (window) {
  {%- assign counter = 0 %}
  window.searchIndex = [{% for page in site.pages %}{% if page.searchable %}{
    "id": {{ counter }},
    "url": "{{ site.url }}{{ page.url }}",
    "type": "page",
    "title": "{{ page.title | replace: '"', ' ' }}",
    "body": "{{ page.content | markdownify | replace: '.', '. ' | replace: '</h2>', ': ' | replace: '</h3>', ': ' | replace: '</h4>', ': ' | replace: '</p>', ' ' | strip_html | strip_newlines | replace: '  ', ' ' | replace: '"', ' ' }}"{% assign counter = counter | plus: 1 %}
  }, {% endif %}{% endfor %}{% for page in site.posts %}{
    "id": {{ counter }},
    "url": "{{ site.url }}{{ page.url }}",
    "type": "post",
    "date": "{{ page.date | date: '%d/%m/%Y à %R' }}",
    "title": "{{ page.title | replace: '"', ' ' }}",
    "body": "{{ page.content | markdownify | replace: '.', '. ' | replace: '</h2>', ': ' | replace: '</h3>', ': ' | replace: '</h4>', ': ' | replace: '</p>', ' ' | strip_html | strip_newlines | replace: '  ', ' ' | replace: '"', ' ' }}"{% assign counter = counter | plus: 1 %}
  }{% if forloop.last %}{% else %}, {% endif %}{% endfor %}];
})(window);

Il est possible de modifier ce fichier si vous voulez ajouter des informations à l’index (par exemple des données complémentaires pour l’affichage des résultats).

La page de résultat de recherche

Dans un fichier search.md à la racine du projet :

---
layout: page
title: Recherche
---

<script src="/assets/js/lunr.js?v={{ site.time | date: '%s' }}" type="application/javascript" async="async"></script>
<script src="/assets/js/search.js?v={{ site.time | date: '%s' }}" type="application/javascript" async="async"></script>
<script src="/search-index.js?v={{ site.time | date: '%s' }}" type="application/javascript" async="async"></script>

<div id="search-results">Recherche en cours...</div>

L’entrée layout est à adapter en fonction de ce que vous avez défini sur votre site.

Le formulaire de recherche

Il reste à intégrer le formulaire de recherche là où vous souhaitez de voir apparaitre :

<form action="/search.html" method="get" class="search-form">
  <p>
    <input id="search-field" type="text" name="q" maxlength="255" value="" />
    <button type="submit" title="Lancer la recherche"><img src="/assets/img/search.svg" alt="Lancer la recherche" /></button>
  </p>
</form>

Pages indexables

En l’état, seuls les articles seront indexés. Il reste donc à ajouter searchable: true dans l’en-tête de chaque page que vous souhaitez indexer.

Voici mon second plugin pour Jekyll, toujours lié à mon menu de catégories.

Contexte

En plus de 10 ans d’existence de ce blog, j’ai beaucoup varié les thématiques de mes articles. Au début j’étais purement en mode bloc-notes sur des astuces techniques pour pouvoir les retrouver facilement. Puis j’ai pas mal parlé de l’iPhone, de mes développements perso, de mes créations “artistiques” (BD, cartes Magic, etc)… à force ça commence à faire beaucoup de catégories et ce n’est plus très lisible dans une liste en vrac.

Du coup j’ai voulu refaire ce que WordPress proposait via les sous-catégories : grouper les catégories par thématiques. Je n’ai pas trouvé de plugin qui le fasse bien. J’en avais testé un qui avait l’air de faire ce que je voulais mais je n’ai pas réussi à le faire marcher… peut-être que j’aurais dû insister mais je ne l’ai plus retrouvé donc j’ai fini par décider d’en développer un moi-même. Après tout le fonctionnel est simple.

Pour le coup effectivement, rien de bien compliqué, un connaisseur de Ruby y aurait sans doute passé moins d’un quart d’heure. Bon perso je n’y connais rien à Ruby, je l’ai découvert en débugant des plugins ces trois derniers mois, donc forcément ça m’a pris un peu plus de temps mais j’ai finalement ce que je voulais ^^

Le plugin

Ce plugin se résume donc à un nouveau filtre Liquid qui prend en entrée les catégories et renvoie en sortie une un tableau à double-entrée avec pour chaque thématique un sous-tableau contenant l’ensemble de ses catégories.

Les thématiques ou « groupes de catégories » sont définis dans le fichier de configuration _config.yml, avec la liste des groupes et pour chacune la liste des catégories qui la composent. Les catégories non-affectées étant regroupées dans un groupe « Default » (une seconde entrée de configuration permettant de définir son libellé).

Le plugin ainsi qu’une documentation plus détaillée sont accessibles ici : jekyll-group-categories-filter

Utilisation sur ce blog

J’ai donc appliqué ça à ce blog en découpant la liste des catégories en 4 thématiques :

• jeux : vu que ces derniers temps j’ai posté pas mal de trucs sur Magic et Carcassonne ça ne me semble pas superflu d’en faire une thématique à part
• réalisations perso : mes diverses réalisations perso que ce soit du dev ou des trucs plus « artistiques »
• informatique : un peu fourre-tout… j’ai hésité à découper plus mais j’ai du mal à délimiter les choses, donc dans l’immédiat on va rester là dessus
• autres : tout le reste

Dans chaque thématique j’ai gardé le tri alphabétique grâce à mon précédent plugin, ce qui me donne le code suivant dans la sidebar :

<h2>Catégories</h2>
{% assign groupedCategories = site.categories | group_categories %}
{% for group in groupedCategories %}
  <h3>{{ group[0] }}</h3>
  <ul>
    {% assign categories = group[1] | sort_by_keys %}
    {% for category in categories %}
      <li><a href="/categories/{{ category[0]|slugify:'latin' }}/">{{ category[0] }}</a> ({{ category[1].size }})</li>
    {% endfor %}
  </ul>
{% endfor %}

Voilà, n’hésitez pas à me faire un retour, soit ici, soit dans le bug tracker du plugin s’il s’agit d’un bug ou d’une idée d’amélioration ^^

Comme je le disais en annonçant la réouverture du blog, l’un des deux gros points noirs suite au choix de Jekyll et d’un site statique entièrement pré-généré c’était le problème des commentaires. En effet, habituellement c’est le moteur de blog qui propose un formulaire et traite côté serveur les soumissions de nouveaux commentaires. En passant au statique ce n’est plus possible directement puisque le serveur ne fait que… servir du statique justement. Aucune intelligence, donc pas non plus celle de gérer les commentaires.

Les solutions existantes

La solution la plus répandue dans ce cas est de passer par une plateforme externe telle que Discuss qui centralise les commentaires et les restitue via un widget JavaScript inclus dans la page. Cela ne me plaît pas tu tout d’une part parce que c’est une externalisation de la donnée alors qu’elle doit à mon sens rester groupée avec les articles et sûrement pas déléguée à un silo. D’autre part ça signifie charger un script externe systématiquement ce qui introduit d’une part de la lourdeur et d’autre part une fuite de données de navigation : Discuss ou son équivalent est mécaniquement au courant de qui regarde quelles pages chez moi et quand. Et non-seulement chez moi au aussi sur tous les autres sites utilisant leur plateforme. Et c’est généralement le cœur de leur modèle économique de monnayer d’une manière ou d’une autre ces données.

Bref la solution basée sur un silo centralisé était exclue.

Une autre solution aurait été de faire pareil mais en auto-hébergé. C’est-à-dire proposer quelques webservices exploités en JavaScript. Ça résout le problème de dépendance externe et de protection de la vie privée mais ça réintroduit le problème que je voulais résoudre en utilisant un générateur de site statique, à savoir ne plus avoir à m’inquiéter de la maintenance et de la sécurité. Certes ça aurait représenté un volume de code bien plus limité qu’une plateforme de blog complète, donc largement simplifié la maintenance mais quand même.

Donc cette solution là n’était pas valable non plus.

Et en faisant quelques recherches je n’ai rien trouvé comme proposition hors ces deux pistes. J’en ai conclus que j’allais devoir inventer une solution de toutes pièces et j’ai donc remis ça à plus tard pour ne pas bloquer la remise en ligne du blog. J’ai donc sorti le blog en laissant ça mûrir dans un coin de ma tête.

Mon idée

Mon cahier des charges était donc de trouver une solution n’impliquant pas de service tiers ni de service auto-hébergé à maintenir. C’était un peu mal parti : faire tout côté client mais avoir le résultat côté serveur sans introduire de faille potentielle semble assez insoluble.

J’ai fini par penser à une solution un peu bâtarde mais viable dans mon cas : passer par des mails. Puis traiter manuellement les soumissions de commentaires.

Forcément ça fait intervenir un service tiers : le fournisseur de messagerie (j’ai renoncé à vouloir auto-héberger du mail, c’est beaucoup trop compliqué et risqué) mais il ne fait que passe-plat et n’est pas chargé de conserver la donnée sur le long terme puisqu’une fois un commentaire réceptionné, je l’intègre à la page de l’article. J’ai donc regardé un peu ce qu’on pouvait faire pour envoyer du mail côté client. En JavaScript ça semble impossible (et pas très souhaitable pour des raisons assez évidentes en matière de spam) mais il reste toujours la bonne vieille méthode à base d’un formulaire en mode “mailto”. Ça donne un peut l’impression de revenir à l’Âge de Pierre mais l’essentiel c’est que ça marche.

Cette solution n’est pas exempte de défaut, à première vue au moins les suivants :

• l’adresse e-mail de destination du formulaire est en clair, ce qui fait qu’elle risque d’être cible de spams à terme
• les commentaires ne sont pas publiés instantanément, il faut que j’intervienne pour les intégrer
• c’est chronophage : je dois faire l’intégration à la main (problème de passage à l’échelle)
• on augmente dans l’absolu le risque juridique : comme c’est moi qui publie les commentaires, je passe automatiquement en mode de modération a priori, donc je ne peux pas prétendre ne pas avoir connaissance des contenus publiés, j’en suis donc responsable
• ce n’est pas super “user friendly” de passer par son client mail pour envoyer le commentaire même si le contenu est pré-rempli

Reste que ces défauts sont acceptables au moins dans mon cas. Reprenons-les point par point :

• publicité de l’adresse e-mail : c’est un défaut mineur, il suffit de faire une adresse dédiée et comme elle ne sert qu’à ça elle peut être remplacée du jour au lendemain si elle est la cible de spam
• délai de publication : là non plus ce n’est pas super grave, on n’a pas vraiment besoin d’instanténéité sur des commentaires, même s’il est vrai que ça a toutes les chances de réduire les discussions entres lecteurs (les discussions entre moi et un visiteur ne sont pas affectées puisqu’elles nécessitent de toute façons une action de ma part pour avancer), c’est un peu dommage mais pas primordial, surtout dans le cas de mon audience confidentielle
• chronophage : le problème évident de passage à l’échelle en cas de gros volume de contributions et cette solution n’est clairement pas généralisable à des sites ayant beaucoup de commentaires mais ce n’est pas un problème pour moi : je ne crois pas qu’un seul de mes articles ait dépassé les dix commentaires, donc ça reste totalement gérable
• risque juridique : ça m’obligera potentiellement à refuser certains commentaires mais je pense que le risque reste minime
• aspect “user friendly” : franchement ça demande juste de valider l’envoi du mail en acceptant qu’il contienne des donnés présentées de manière un peu technique… disons qu’on s’en fout, d’autant plus que mon blog traite entre autres de technique (et en passant je pense que je me débarrasse de la plupart des robots spammeurs qui ne doivent vraiment pas s’attendre à ça :D)

Voilà du coup ça me semble correct dans l’immédiat : pas parfait mais ça fait le boulot en rétablissant un système de commentaires. On va laisser ça tourner quelque temps puis on verra ^^

Ça faisait déjà près d’un an et demi que ce blog était mort suite à un crash serveur. Je ne pouvais pas le remettre en fonction directement parce qu’il utilisait une vieille version de WordPress qui n’était pas compatible avec PHP7 et je n’avais pas envie de pourrir mon nouveau serveur avec un vieux PHP. Quant à la mise à jour de WordPress était dissuasive parce que j’avais de nombreuses versions de retard et que ça se serait forcément fait dans la douleur.

En parallèle j’avais vu passer plusieurs articles parlant de remplacer WordPress et autres moteurs dynamiques par un générateur de site statique. Cet aspect me tentait bien mais pas pour les raisons avancées habituellement, en particulier la principale : les perfs je m’en fiche un peu (mon serveur se tourne les pouces la plupart du temps et j’ai une audience limitée).

Non, ce qui m’intéressait c’était plutôt de supprimer la maintenance et le besoin de mise à jour, soit précisément ce qui m’a fait repousser la remise en ligne du blog (et ce qui me causait sans doute de grosses failles de sécurité sur le précédent serveur). En effet, dans ce cas le générateur n’est pas en ligne, je peux le garder tranquillement en local sur mon ordi perso.

Par contre, ça a plusieurs gros inconvénients qui m’ont retenu de sauter le pas plus tôt, en particulier deux :

• Pas de système de commentaires. C’est embêtant parce qu’il est exclus que je délègue ça à un silo genre Discuss. Et si c’est pour remettre du JS et un système de web services ben on reperd direct l’intérêt principal de s’éviter la maintenance… Je n’ai pas de solution correcte pour l’instant donc il faudra s’en passer (genre en passant par Mastodon ou à défaut Twitter), jusqu’à ce que je trouve quelque chose de viable.
• Pas de moteur de recherche. Moins gênant mais quand même déléguer à Google et autres la recherche interne du site ça me déplaît pas mal. Là non plus je n’ai pas de solution pour l’instant (j’ai trouvé un plugin qui permettrait de le faire mais en passant par une API tierce, donc bon, on n’y gagne pas grand-chose au final).

J’ai finalement décidé de sauter le pas parce que ça m’est arrivé quand même assez souvent de me dire que j’aurais bien fait un article sur un sujet mais qu’en l’absence de blog j’ai soit rien fait, soit résumé en quelques pouets et/ou tweets.

J’ai donc cherché un peu dans les outils existants. Forcément y en a des dizaines… Du coup faut choisir. Après avoir écarté tout ce qui est NodeJS et rien trouvé en PHP, je me suis rabattu sur Jekyll (en Ruby) qui a le mérite d’avoir un peu d’ancienneté et donc pas mal de plugins dispo et probablement une durée de vie pas trop basse.

Après avoir rencontré pas mal de problèmes tels que :

• besoin de choisir un thème
• besoin d’installer des plugins et configurer plein de choses (Jekyll de base est assez vide)… pour la liste des plugins, cf. la page à propos
• du temps perdu à comprendre que si ma pagination était morte d’un coup c’était parce que j’avais reformaté le fichier (oui les pages contiennent des en-têtes en YAML qui a l’idée VRAIMENT débile de se baser sur l’indentation, donc un formatage et boum ça marche plus… et vas-y pour comprendre que ça vient de là !)
• repasser sur tous les articles pour faire en sorte que ça se rende bien (un convertisseur depuis une base WordPress est dispo mais il ne convertit pas les balises spécifiques… et j’en avais pas mal pour du code ou de la mise en forme autour des images)

J’ai enfin quelque chose de fonctionnel \o/

J’en profite également pour basculer sur un autre domaine (en .net plutôt que .com).

Il reste à mettre en place les redirections pour ressusciter les anciennes URL des articles mais ça peut attendre, après un an et demi, on est plus à quelque semaines près… Et il risque d’y avoir encore quelques ajustements mais ça a déjà le mérite d’être fonctionnel ^^