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.
Aller plus loin
- La page du projet (1044 clics)
- Le dépôt sur github (249 clics)
- Un exemple de blog (842 clics)
# Import depuis WP
Posté par Artefact2 (site web personnel) . Évalué à 5.
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 Alexis Metaireau (site web personnel) . Évalué à 5.
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 Alexis Metaireau (site web personnel) . Évalué à 2.
[^] # Re: Import depuis WP
Posté par dtrystram . Évalué à 1.
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 FantastIX . Évalué à 1.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
# Commentaires
Posté par DLFP est mort . Évalué à 10.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Commentaires
Posté par erdnaxeli (site web personnel) . Évalué à 2.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Commentaires
Posté par M . Évalué à 2.
[^] # Re: Commentaires
Posté par Alexis Metaireau (site web personnel) . Évalué à 1.
Je vais ajouter une notice quand à l'utilisation de disqus pour les commentaires et de tout ce que ça implique.
[^] # Re: Commentaires
Posté par xrogaan . Évalué à 2.
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 Frederic Cambus (site web personnel) . Évalué à 1.
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 Frank-N-Furter . Évalué à 3.
Ç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 Nicolas Évrard (site web personnel, Mastodon) . Évalué à 3.
À priori, ça pourrait relativement bien fonctionner ce genre de chose non ?
[^] # Re: Commentaires
Posté par ... a little wood elfe . Évalué à 1.
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 DLFP est mort . Évalué à 2.
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 nonas . Évalué à 1.
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 Alexis Metaireau (site web personnel) . Évalué à 1.
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 solsTiCe (site web personnel) . Évalué à 6.
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 Alexis Metaireau (site web personnel) . Évalué à 1.
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 solsTiCe (site web personnel) . Évalué à 2.
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 Alexis Metaireau (site web personnel) . Évalué à 1.
[^] # Re: hyde
Posté par fero14041 . Évalué à 1.
Si quelqu'un avait un avis éclairé pour mettre en lumière (forcément) les différences, points forts et faibles respectifs ?-)
[^] # Re: hyde
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
[^] # Re: hyde
Posté par Emmanuel Seyman . Évalué à 1.
[^] # Re: hyde
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: hyde
Posté par Alexis Metaireau (site web personnel) . Évalué à 1.
[^] # Re: hyde
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: hyde
Posté par MrLapinot (site web personnel) . Évalué à 2.
Exemple de résultat : http://wiki.darcs.net/
# Intéressant
Posté par danc5 . Évalué à 1.
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 msg_dracula . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.