PluXml + Git : mon processus de publication

La plupart du temps, j’écris mes billets durant mes trajets quotidiens en train. Soit 1h le matin et 1h le soir quand la SNCF parvient à faire circuler correctement ses TER. Mon processus d’écriture et de publication est relativement bien huilé :

1. Rédaction sous Word ou LibreOffice (ça dépend de l’OS sur lequel je suis) : ça me permet de bénéficier du correcteur orthographique 🙂 C’est la phase qui me prend le plus de temps.
2. Mise en forme HTML « a la mano » dans un éditeur (Visual Studio Code ou Mousepad) : bien que PluXml permette de bénéficier d’un éditeur Wysiwyg comme CKEditor, je préfère bosser à l’ancienne 😛
3. Copié-collé de ma prose dans l’interface admin de PluXml et paramétrage des attributs du billet (date, catégories, tags, etc.)

En moyenne, un billet représente 2 à 3 heures de travail. Si les deux premières étapes ne me posent pas de soucis dans le train, la troisième est plus problématique. En effet, n’ayant que très peu de plage de réseau 3G pendant mon trajet, il m’est impossible de travailler en ligne sur mon PluXml.

 

Du coup, pour pallier à ce problème, j’ai mis en place un dépôt Git pour mon blog (en prenant bien soin d’ignorer Piwik et les commentaires du blog).

 

Grâce à cela, je peux travailler non seulement le contenu du blog, mais aussi le contenant sur un PluXml local. Une fois mon billet terminé, et/ou mes fichiers modifiés, et le réseau retrouvé, un petit « add + commit + push + deploy » et le tour est joué.

Deuxième avantage, je peux bosser sur mes billets depuis n’importe laquelle de mes machines puisque Git me permet de les synchroniser. Enfin, dernier avantage et pas des moindres : je suis certain d’avoir toujours une sauvegarde à jour de mon blog (hormis les commentaires que je sauvegarde « a la mano » via ssh… faudra d’ailleurs que je m’occupe d’automatiser tout ça). ^^

Bref, je suis presque totalement satisfait de cette solution.

Ce fonctionnement me pose néanmoins 1 problème : si je constate une faute dans un de mes billets, je ne peux plus la corriger directement depuis l’interface admin de mon PluXml en ligne. Je suis obligé de passer par mon PluXml local puis rebelote : « add + commit + push + deploy ». Lorsqu’il s’agit d’une petite faute d’orthographe à corriger, ça fait beaucoup de travail pour pas grand-chose.

 

Je me suis alors posé la question de l’intérêt de tourner sur PluXml vu ma nouvelle méthodologie. J’ai donc jeté un coup d’œil à différents projets : Jekyll, Pelican, Octopress, etc. En fait, ces projets sont des générateurs de fichiers statiques. Une fois le fichier statique généré, il suffit de l’uploader (via Git par exemple). Oui, un tel système serait plus approprié dans mon cas. Malheureusement, le seul point négatif des CMS à la Jekyll est qu’ils ne gèrent pas les commentaires. Il me faudrait donc :

• utiliser un système de commentaire externalisé à la Disqus → hors de question
• créer moi-même un système de commentaires → pas le temps (et pas l’envie à vrai dire)

Conclusion : pour l’instant, PluXml reste la meilleure alternative. ^^