🎄 30 jours de Kirby pour 24 jours de web

vendredi 22 novembre 2024

24 jours de web est un calendrier de l’avent lancé par Rémi Parmentier / HTeuMeuLeu en 2012, qui publie chaque jour de décembre des articles de fond sur la conception web écrits par la communauté de design, d’intégration et de développement francophone. Il y a quelques années le projet a été confié aux bons soins de l’asso Paris Web, qui organise les conférences du même nom, et où je sévis comme designer/intégrateur/développeur.

Suite à la migration de CMS de Paris Web au printemps 2024, où on a abandonné notre vénérable Movable Type au profit de Kirby, l’équipe a voulu unifier l’outillage et rapprocher le projet 24 jours de web du cœur de Paris Web.

Étant donné que j’avais la motivation, l’énergie, le temps et le savoir-faire pour travailler sur la migration, je me suis proposé pour mener celle-ci… mais ça a été un boulot d’équipe : les autres membres de l’asso ont soufflé des idées, exposé leurs process, ou relu mon code. C’est une équipe qu’elle est vachement bien, et la rejoindre c’est une bonne idée.

Pourquoi Kirby ?

• j’aime et j’utilise Kirby depuis plus de dix ans. J’ai suivi son évolution, je connais intimememnt son fonctionnement et je connais ma capacité à développer dessus ;
• je n’aime pas Wordpress ;
• Kirby est développé en PHP, l’équipe de Paris Web contient beaucoup de gens qui ont de l’expérience avec le langage, je ne voulais pas proposer une technologie qui ne pourrait pas être comprise par d’autres, tant pour la relecture de code que pour le dépannage si je ne suis pas là ;
• l’équipe qui développe Kirby partage avec Paris Web une vision d’un web accessible et ouvert au plus grand nombre, le créateur n’a pas d’illusions de grandeur et n’est absolument pas dans le délire Silicon Valley de croissance à tout prix.

Le fait que le logiciel soit payant permet à son équipe de vivre sans avoir à faire des procès contre d’autres entreprises qui utiliseraient le code pour proposer le même service. En même temps, certains projets et les assos peuvent demander des licences gratuites, c’est très sympa. Vielen Dank Bastian!

Pourquoi pas Wordpress ?

• j’aime pas Wordpress ;
• Paris Web fonctionne à l’énergie qu’on peut mettre dans la machine, et cette énergie est alimentée par l’intérêt qu’on en retire personnellement. S’il fallait continuer à utiliser Wordpress, je n’aurais pas eu d’énergie pour l’entretien du site étant donné que je n’aurais eu aucun plaisir…

Une petite pause technique s’impose.

Un aspect technique crucial de Kirby, c’est l’organisation de ses données. Celles-ci sont stockées dans des fichiers texte—un par site, un par page, un par compte, un par fichier attaché—qui sont structurés dans une syntaxe facilement modifiable à la main. Pour donner un cadre à ces données et spécifier la forme qu’elles doivent prendre dans le fichier sauvegardé, ainsi que pour définir la spécificité des champs à afficher dans l’interface d’administration pour modifier les données de la page, il y a les blueprints. C’est des fichiers YAML qui régissent les champs de données du site, des pages ou même des rôles pour les comptes. Chaque champ peut avoir un type (texte, nombre, date, données structurées…) et d’autres propriétés pour son affichage dans l’interface d’administration. Pour des explications plus poussée et davantage d’illustrations, je vous recommande ces articles par Anne-Sophie Tranchet ou par Diane Wattiez, qui dévoilent toutes les facettes de Kirby. L’important pour la suite c’est de savoir qu’un blueprint définit la structure des données pour une page, un champ, un rôle de compte…

Un nouveau code

Je vais tenter une petite analyse, en remontant les commits (importants) jusqu’à aujourd’hui.

• Kirby install 🎲 (59db692) — l’installation de Kirby, via Composer. Quatre plugins : beebmx/kirby-env pour utiliser un fichier .env différent selon les environnements (dev, stage, prod), getkirby/staticache pour générer une version statique du site et améliorer sa performance, sylvainjule/bouncer qui servira pour restreindre certaines parties du panel, et sylvainjule/matomo pour avoir quelques informations de statistiques dans le panel depuis notre Matomo maison.
• the whole damn website 🚜 (f4a7dc9) — c’est là que l’exercice échoue, étant donné que comme un gros malin j’ai commité d’un coup les trois premiers jours de travail. Il faut que je vous raconte mon process sur ces trois jours, puis du reste, dans la suite de l’article.

Avant de faire les tâches faciles, je me suis d’abord consacré à ce qui pouvait être potentiellement bloquant.

(Note pour la suite de l’article : je vais utiliser le masculin pour les personnes au rôle d’admin du site et le féminin pour les personnes au rôle d’auteur ou d’autrice des articles. c’est plus simple pour s’y retrouver quand je dis “il” et “elle”, et ça traduit la réalité : parmi les admins il y a plus d’hommes et parmi les autrices les femmes sont en majorité. les mentions du “panel” font référence à l’interface de gestion du site, que ce soit pour l’écriture ou l’administration.)

Dans le cas de 24 jours de web, on accueille 24 (voire plus) autrices pour qu’elles écrivent leurs articles. À la suite de quoi on pourra supprimer leurs comptes. Mais je tenais à ce que les autrices ne puissent pas accéder à d’autres articles que le leur.

• l’interface des pages d’articles est différente selon qu’on est admin, autrice ou correctrice. J’ai pu coder un plugin qui me permet de déclarer des blueprints de manière conditionnelle selon le rôle.
• de même, lorsqu’un admin doit paramétrer les pages auxquelles une autrice ou une correctrice a accès, les spécificités du champ de sélection de pages sont différentes selon le rôle de l’utilisatrice. Pour une autrice il faut proposer à l’admin les pages de l’édition à venir et chacune des pages d’autrices, alors que la correctrice a besoin d’accéder à la page de l’édition elle-même, ainsi qu’à la page de toutes les autrices. Dans le même plugin, j’ai pu faire en sorte que le champ de sélection soit adapté en fonction du compte d’utilisatrice qui est visité par l’admin. Lorsqu’un admin visite le compte d’un admin il n’y aura pas le champ (étant donné que l’admin a accès à tout), et lorsqu’une autrice visite son propre compte elle voit la liste des pages auxquelles elle a accès, mais ne peut pas les modifier.

Une fois confirmé que cette gestion était possible, j’ai pu entamer la migration.

D’abord, les gabarits (ou templates en parlance Kirby ou Wordpress). Comme il fallait tout reprendre à l’identique, j’ai copié-collé le HTML reçu du serveur en view-source:, en le comparant aux différents gabarits du thème Wordpress. Généralement il n’y a pas grand chose à ajuster, mais il ne faut pas oublier que Wordpress ajoute des classes au body ou autres trucs dans le genre qu’il faut ajouter au thème Kirby. Parallèlement à la conception des trois gabarits de pages (page par défaut, édition, article) et des fragments (snippets pour les parties head, en-tête et pied de page) j’ai créé mes fichiers de contenu. L’avantage de Kirby c’est son arborescence flat-file, où je peux ajouter et retirer des données sans passer par une interface, juste dans mon éditeur de texte.

Après avoir une bonne idée de la structure des données, j’ai fait les blueprints. C’est un travail de design autant qu’un travail de code, étant donné que c’est ce qui va donner son organisation à l’interface que l’admin ou l’autrice verra. Avoir un bon confort de rédaction et de relecture, ajuster la densité de l’info pour une autrice qui ne verra l’interface qu’une fois ou deux à l’opposé de l’admin qui est un power-user.

Avec les gabarits, la structure des contenus et les blueprints, le principal est fait pour la migration des données.

La migration des données

La séquence qui suit n’est pas le meilleur moyen de migrer des données de Wordpress vers Kirby. C’est du bricolage, fait en fonction de ce que j’avais sous la main.

Et ce que j’avais sous la main, c’était un dossier qui répliquait, via Wget, l’intégralité du site 24 jours de web, en suivant et sauvegardant tous les liens. C’est là que j’ai vu que l’API REST de Wordpress produisait des sorties JSON pour tous les articles.

Chaque fichier JSON contenait tout ce qu’il fallait pour l’importation. Le titre, la date, le slug (version simplifiée du titre à mettre dans les URL), le contenu en HTML rendu (pas de choses spécifiques à Wordpress), et via l’API REST, les URLs pour charger des informations sur les autrices et les commentaires.

Utilisant Python (parce que je connais bien), j’ai codé une moulinette qui, pour chaque fichier JSON, allait créer un fichier au bon nom, avec le bon contenu, dans le bon répertoire. D’un coup, le site qui n’avait que trois articles s’est retrouvé plein de toutes les archives de plus de dix ans d’articles !

… et des bugs graphiques à retoucher, des soucis plus ou moins gros de HTML inclus dans les fichiers, quelques petites frustrations, mais au final rien d’insurmontable.

Dans cette moulinette d’importation, j’avais hésité à importer les fichiers liés de chaque article… mais c’était trop de travail à modifier. Étant donné que le HTML était déjà rendu, il fallait repasser sur toutes les pages, changer le code d’affichage des images pour avoir la bonne URL, la bonne structure de nom, etc. J’ai préféré abandonner cette solution pour ces fichiers, et me résoudre à garder sur le serveur, à l’identique, l’arborescence wp-content/uploads/… qui avait été faite par Wordpress.

Chaque article dans Wordpress était associé à une autrice, dont les infos étaient stockées dans les infos du compte utilisé par l’autrice. Dans un premier temps j’ai importé ces données au sein de chaque article. J’avais prévu que l’autrice aurait la même interface pour écrire son article et pour écrire sa bio, renseigner ses liens, etc. Ce choix était un compromis, pour ne pas avoir à garder les comptes des autrices sur Kirby d’une année sur l’autre. J’ai modifié ça par la suite, j’en reparle plus bas.

Pour les commentaires, on touche à une limite de Kirby. N’étant pas un CMS pour blogs, il n’y a pas de gestion des commentaires. En discutant avec l’équipe, on s’est dit qu’en 2024 les conversations pourraient avoir lieu sur les réseaux sociaux (sauf Twitter), mais qu’il était important que les commentaires passés soient affichés sur le site.

Pour ça, ma moulinette a été modifiée pour pouvoir aussi sauvegarder les infos de commentaires. Comment les stocker dans Kirby ? Je ne me suis pas cassé la tête. Étant donné que j’avais l’adresse de l’API pour les commentaires, j’ai stocké le fichier JSON dans le répertoire des pages concernées sur Kirby. Pour les afficher, au chargement d’une page d’article Kirby va vérifier l’existence d’un fichier appelé comments.json parmi les fichiers de cette page, et va utiliser les données dans le gabarit : pour chaque commentaire tu affiches le nom, l’URL, le contenu…

…et le reste du foutu hibou

(le titre est en référence au meme)

Les flux (RSS et JSON) ont suivi. Pour les faire j’ai utilisé les techniques de routing de Kirby, avec un gabarit d’édition au format XML ou JSON. C’est une manière de diriger une route vers un gabarit spécifique avec des données particulières. Allez lire la doc, c’est très puissant.

La gestion des styles différents pour chaque édition n’a pas posé de problème : chaque page de contenu inclut le style CSS à appliquer aux articles de cette édition, et on peut modifier ce style directement dans le panel. Quelques petites pirouettes dans les gabarits pour récupérer ce champ de la page du parent de l’article, et le tour est joué.

En testant les pages d’articles, il est apparu plusieurs problèmes. Certains liens étaient en relatif, d’autres en absolu, il manquait des scripts ou des styles… bref, j’ai passé un coup de balai derrière tous les bugs au fur et à mesure. Il a fallu aussi gérer le cas de l’édition 2016, qui n’a pas d’articles mais qui a du contenu.

Un changement de style que j’ai apporté, c’était la mise en petites majuscules du premier mot d’un article s’il possède une lettrine. Ça a provoqué un imbroglio parce que la version de la typo ne comprenait pas de petites majuscules, mais en mettant à jour la version, les petites majuscules n’avaient pas d’accents ou autres signes diacritiques… donc on est revenus à la première version (qui simulait les petites majuscules en utilisant des majuscules, petites), en ajustant la typo pour que les soucis de dimensions ne se perçoivent pas. Le snobisme typographique des accents sur les majuscules passe avant le snobisme typographique plus obscur des formes de petites majuscules qui ne sont pas exactement les formes des majuscules.

Là on est environ trois semaines après le premier commit et le début du travail. Les autres membres de Paris Web qui œuvrent avec moi me font des retours sur le contenu, les styles, etc. Une idée nous vient : plusieurs autrices ont écrit des articles plusieurs années différentes, comment est-ce qu’on pourrait faire des liens entre ces articles ?

Là il a fallu que je sépare les autrices de leurs articles. Je suis retourné à ma moulinette qui a automagiquement créé des pages pour chacune des autrices, et la référence à ces nouvelles pages autrice dans les pages article.

À partir de ce point il a été possible de récupérer pour chaque autrice tous les articles qu’elle a écrit dans les éditions, et de les afficher sous son profil sous chaque article.

Mais là, nouvelle question : et si l’autrice a donné des conférences à Paris Web, pourquoi ne pas les lister en plus des autres articles, directement depuis le contenu de du site de PW ?

Étant donné que le site de Paris Web est aussi géré par Kirby et que la structure des données est assez similaire, j’ai développé un plugin de Kirby, utilisable sur PW ou 24jdw en ajustant les préférences. Ce plugin expose une liste de toutes les oratrices/autrices et pour chacune la liste de ses conférences/articles. Ces infos sont ensuite ingérées (et conservées) par l’autre site, qui va pouvoir les afficher. Magie !

Place au calendrier !

Ça y est, moins de 10 jours avant de pouvoir soulever la première languette du calendrier de l’avent 2024… l’équipe de Paris Web est sur les starting blocks, j’ai donné le relais à Gaël pour les styles de l’habillage, et les auteurs et autrices sont en train de remplir le site de leurs nouveaux articles passionnants.

Vous pouvez aller le voir sur 24joursdeweb.fr, abonnez-vous aux flux RSS ou JSON pour bien recevoir des articles tous les jours, et apprenez des trucs :)

---

PS: Je l’ai déjà donné plus haut, mais revoilà le lien du gist vers la moulinette que j’ai faite pour chercher les trucs et les machins de Wordpress et créer les fichiers de donnée de Kirby : https://gist.github.com/joachimesque/69a39382c7101ab00b74bf1465c34353. C’est un peu le bazar, et j’ai aussi inséré un fichier JSON d’exemple d’article. La première étape c’est un Wget qui ira chercher tout le bazar via la commande wget --recursive --no-clobber --page-requisites --html-extension --convert-links --domains 24joursdeweb.fr https://www.24joursdeweb.fr/, puis regarder dans le répertoire wp-json/wp/v2/posts. Bien évidemment depuis la migration ça ne marchera plus sur ce domaine.