Nouvelles du blog
nah,
08 mars 2020,
Mots clés
blog, PluXml,
classé dans Blog
Ça fait un moment que j'hésitais à lâcher PluXML. Non pas parce que j'aime pas ce CMS (bien au contraire), mais à cause de certains détails agaçant.
Je l'utilise depuis 2010 (quasiment une décennie), mais depuis, ma procédure de rédaction des articles a pas mal évolué.
Mes derniers articles sont rédigés en ReStructuredText (rst), un langage de balisage léger, dans le même style que Markdown ou Textile, via ReText, suivi d'un export au format html, et enfin copier-coller dans l'éditeur html de PluXML.
Cela fait donc plusieurs étapes entre la rédaction et l'aperçu dans le blog, avec la répétition de toute la procédure si je veux éditer ou corriger un truc.
À noter : j'utilise la même procédure pour nv, qui tourne aussi sous PluXML.
Par exemple, la dernière fiction du mercredi a été rédigée en reStructuredText, à partir d'une idée tenant sur une ligne, puis exportée en html, etc.
https://nouvelles.chibi-nah.fr/controle-z-d
Par contre, pour mes pages de docs, j'utilise une procédure totalement différente. Là, je passe par Sphinx-doc, git, et quelques hooks.
Pour la rédaction, j'utilise aussi bien ReText, Geany ou Visual Studio Code (pas de troll, merci).
Je génère les pages en local pour contrôler le contenu. Le suivi des révisions étant géré par git, cela signifie donc que je peux aussi bien bosser avec Ryoko comme avec Yue. Et pour la publication ? Un simple git push, et c'est tout. Les pages sont générées sur le serveur puis copiés vers le répertoire de destination. Pas de copie via ftp ou scp. Pas de prise de tête.
Un processus totalement différent par rapport au blog.
Mon occupation actuelle est de reprendre tous les articles du blog (un peu moins d'une centaine), que j'ai converti en Markdown, via un script python, dont David Revoy a parlé récemment.
https://www.davidrevoy.com/moving-to-markdown
https://github.com/KillianKemps/Pluxml-to-Markdown
Cependant, le contenu du blog étant essentiellement statique (les commentaires étant modérés, voire carrément désactivés), l'intérêt d'un CMS générant dynamiquement les pages est discutable. Je pense m'orienter vers un générateur statique. Pas Sphinx-doc, qui ne correspond pas à mes prérequis pour un blog (pour de la documentation, c'est juste génial). Plutôt Pelican (que je teste en ce moment).
Cela nécessite pas mal de travail. Notamment insérer toutes les métadonnées dans chacune des pages (date de publication, auteur, tags). Et chose importante : essayer de garder les mêmes URL que celles générées avec PluXML.
La migration du blog s'effectuera dans les prochaines semaines, une fois les articles corrigés et le thème mis en place.
Haut de page