Besoins

Dure tâche que de choisir un moteur de site personnel. En bon(?) ingénieur, la première chose à faire est de définir les besoins :

• Publication de billets type blog
• Pages statiques de présentations
• Gestion de la syndication de contenu
• Catégorisation des billets
• Étiquetage des billets

Contraintes perso

À ces besoins s'ajoutent des contraintes éthiques :

• Hébergeable sur un VPS
• Basé sur des logiciels libres
• Respectueux de la vie privée
• Faible consommation de ressources

Ces contraintes sont très subjectives, et on pourrait débattre du "pourquoi" sans trouver d'issue honorable. Pour le volet technique, j'ai suffisamment de bagage pour me lancer dans différentes expérimentations tout en connaissant mes limites.

Tentatives

Par le passé, j'ai tenté Dotclear¹ et WordPress². Je n'avais aucune envie de me relancer dans la gestion de bases de données - j'ai déjà un Nextcloud³ en place -, et, concernant WordPress, je trouve que c'est un bien gros morceau pour la finalité recherchée : ce site perso me servira plus à archiver mes pensées, éventuellement partager modestement certaines expériences, mais pas plus.

Encore plus loin dans le temps (~2005), j'avais construit ma page de CV à la main en PHP. Avec gestion fr/en et génération de bibliographie bibtex ! Mais je suis trop vieux pour ces conneries.

Le statique c'est fantastique

De plus, la contrainte de faible consommation de ressources dictée par le rapport du GIEC⁴ m'a conduit, par les conseils de gens qui savent, vers la génération de sites statiques. Il s'agit d'éditer "à l'ancienne" les fichiers html qui seront servies par un serveur http classique.

Ce billet vous est donc offert par Pelican⁵, générateur de site statique, nettement mieux décrit sur cette page que ce que je pourrais faire.

Hackerman, ou la publication via Nextcloud

Lors de la génération d'un nouveau projet, l'assistant propose plusieurs type de publication : FTP, SSH, Github Pages,... Aucune ne me convenait : je sors d'une petite déception avec Pico, integré dans Nextcloud grâce à une App très bien faite. Mais finalement, mes limites techniques ont eu raison de ma persevérence (notamment sur la configuration de la réécriture d'URL, j'y reviendrai).

Mais j'ai gardé à l'esprit cette démarche : je veux pouvoir éditer mes billets confortablement sur ma machine locale et publier le contenu sur mon VPS qui héberge aussi mon instance Nextcloud.

Facile : mon espace disque Nextcloud est synchronisé localement. Il suffit donc d'éditer les fichiers de content/ !

Lors de la publication, le contenu généré en html va dans un répertoire output, toujours dans mon espace Nextcloud partagé localement : j'ai donc simplement créé un lien symbolique vers ce répertoire dans le DocumentRoot de mon serveur apache (/var/www/html chez moi).

Il y a deux méthodes de publication :

• $> pelican content/
• $> make publish

La première utilise le fichier de configuration pelicanconf.py. La deuxième utilise publishconf.py, qui ne fait que reprendre les valeurs du premier et réécrit certaines autres. Afin de créer une sorte de pre-release, le repertoire de sortie de pelicanconf.py est output/draft/. Cela me permet de tester dans le navigateur la génération de contenu. Le fichier publishconf.py réécrit OUTPUT_PATH = 'output/'

Et après...

Il me reste à gérer correctement le SSL et les réécritures d'URL, la présence de Nextcloud sur le même serveur ne me simplifie pas la tâche. Surtout parce que j'ai laissé faire une installation "par défaut". A priori, la configuration d'Apache est telle qu'elle considère Nextcloud comme le seul point d'entrée sur le serveur.

Vous pouvez tenter https://djelly.calut.fr. Vous serez renvoyés sur mon cloud, avec une erreur de domaine non approuvé (ce qui est un peu rassurant quand même !)

Et bien sûr, personnaliser tout cela de belle façon - pour l'instant, le thème par défaut est utilisé.

Disclaimer: ne vous syndiquez pas pour l'instant !!