Nerdkrams
Ins Internet schrei­ben mit Pelican

(Vorbemerkung: Dies ist eine leicht über­ar­bei­te­te Variante eines Beitrags, den ich schon anders­wo ver­öf­fent­licht hatte.)

Mir ist schon seit einer Weile auf­grund von Performance- und Sicherheitsproblemen danach, WordPress, das ich seit inzwi­schen neun Jahren nut­ze, auf die­sem klei­nen Textveröffentlichungsdings ein­mal durch etwas Anderes aus­zu­tau­schen. Nicht aber gegen ein ande­res „rich­ti­ges“ Blogsystem wie s9y und Ghost, denn damit hät­te ich nicht viel gewon­nen, hin­ge­gen eini­ges ver­lo­ren (gera­de auch weil Ghost immer noch kein brauch­ba­res Kommentarsystem hat und ich sicher­lich nicht anfan­gen wer­de, inter­es­sier­ten Kommentatoren JavaScript auf­zu­zwin­gen). Interessanter sind da schon Seitengeneratoren wie Jekyll und des­sen Frameworks (etwa Octopress), die zwar auch meist kei­ne Kommentarfunktion, dafür aber vie­le wei­te­re Vorteile mit­brin­gen, zum Beispiel, dass man sein Blog mit git ver­sio­nie­ren kann und nicht auf einen PHP/MySQL-Stack ange­wie­sen ist, weil die Website direkt als HTML aus­ge­ge­ben wird und nicht bei jedem Aufruf neu erzeugt wer­den muss. Franz hat die Vorteile eines sol­chen Bloggenerators ein­mal aufgezählt.

Nun ist Jekyll längst nicht das ein­zi­ge Werkzeug die­ser Art, die Auswahl ist rie­sig; gera­de, wenn man in der Sprache Ruby nicht hei­misch ist, ist das Erzeugen eines neu­en Blogeintrags in (zum Beispiel) Octopress auch eine unnö­tig kom­pli­zier­te Sache. Außerdem scheint es unmög­lich zu sein, ein Octopress-Theme zu ent­wickeln, das nicht aus­sieht wie aus­ge­kotzt. Oder hat es nur noch nie­mand versucht?

Warum nicht Pelican?

Unter den Alternativen beson­ders inter­es­sant fin­de ich Pelican, das anders­wo als ein­fach beschrie­ben wird und jüngst in Version 3.5 erschien. Ein guter Anlass, es mir mal anzu­se­hen. Dafür brau­che ich ja nur Python 2.7 und einen belie­big ein­fa­chen Webserver, der Rest ver­läuft nach der Anleitung. Wird die fal­sche Python-Version - stan­dard­mä­ßig ist das oft nicht 2.7 - ver­wen­det, so schlägt pip install peli­can so erheb­lich fehl, dass der anschlie­ßen­de Aufruf von peli­can-quick­start nur zwei Syntaxfehler zur Folge hat. Vor der Installation soll­te mit python -V also drin­gend über­prüft wer­den, ob Python 2.7 die akti­ve Version ist.

Quickstart!

peli­can-quick­start funk­tio­niert danach jeden­falls wie gewünscht: Eintippen, ein paar Fragen beant­wor­ten und es kann los­ge­hen. Dies rich­tet im Wesentlichen die Datei pelicanconf.py ein, die sozu­sa­gen das Organisatorische über­nimmt: Blogtitel, Permalinkstruktur und ähn­li­che Optionen wer­den dort fest­ge­legt. Bei der Gelegenheit soll­te dort gleich der OUTPUT_PATH so ange­passt wer­den, dass die erzeug­ten HTML-Dateien im rich­ti­gen Ordner landen.

Zeit für den ersten Testartikel.

peli­can benutzt stan­dard­mä­ßig den Ordner ./content/ für Entwürfe. Wenn per pip oder easy_install eine lauf­fä­hi­ge Version von Markdown instal­liert ist, ver­steht es auch Markdown, eine Auszeichnungssprache, die von Diaspora, Ghost, Stack Overflow, GitHub und wei­te­ren Plattformen bereits benutzt wird und die zu ler­nen ich also sowie­so empfehle.

Pelican ver­wen­det wie wohl alle sta­ti­schen Generatoren Reintextdateien statt einer kom­ple­xen Datenbank. Es lässt sich also schlicht Folgendes tun:

emacs content/new-blog-post.md

Der Dateiname ist weit­ge­hend egal, ihr könnt die Beiträge also auch durch­num­me­rie­ren oder das Datum in den Dateinamen schreiben.

Ein funk­tio­nie­ren­des Beispiel für so einen Blogartikel mit Kategorien, Tags und modi­fi­zier­tem Permalink (slug) sieht jeden­falls so aus:

Title: Beispielbeitrag
Date: 2014-10-28 20:00
Modified: 2014-10-28 20:01
Category: Nerdkrams
Tags: hirnfick,pelican
Slug: ein-beispiel
Authors: tux.
Summary: Der Beispielbeitrag ist ein Beispiel.
Dies ist der erste Beitrag, den ich auf Pelican schreibe.
Seht mal, *Markdown* **geht auch!**.
<u>HTML übrigens auch.</u>

Wie ihr seht, gehört der erste Teil eines Blogartikels immer den Metadaten, ihr könnt also ziem­lich leicht den Namen des Autors oder das Veröffentlichungsdatum ändern. Mit Emacs und org-mode lie­ße sich das auto­ma­ti­sie­ren, aber sicher­lich gibt es da vie­le wei­te­re Möglichkeiten. Es ist natür­lich auch mög­lich, das Datum aus dem Dateisystem zu übernehmen.

Release, release.

Wenn euch der Beispielbeitrag so gefällt, könnt ihr ihn veröffentlichen:

cd ~
pelican

Ta-dah:

Pelican

Plugins

So fle­xi­bel das Pelican-System wegen der Kompilierung auch erschei­nen mag, natür­lich gibt es immer etwas, was für den eige­nen Einsatz fehlt. WordPress wird ja auch für sei­ne Erweiterbarkeit von vie­len Nutzern geschätzt. Aber wer sagt, dass „sta­tisch“ immer „unfle­xi­bel“ bedeu­ten muss?

Tatsächlich gibt es auch für Pelican eine Vielzahl an Plugins, die den erzeug­ten HTML-Seiten etwas Würze ver­lei­hen. Anzeige des Gravatars für Artikelautoren? Funktioniert. YouTube? Etwas umständ­lich, aber kein Problem. Eine Sitemap für die SEO-Verrückten? Warum nicht?

Alle Funktionen sind da, aber es könn­te noch etwas hüb­scher aus­se­hen? Auch Pelican kennt Themes, eine Vielzahl von ihnen ist auf GitHub zu fin­den. Es genügt, ein Theme in den Ordner /themes zu kopie­ren und in der Datei pelicanconf.py ein­zu­tra­gen - beim näch­sten Generieren wird es auto­ma­tisch verwendet.

Kommentare

Da die mit Pelican erzeug­te Website nicht erst beim Aufruf erzeugt wird, sind Kommentare, die in einer Datenbank lie­gen, hier nicht ohne Weiteres mög­lich. Die offen­sicht­li­che Lösung, sta­ti­sche Kommentare im Stil klas­si­scher Leserbriefe per E-Mail zu ermög­li­chen, ist auf Websites mit einer hohen Frequenz an Benutzerinteraktion mit­un­ter zu auf­wän­dig. Wer damit leben kann, dass Kommentare JavaScript vor­aus­set­zen, der kann zu eta­blier­ten Fremdanbietern wie Disqus, das in vie­le Pelican-Themes bereits inte­griert ist, oder IntenseDebate grei­fen oder ein selbst­ge­ho­ste­tes Kommentarsystem wie etwa HashOver oder Isso ein­bin­den. Dafür muss nur im Theme eine ent­spre­chen­de Anpassung erfol­gen, bei der Gelegenheit las­sen sich die Kommentare auch gleich per CSS optisch anpassen.

Fazit

Alles in Allem: Pelican ist mehr als nur ein net­tes Spielzeug. Es gibt einen WordPress-Import und Plugins für aller­lei Einsatzzwecke. Ich emp­feh­le Pelican mal im Auge zu behal­ten. Es muss ja nicht immer ein auf­ge­bläh­tes CMS sein.

Senfecke:

    • Sofern WordPress nicht bis dahin wie­der benutz­bar wird, es einen daten­schutz­kon­for­men Kommentarbereich mit Spamfilter für Pelican gibt und ich mal die Muße habe, das Theme die­ses Nichtblogs auf Pelican zu por­tie­ren: ja. Ich rech­ne aller­dings nicht mehr mit die­sem Jahr. Erst mal die Abschlussarbeit fer­tig schrei­ben. Und die Musikrückschau 2014/2 steht ja auch noch an.

  1. Ich hat­te die­ses Gedanken x-fach her­um­ge­wälzt und bin im Laufe der letz­ten zehn Jahre+ an Bloggen sogar mehr­fach zwi­schen WordPress, Wiki-Engines zum Bloggen, Blosxom Py & Php, Jekyll, Octopress, Pelican, diver­sen sta­ti­schen Desktop-Generatoren in JS, diver­se son­sti­ge Ruby-Engines bis hin zur mini­ma­li­sti­schen hän­di­schen Erstellung via Inlcudes, etwas simp­len PHP und puren Textfiles gewech­selt. Und bin jedes Mal dann doch wie­der bei WordPress gelandet. 

    Der Sicherheitsfaktor mag stim­men, aber schluss­end­lich und im rea­len Alltag haben die sta­ti­schen Generatoren zumin­dest bei mir ein paar Schwachstellen gezeigt… die Renderzeit z.B. nach 500+ Einträgen wird oft ein Problem und ist müh­sam - spe­zi­ell, wenn man immer wie­der ein paar Kleinigkeiten noch­mals ändert. Auch wenn mitt­ler­wei­le nur der Beitrag sel­ber und Archiv-Seiten neu „geren­dert“ wer­den, dau­ert es oft sehr lan­ge und steigt mit Anzahl der Beiträge. 

    Ein ande­res Fazit, das ich ken­nen ler­nen durf­te bei vie­len ande­ren Bloggern und auch mir sel­ber, dass die Anzahl der publi­zier­ten Beiträge nach dem Umstieg auf eine sta­ti­sche Engines nach eini­ger Zeit deut­lich nach­lässt. Warum das so ist oder ob es tat­säch­lich am Umstand der Engine liegt, weiß ich nicht - aber ich blog­ge mit WordPress, so sehr ich es auch nicht mag, deut­lich öfter und mal eben leich­ter ein­fach so (auch von ande­ren Geräten - da ein­fach Login, los­tip­pen, publish und fer­tig.). Die Rumbastelei mit Disqus, PHP-Comments und ande­ren Dingen ist zwar unkom­pli­ziert im Prinzip, aber bis heu­te fin­de ich das WP-Kommentarsystem den­noch noch immer schlicht und ein­fach und rela­tiv sim­pel - auch für den User. Disqus und Co. mit akti­vier­tem Blocker für JS-Zeugs und Co? Nada, kein Login dann mög­lich. Und paar ande­re Kleinigkeiten. 

    Der Workflow ist bei sta­ti­schen Engines zwar auch simp­le - unter Linux XY hat­te ich ein­fach ein paar Skripte sel­ber zusam­men­ge­klopft, die ich ein­fach star­te­te und dann nach dem Titel abge­fragt wur­de, dann nach dem „Content“, optio­nal Bilder und Co. und danach der auto­ma­ti­sche Output mit Upload zum Server. Fühlt sich groß­ar­tig an, einen simp­len, puren HTML-Blog dort lie­gen zu haben. Klein, unan­greif­bar, extrem schnell, ein­fach zu war­ten, zu sichern und nix kann kaputt gehen. Aber in Summe - je nach Engine und Background - ladet man sich dann eben­so wie­der dut­zen­de Bibliotheken, Erweiterungen und Co. run­ter, damit die Engine am Rechner über­haupt werkt. Bei Jekyll und purer OS-Basis ist die Anzahl der Biblios und MB-Größe über dem von WordPress am Server durch die gan­zen Zusätze und bei einem Wechsel vor dem Gerät und Neueinrichtung tra­ten dann auch gleich mal Probleme wie unter­schied­li­che Versionen von RubyBla und ande­ren Dingen auf, kein Problem natür­lich, neu zusätz­lich halt instal­lie­ren oder erset­zen, usw… - aber in Summe hat man genau­so wie­der so ein „Packerl“ an Datenwulst, das man pflegt und hegt.
    Blosxom als Single-File-Engine der ersten Stunde (und ehe­ma­lig eine der ersten Blog-Engines in grau­er Urzeit, 2000er-Ära) ist da viel­leicht die beste Lösung (hat­te ich drei~vier Jahre lang pro­blem­los am lau­fen) - hat­te für mich den Abschlussgrund aller­dings dann vor zwei Jahren, weil mobi­les zugrei­fen via Smartphone, Tablet und Co. zum Bloggen eben­so weg fällt und der Zugriff via SSh auch immer so eine Sache ist und manch­mal hakt.

    Also kei­ne Lanze für WP, aber ich bin noch immer auf der Suche unver­än­dert und nicht fün­dig gewor­den bis heu­te. Am lieb­sten eine Mini-Blog-Engine mit puren Textfiles, einer ein­zel­nen Datei, simp­le, respon­si­ve Möglichkeit auch von woan­ders oder unter­wegs zugrei­fen und blog­gen (oder ändern) zu kön­nen, ein schlich­tes Kommentarsystem mit einer Datei und den Rest bit­te per Hand. Und eine, die aber nicht nach 500 oder 1000 Beiträgen schlapp macht oder 15 Minuten „ren­dern“ muss für ein­mal Wort aus­bes­sern. :x :)

    • Mobiles Bloggen mit Pelican geht eigent­lich recht leicht: MobileOrg und ein post-com­mit-Hook auf dei­nem git-Server.

      Ist halt eine arge Bastelei, bis alles geht.

Comments are closed.

https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_smilenew.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_biggrin2.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_sadnew.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_eek.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_shocked.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_confusednew.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_coolnew.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_lol.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_madnew.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_aufsmaul.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_seb_zunge.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_blushnew.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_frown.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_twistedevil1.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_twistedevil2.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/icon_mad.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_rolleyesnew.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_wink2.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_idea2.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_arrow2.gif 
mehr...
 

Erlaubte Tags:
<strong> <em> <pre> <code> <a href="" title=""> <img src="" title="" alt=""> <blockquote> <q> <b> <i> <del> <span style=""> <strike>

Datenschutzhinweis: Deine IP-Adresse wird nicht gespeichert. Details findest du hier.