Utiliser un CMS / générateur de site statique, bonne ou mauvaise idée ?

Hello tout le monde !

Je suis en train de me pencher sur un sérieux ravalement de façade pour mon blog, ce qui passera à la fois par de l’esthétique mais aussi un changement d’outil d’édition.

Actuellement je suis avec un bon vieux wordpress avec des plugins divers et variés. Cette solution ne me conviens plus car j’ai vraiment la sensation de faire du bricolage et de ne pas maîtriser mes outils si je souhaite faire une modif’ dessus (PHP c’est pas trop mon truc, et j’ai une impression d’usine à gaz monstre quand j’envisage de modifier mon thème).

Je compte donc passer sur une techno python (langage que je maîtrise plus et sur lequel je souhaite évoluer). Cependant, je me tate sur un aspect : le framework.

Initialement, je pensais partir avec mezzanine. Je connais Django et donc ça me semblait un choix décent. Puis ensuite je me suis souvenu des générateurs de sites statiques, comme Pelican (python aussi). Et vu que mon blog évolue peu/rarement/jamais, ca semble pas déconnant non plus (couplé à un git + github pages et je pourrais même virer mon hébergement).

Des idées sur le sujet / des conseils et / ou retours d’expériences à partager ?

C’est exactement la réflexion qui m’a poussé à réfléchir aux moteurs statiques. De ce que je vois, Hugo est fait en … Go. Du coup comme j’ai envie de custom’ l’affichage je vais sûrement galérer à devoir apprendre de nouvelles choses (ce que je n’aurais pas le temps de faire…). Mais la réflexion sur l’utilisation d’un générateur statique tient toujours elle (et paf, un bon point pour pelican).

@Ge0 : Je me souviens de notre discussion, et comme tu vois j’avance très doucement dans mes réflexions. Pour ce qui est du template, je vais essayer de me faire du cousu main, c’est pourquoi je souhaite rester dans des cadres que je connais (moteur de template django ou jinja par exemple). Du coup comme ci-dessus, ça éloigne les langages que je ne maîtrise pas (comme ruby). Lektor semble intéressant aussi, j’y jetterais sûrement un oeil.

Là ou pelican me tente aussi, c’est qu’il à l’air facile pour plugguer un nouveau convertisseur, et vous m’voyez ptet venir mais je pensais bien rajouter un convertisseur zmarkdown pour avoir des exports pdf/epub des pages…

En fait, Hugo utilise des templates. Tu peux aller très loin sans toucher une seule ligne de Go – en fait je suis même à peu près sûr que c’est une mauvaise idée de toucher le moteur de génération, et donc de faire du Go.

Si tu veux, j’ai un script pour lui faire générer des epub et des PDF (cf https://textes.spacefox.fr pour des exemples). La génération de ces formats passe par pandoc, avec ce que ça apporte comme avantages et inconvénients.

PS : si Pelican utilise un moteur de templates que tu connais déjà, par contre, c’est en effet un énorme plus pour lui.

Mon site est aussi en Hugo. C’est genre rapide à customiser, ça fait le taf, les articles sont en markdown, donc niveau import entre zds et mon site ça passe quasi crème.

Je plussoie SpaceFox, tu n’auras pas toucher à Go.

Y a flask qu’est sympa aussi !

Pour le coup, Flask n’est pas un CMS mais un micro-framework. Je ne pense pas que ce soit ce qu’Eskimon recherche.

Et si je veux customiser pour ajouter un renderer 100% zds compliant ? (Celui en fin de dev actuel ?)

Yep je connais flask et yep ce n’est pas ce que je cherche

À moins que le moteur ne propose explicitement une interface d’extension du rendu (je ne me suis pas posé la question concernant Hugo), ça me paraît être une très mauvaise idée de modifier le système de rendu : si tu fais ça, tu casses la compatibilité avec les futures versions (ou alors tu auras une modif à porter à chaque nouvelle version).

Je ne connais pas assez les autres moteurs de rendu, mais Hugo a une notion de shortcodes qui permettent d’aller très loin sans toucher au moteur (cf le dépôt de ce thème, dans lequel il n’y a pas de Go).

Selon ton générateur de site, soit tu peux partir sur une customisation s’il a une API pour ce faire, soit sur une transcription des MD du ZdS.

À noter qu’il y a toujours la question des métadonnées, qui nécessiteront probablement de re-passer sur les fichiers Markdown d’origine.

Je faisais référence à ça (un reader dans le jargon pelican) : http://docs.getpelican.com/en/stable/internals.html#how-to-implement-a-new-reader

Donc visiblement tu es dans le cas où il y a une API d’extension