Pelican, un générateur de blog statique.

Posté par (page perso) . Modéré par Xavier Teyssier.
Tags :
23
7
nov.
2010
Python
Pelican est un logiciel en Python sous licence AGPL qui permet de générer un blog de manière statique, de manière à pouvoir l'héberger facilement : pas besoin de langage de script côté serveur, les pages sont générées sur votre machine.

Il est possible d'utiliser les syntaxes markdown ou restructured text pour écrire vos articles, ainsi que l'éditeur de texte de votre choix. Le système est fait de manière à pouvoir accueillir simplement de nouvelles syntaxes.

Pelican supporte actuellement les articles, catégories, tags, commentaires (via disqus), l'export des articles vers PDF, les pages et la gestion des thèmes.
  • # Import depuis WP

    Posté par (page perso) . Évalué à 5.

    Ce projet à l'air très intéressant (parce que j'aime beaucoup la syntaxe Markdown pour écrire des trucs), et j'ai vraiment envie de l'essayer, cependant, est-il possible de faire un import facilement depuis une installation de Wordpress ?

    Si non, ça risque d'être un gros frein (tout migrer à la main, ça prend beaucoup de temps).

    Par contre, pas de gestion des images / fichiers associés ?
    • [^] # Re: Import depuis WP

      Posté par (page perso) . Évalué à 5.

      Pour la gestion des imports depuis wordpress, je n'ai pas trouvé de manière de faire ça de manière exacte. J'ai fait un petit script qui demanderais encore un peu de paufinage pour être réellement utilisable, mais qui m'a permis de récupérer la quasi totalité des articles de mon installation wordpress.

      Ca gère partiellement les images pour l'instant: je n'arrive pas à penser à un moyen efficace pour les inclure dans l'output actuellement. Je me mets ça sur la TODO list :)
      • [^] # Re: Import depuis WP

        Posté par (page perso) . Évalué à 2.

        J'oubliais, le script en question: http://hg.lolnet.org/pelican/rev/2d50d32db523
      • [^] # Re: Import depuis WP

        Posté par . Évalué à 1.

        De la même façon pour le include,
        j'utilise aussi beaucoup dans mes fichiers rst
        en entête quelque chose du genre :
        .. include:: ../glossaire.conf.
        avec dans glossaire :
        .. |cdp| replace:: Chef de Projet
        et dans mon texte pour gagner du temps à la saisie :
        ...le |cdp| a pris en charge...

        Ce qui ne marche pas avec le script pelican !
        Autrement très pratique !
    • [^] # Re: Import depuis WP

      Posté par . Évalué à 1.

      Ce projet à l'air très intéressant [...]

      Perso, je pense qu'il est bien plus qu'intéressant. Bon, j'admets volontiers que c'est en lisant cette dépèche que j'ai appris qu'il en existait d'autres de ce type mais je ne vois que des avantages à ce genre de gestion. (Attendez avant de tirer ;) ...)

      Comparé aux systèmes avec bases de données, utilisées principalement pour stocker des articles statiques (et même si à la base on a affaire à un gestionnaire de communautés, on se retrouve souvent avec un CMS incluant d'office une base de données), on élimine du coup une tripotée de failles de sécurité potentielles (attaques par injection SQL, écriture sur disque par le serveur web, parcourt du système de fichiers par le service web, etc).

      Perso, je préfère sacrifier du dynamisme en faveur de la sécurité. (Si c'était à refaire, on ne m'y reprendrais d'ailleurs plus.) Un tel système favorise d'ailleurs la séparation entre les contenus dynamique et statique. Rien n'empêche d'ailleurs, à l'instar de disqus, d'avoir un service de commentaires dans un environnement séparé (p.ex. un conteneur OpenVZ, un chroot apache/lighttpd ou que sais-je) et de lier le tout via des blocs interprétés dans un module apache (j'invente) ou via Javascript et des services web, authentifiés ou non à travers un SSO.

      Avec un contenu dynamique séparé, on ne doit pas fermer le site en cas de maintenance de la base de données, par exemple et le contenu peut rester accessible. Autre avantage non négligeable aussi, c'est la réplication par SSH, GIT, SVN... D'accord, on déplace [les conséquences et l'impact de] la sécurité mais au moins [il est possible de faire en sorte qu'] une attaque en règle ne modifiera pas le contenu (ou les articles).

      J'ai toujours rechigné à installer des CMS à base de données, estimant que ça revenait à se chercher des ennuis comme un aimant attire la limaille...
      • [^] # Re: Import depuis WP

        Posté par . Évalué à 2.

        C'est possible d'avoir un truc joli sous Joomla par exemple, et tout récupérer en html statique avec un aspirateur web ?

        "La première sécurité est la liberté"

  • # Commentaires

    Posté par (page perso) . Évalué à 10.

    S'il y a un truc qui me chiffonne avec ces systèmes, c'est la gestion des commentaires : disqus c'est un service externe, pas libre, et qui requiert JavaScript. On n'est pas maître de ses données. Je me souviens d'ailleurs d'un service similaire qui était utilisé (HaloScan?) qui est maintenant fermé (donc tout est perdu), et qui quand il était en opération supprimait les anciens commentaires…

    DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: Commentaires

      Posté par (page perso) . Évalué à 2.

      C'est en effet ennuyeux de devoir passer par un service externe pour les commentaires, mais avec un blog statique je ne vois pas comment faire autrement. C'est le même problème pour nanoblogger.

      Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

      • [^] # Re: Commentaires

        Posté par . Évalué à 2.

        On passe par le mail pour l'envoie des commentaires et une petite moulinette permet des les importer sur le blog ?
        • [^] # Re: Commentaires

          Posté par (page perso) . Évalué à 1.

          C'est vrai que c'est problématique. Le souci avec les mails pour commentaires, c'est qu'il faut du coup gérer quelque chose pour faire la moulinette.

          Je vais ajouter une notice quand à l'utilisation de disqus pour les commentaires et de tout ce que ça implique.
        • [^] # Re: Commentaires

          Posté par . Évalué à 2.

          Le problème des mails c'est tout de suite le spam.

          Puis, il faut ouvrir son client pour l'envoyer ce qui fait tout de suite 2 applications pour lire et participer a un blog... Le but de Pelican est de fournir un moyen de servie des pages statiques et donc, de ne pas dépendre de tout contenu généré ou dynamique. Tout le contraire des commentaires donc.

          Mais je vous souhaite bonne chance pour trouver un système indépendant, qui peu détecter le spam, et qui ne soit pas trop lourd pour le lecteur occasionnel voulant laisser une trace :)
        • [^] # Re: Commentaires

          Posté par (page perso) . Évalué à 1.

          J'avais il y a quelque temps créé un petit script de blog dont le principe était similaire à Pelican. Pour le système de commentaires, chaque article disposait d'un formulaire qui enregistrait le contenu dans un fichier et envoyait un mail pour prévenir de l'arrivée d'un nouveau commentaire qu'il suffisait donc d'importer, puis lancer la regénération de l'article.

          Le grand problème des commentaires, c'est en effet le spam, et ce système est vite devenu ingérable : pour un commentaire utilisateur, il y avait 10 à 20 commentaires contenant du spam.

          Trois solutions à ce problème donc :

          1) Mettre un captcha à la validation du commentaire (le meilleur moyen de dissuader les visiteurs de contribuer).
          2) Utiliser un filtre anti-spam comme Akismet (complexité supplémentaire, alourdit l'application car nécessité d'ajouter une interface de validation des commentaires en cas de faux positif : on s'éloigne donc de la simplicité et de la légèreté recherchée ininitialement).
          3) Utiliser un service de gestion des commentaires externe tel que Disqus, mais vient alors le problème évoqué plus haut : ce n'est pas libre et l'on n'est pas propriétaire des données.

          Au final, la solution ne serait-elle pas une alternative libre à Disqus que l'on pourrait héberger soit même?
          • [^] # Re: Commentaires

            Posté par . Évalué à 3.

            Au final, la solution ne serait-elle pas une alternative libre à Disqus que l'on pourrait héberger soi-même?
            Ça ne rentre pas un peu en contradiction avec le fait de vouloir maintenir un blog statique ?

            Depending on the time of day, the French go either way.

          • [^] # Re: Commentaires

            Posté par (page perso) . Évalué à 3.

            Si le commentaire passe par l'email, il pourrait aussi passer par le filtre antispam du client email (ou du serveur) et ainsi être filtré.

            À priori, ça pourrait relativement bien fonctionner ce genre de chose non ?
          • [^] # Re: Commentaires

            Posté par . Évalué à 1.

            Ou bien un système ou les commentaires sont hébergés par le commentateur et non par l'auteur du blog ?

            Je ne suis pas certain de comment ça pourrait marcher et ça poserait d'autres problèmes mais je trouve l'idée intéressante.
            • [^] # Re: Commentaires

              Posté par (page perso) . Évalué à 2.

              Il y a le système de trackback (on poste sur son blog qui fait un lien vers un autre article de blog) mais c'est encore plus un nid à spam que le reste.

              Bref j'ai fait ma critique mais je ne prétends pas avoir la solution ultime… je suis utilisateur frustré de WordPress :(

              DLFP >> PCInpact > Numerama >> LinuxFr.org

          • [^] # Re: Commentaires

            Posté par . Évalué à 1.

            Si on confie les commentaires à une moulinette par email (avec comme tu proposes, envoie du commentaire par mail pour approbation par l'admin du blog), on peut confier le traitement du spam aux logiciels déjà intégrés dans une chaine email classique (spamassassin et compagnie par exemple).
            Dans ce cas, on peut même se passer de l'étape d'approbation et une fois que l'email a passé les filtres, lancer la régénération de la page en question sur le blog en y intégrant le commentaire.
            • [^] # Re: Commentaires

              Posté par (page perso) . Évalué à 1.

              Un des objectifs de pelican, c'est d'être simple.

              Malheureusement, le système de commentaires par mail ne me semble pas être simple du tout, et nécessite une installation assez lourde coté serveur, que tout le monde ne peut pas avoir.

              D'une manière générale, je considère la gestion des commentaires comme étant quelque chose "en plus": si les commentaires sont vraiment necessaires, alors il est possible d'integrer disqus.

              Mais tout autre système est envisageable: disqus est assez simple à "plugger" à un site statique, puisque tout est géré à la volée, en javascript. Tout système similaire s'adapterait sans problèmes.

              D'une manière générale, il est possible de gérer un système de commentaires avec une mailing-list + une iframe des archives (bouh, non, j'ai pas pensé ça, dites moi que j'ai pas dis iframe) sur chaque page/article: chaque personne utilise donc son propre email pour communiquer, et c'est relayé sur les commentaires du blog. Filtrage/spam et compagnie sont gérés par la mailing list au passage (mailman ?).

              Ca fonctionne, mais je trouve ça quand même assez peu elegant, non ?
  • # hyde

    Posté par (page perso) . Évalué à 6.

    ça à l'air interessant
    Il en existe déjà beaucoup du même genre: Webgen, nanoc, Jekyll, Hyde, Webby, Hobix, Bricolage, etc ...

    J'ai essayé hyde mais j'ai fini par laissé tombé car, il supporte soit-disant restructuredText mais en fait mal. Y'a des bugs à droite à gauche que le dev règle quand il veut bien. Ou dit qu'il va le faire sans jamais le faire. C'est dommage. Il est interessant; en python utilisant les templates django, avec la possibilité d'utiliser des hooks pour la generation des css, et autres ... donc plein de features mais pas vraiement abouties et/ou buggées.

    pour pelican, ça a l'air bien. pas trop testé encore
    ça serait bien de préciser que c'est basé sur des templates jinja2.

    j'apprécierais une liste des dépendances pour ceux qui n'utilisent pas pip sur le site web (mais bon ca se trouve dans pelican.egg-info/requires.txt )

    et puis une dépendance optionnelle sur rst2pdf serait bien, parce que j'en vois mal l'intérêt pour l'instant

    quand je génére une site comme ça:
    pelican prog/dvcs/git/pelican/samples/content
    la première category est appellé prog/dvcs/git/pelican/samples/content. Pas très sexy. bug ? je veux dire sur la page web dans le menu et même l'url est comme ça
    • [^] # Re: hyde

      Posté par (page perso) . Évalué à 1.

      C'est vrai, il en existe quelques uns, je ne les connaissait pas tous d'ailleurs, mais ceux que j'ai regardé avant de commencer étaient soit trop complexe, soit pas assez à mon gout. Je préfère me concentrer sur peu de fonctionnalités, puis en ajouter au fur et à mesure de mes besoins/retours.

      J'ai passé la dépendance à rst2pdf en optionnelle, ainsi que mis à jour la documentation avec la liste des dépendances.

      Pour la gestion des catégories, c'est effectivement un bug. Je viens de le corriger (http://hg.notmyidea.org/pelican/rev/c888a94fff70). Merci !
      • [^] # Re: hyde

        Posté par (page perso) . Évalué à 2.

        ok.
        au sujet de rst2pdf, quand je lance pelican il me donne une exception ImportError si je n'ai pas rst2pdf d'installer. Il faut changer le code aussi, non ?

        C'est ça que je voulais dire: Ne pas avoir à installer rst2pdf si on ne l'utilise pas pour lancer pelican

        faudrait une option de config pour ça ?? j'ai pas regardé comment ca se passe.

        bref. j'insiste et en demande peut-être trop pour pas grand-chose. désolé
    • [^] # Re: hyde

      Posté par . Évalué à 1.

      Nommons aussi l'extension pour Mercurial Talaria [http://mercurial.selenic.com/wiki/TalariaExtension], et HgBlog [http://bitbucket.org/codekoala/hgblog/], dans un esprit me semble-t-il similaire.
      Si quelqu'un avait un avis éclairé pour mettre en lumière (forcément) les différences, points forts et faibles respectifs ?-)
  • # Intéressant

    Posté par . Évalué à 1.

    Je suis convaincu de la pertinence des générateurs de pages statiques pour des sites genre blog, etc... (surtout au vu des perfs PHP/MySQL des hébergements gratuits).
    Depuis quelques mois j'utilise jekyll https://github.com/mojombo/jekyll (écrit en ruby) et je me réjouis qu'il y ait des choses similaires en python.

    Il y a des choses à y voir du côté de l'import depuis des CMS classiques (wordpress, ...)

    Concernant la date inclue dans l'entête du fichier markdown, jekyll a choisi l'approche de mettre la date dans le nom du fichier, surchargeable dans l'entête, ce qui donne une assez grande souplesse dans la gestion de la date par exemple.
    Ce qui serait bien, c'est que , outre le format de marquage léger (markdown, textile, ...), ce genre de conventions soient partagés entre les différents projets. Cela permet entre autre de changer d'outil assez facilement, sans moulinette de conversion.

    Bonne continuation !
  • # Syntaxe Markdown

    Posté par . Évalué à 1.

    J'ai testé un peu le truc. En fait, c'est ce que je cherchait depuis pas mal de temps. Souhaitant m'auto-héberger, je cherche quelques chose de très léger.

    Par contre, j'ai une peu de soucis avec la syntaxe markdown. J'arrive pas à créer de simple lien, les niveaux de titre non plus...

    Je me suis référé à cette page : http://daringfireball.net/projects/markdown/basics et en recopiant les exemples, ça ne marche pas. A moins que je me sois trompé de langage de balisage, ce qui est aussi probable : )

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.