Nerdkrams
Ins Inter­net schrei­ben mit Pelican

(Vor­be­mer­kung: Dies ist eine leicht über­ar­bei­te­te Vari­an­te eines Bei­trags, den ich schon anders­wo ver­öf­fent­licht hatte.)

Mir ist schon seit einer Wei­le auf­grund von Per­for­mance- und Sicher­heits­pro­ble­men danach, Wor­d­Press, das ich seit inzwi­schen neun Jah­ren nut­ze, auf die­sem klei­nen Text­ver­öf­fent­li­chungs­dings ein­mal durch etwas Ande­res aus­zu­tau­schen. Nicht aber gegen ein ande­res „rich­ti­ges“ Blog­sy­stem 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 Kom­men­tar­sy­stem hat und ich sicher­lich nicht anfan­gen wer­de, inter­es­sier­ten Kom­men­ta­to­ren Java­Script auf­zu­zwin­gen). Inter­es­san­ter sind da schon Sei­ten­ge­ne­ra­to­ren wie Jekyll und des­sen Frame­works (etwa Octo­press), die zwar auch meist kei­ne Kom­men­tar­funk­ti­on, dafür aber vie­le wei­te­re Vor­tei­le mit­brin­gen, zum Bei­spiel, dass man sein Blog mit git ver­sio­nie­ren kann und nicht auf einen PHP/­MyS­QL-Stack ange­wie­sen ist, weil die Web­site direkt als HTML aus­ge­ge­ben wird und nicht bei jedem Auf­ruf neu erzeugt wer­den muss. Franz hat die Vor­tei­le eines sol­chen Blog­gene­ra­tors ein­mal aufgezählt.

Nun ist Jekyll längst nicht das ein­zi­ge Werk­zeug die­ser Art, die Aus­wahl ist rie­sig; gera­de, wenn man in der Spra­che Ruby nicht hei­misch ist, ist das Erzeu­gen eines neu­en Blog­ein­trags in (zum Bei­spiel) Octo­press auch eine unnö­tig kom­pli­zier­te Sache. Außer­dem scheint es unmög­lich zu sein, ein Octo­press-The­me zu ent­wickeln, das nicht aus­sieht wie aus­ge­kotzt. Oder hat es nur noch nie­mand versucht?

War­um nicht Pelican?

Unter den Alter­na­ti­ven beson­ders inter­es­sant fin­de ich Peli­can, das anders­wo als ein­fach beschrie­ben wird und jüngst in Ver­si­on 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 Web­ser­ver, der Rest ver­läuft nach der Anlei­tung. Wird die fal­sche Python-Ver­si­on – 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 Auf­ruf von peli­can-quick­start nur zwei Syn­tax­feh­ler zur Fol­ge hat. Vor der Instal­la­ti­on soll­te mit python ‑V also drin­gend über­prüft wer­den, ob Python 2.7 die akti­ve Ver­si­on ist.

Quick­start!

peli­can-quick­start funk­tio­niert danach jeden­falls wie gewünscht: Ein­tip­pen, ein paar Fra­gen beant­wor­ten und es kann los­ge­hen. Dies rich­tet im Wesent­li­chen die Datei pelicanconf.py ein, die sozu­sa­gen das Orga­ni­sa­to­ri­sche über­nimmt: Blog­ti­tel, Per­ma­link­struk­tur und ähn­li­che Optio­nen wer­den dort fest­ge­legt. Bei der Gele­gen­heit soll­te dort gleich der OUTPUT_PATH so ange­passt wer­den, dass die erzeug­ten HTML-Datei­en im rich­ti­gen Ord­ner landen.

Zeit für den ersten Testartikel.

peli­can benutzt stan­dard­mä­ßig den Ord­ner ./content/ für Ent­wür­fe. Wenn per pip oder easy_install eine lauf­fä­hi­ge Ver­si­on von Mark­down instal­liert ist, ver­steht es auch Mark­down, eine Aus­zeich­nungs­spra­che, die von Dia­spo­ra, Ghost, Stack Over­flow, Git­Hub und wei­te­ren Platt­for­men bereits benutzt wird und die zu ler­nen ich also sowie­so empfehle.

Peli­can ver­wen­det wie wohl alle sta­ti­schen Gene­ra­to­ren Rein­text­da­tei­en statt einer kom­ple­xen Daten­bank. Es lässt sich also schlicht Fol­gen­des tun:

emacs content/new-blog-post.md

Der Datei­na­me ist weit­ge­hend egal, ihr könnt die Bei­trä­ge also auch durch­num­me­rie­ren oder das Datum in den Datei­na­men schreiben.

Ein funk­tio­nie­ren­des Bei­spiel für so einen Blog­ar­ti­kel mit Kate­go­rien, Tags und modi­fi­zier­tem Per­ma­link (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 Blog­ar­ti­kels immer den Meta­da­ten, ihr könnt also ziem­lich leicht den Namen des Autors oder das Ver­öf­fent­li­chungs­da­tum ä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ög­lich­kei­ten. Es ist natür­lich auch mög­lich, das Datum aus dem Datei­sy­stem zu übernehmen.

Release, release.

Wenn euch der Bei­spiel­bei­trag so gefällt, könnt ihr ihn veröffentlichen:

cd ~
pelican

Ta-dah:

Pelican

Plugins

So fle­xi­bel das Peli­can-System wegen der Kom­pi­lie­rung auch erschei­nen mag, natür­lich gibt es immer etwas, was für den eige­nen Ein­satz fehlt. Wor­d­Press wird ja auch für sei­ne Erwei­ter­bar­keit von vie­len Nut­zern geschätzt. Aber wer sagt, dass „sta­tisch“ immer „unfle­xi­bel“ bedeu­ten muss?

Tat­säch­lich gibt es auch für Peli­can eine Viel­zahl an Plugins, die den erzeug­ten HTML-Sei­ten etwas Wür­ze ver­lei­hen. Anzei­ge des Gra­va­tars für Arti­kel­au­toren? Funk­tio­niert. You­Tube? Etwas umständ­lich, aber kein Pro­blem. Eine Sitemap für die SEO-Ver­rück­ten? War­um nicht?

Alle Funk­tio­nen sind da, aber es könn­te noch etwas hüb­scher aus­se­hen? Auch Peli­can kennt The­mes, eine Viel­zahl von ihnen ist auf Git­Hub zu fin­den. Es genügt, ein The­me in den Ord­ner /themes zu kopie­ren und in der Datei pelicanconf.py ein­zu­tra­gen – beim näch­sten Gene­rie­ren wird es auto­ma­tisch verwendet.

Kom­men­ta­re

Da die mit Peli­can erzeug­te Web­site nicht erst beim Auf­ruf erzeugt wird, sind Kom­men­ta­re, die in einer Daten­bank lie­gen, hier nicht ohne Wei­te­res mög­lich. Die offen­sicht­li­che Lösung, sta­ti­sche Kom­men­ta­re im Stil klas­si­scher Leser­brie­fe per E‑Mail zu ermög­li­chen, ist auf Web­sites mit einer hohen Fre­quenz an Benut­zer­inter­ak­ti­on mit­un­ter zu auf­wän­dig. Wer damit leben kann, dass Kom­men­ta­re Java­Script vor­aus­set­zen, der kann zu eta­blier­ten Fremd­an­bie­tern wie Dis­qus, das in vie­le Peli­can-The­mes bereits inte­griert ist, oder Inten­se­De­ba­te grei­fen oder ein selbst­ge­ho­ste­tes Kom­men­tar­sy­stem wie etwa HashO­ver oder Isso ein­bin­den. Dafür muss nur im The­me eine ent­spre­chen­de Anpas­sung erfol­gen, bei der Gele­gen­heit las­sen sich die Kom­men­ta­re auch gleich per CSS optisch anpassen.

Fazit

Alles in Allem: Peli­can ist mehr als nur ein net­tes Spiel­zeug. Es gibt einen Wor­d­Press-Import und Plugins für aller­lei Ein­satz­zwecke. Ich emp­feh­le Peli­can mal im Auge zu behal­ten. Es muss ja nicht immer ein auf­ge­bläh­tes CMS sein.

Senfecke:

    • Sofern Wor­d­Press nicht bis dahin wie­der benutz­bar wird, es einen daten­schutz­kon­for­men Kom­men­tar­be­reich mit Spam­fil­ter für Peli­can gibt und ich mal die Muße habe, das The­me die­ses Nicht­blogs auf Peli­can zu por­tie­ren: ja. Ich rech­ne aller­dings nicht mehr mit die­sem Jahr. Erst mal die Abschluss­ar­beit fer­tig schrei­ben. Und die Musik­rück­schau 2014/2 steht ja auch noch an.

  1. Ich hat­te die­ses Gedan­ken x‑fach her­um­ge­wälzt und bin im Lau­fe der letz­ten zehn Jah­re+ an Blog­gen sogar mehr­fach zwi­schen Wor­d­Press, Wiki-Engi­nes zum Blog­gen, Blo­sxom Py & Php, Jekyll, Octo­press, Peli­can, diver­sen sta­ti­schen Desk­top-Gene­ra­to­ren in JS, diver­se son­sti­ge Ruby-Engi­nes bis hin zur mini­ma­li­sti­schen hän­di­schen Erstel­lung via Inlcu­des, etwas simp­len PHP und puren Text­files gewech­selt. Und bin jedes Mal dann doch wie­der bei Wor­d­Press gelandet. 

    Der Sicher­heits­fak­tor mag stim­men, aber schluss­end­lich und im rea­len All­tag haben die sta­ti­schen Gene­ra­to­ren zumin­dest bei mir ein paar Schwach­stel­len gezeigt… die Ren­der­zeit z.B. nach 500+ Ein­trä­gen wird oft ein Pro­blem und ist müh­sam – spe­zi­ell, wenn man immer wie­der ein paar Klei­nig­kei­ten noch­mals ändert. Auch wenn mitt­ler­wei­le nur der Bei­trag sel­ber und Archiv-Sei­ten 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 Blog­gern und auch mir sel­ber, dass die Anzahl der publi­zier­ten Bei­trä­ge nach dem Umstieg auf eine sta­ti­sche Engi­nes nach eini­ger Zeit deut­lich nach­lässt. War­um das so ist oder ob es tat­säch­lich am Umstand der Engi­ne liegt, weiß ich nicht – aber ich blog­ge mit Wor­d­Press, 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 Log­in, los­tip­pen, publish und fer­tig.). Die Rum­ba­ste­lei mit Dis­qus, PHP-Com­ments und ande­ren Din­gen ist zwar unkom­pli­ziert im Prin­zip, aber bis heu­te fin­de ich das WP-Kom­men­tar­sy­stem den­noch noch immer schlicht und ein­fach und rela­tiv sim­pel – auch für den User. Dis­qus und Co. mit akti­vier­tem Blocker für JS-Zeugs und Co? Nada, kein Log­in dann mög­lich. Und paar ande­re Kleinigkeiten. 

    Der Work­flow ist bei sta­ti­schen Engi­nes zwar auch simp­le – unter Linux XY hat­te ich ein­fach ein paar Skrip­te 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 „Con­tent“, optio­nal Bil­der und Co. und danach der auto­ma­ti­sche Out­put mit Upload zum Ser­ver. 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 Sum­me – je nach Engi­ne und Back­ground – ladet man sich dann eben­so wie­der dut­zen­de Biblio­the­ken, Erwei­te­run­gen und Co. run­ter, damit die Engi­ne am Rech­ner über­haupt werkt. Bei Jekyll und purer OS-Basis ist die Anzahl der Bibli­os und MB-Grö­ße über dem von Wor­d­Press am Ser­ver durch die gan­zen Zusät­ze und bei einem Wech­sel vor dem Gerät und Neu­ein­rich­tung tra­ten dann auch gleich mal Pro­ble­me wie unter­schied­li­che Ver­sio­nen von Ruby­B­la und ande­ren Din­gen auf, kein Pro­blem natür­lich, neu zusätz­lich halt instal­lie­ren oder erset­zen, usw… – aber in Sum­me hat man genau­so wie­der so ein „Packerl“ an Daten­wulst, das man pflegt und hegt.
    Blo­sxom als Sin­gle-File-Engi­ne der ersten Stun­de (und ehe­ma­lig eine der ersten Blog-Engi­nes in grau­er Urzeit, 2000er-Ära) ist da viel­leicht die beste Lösung (hat­te ich drei~vier Jah­re lang pro­blem­los am lau­fen) – hat­te für mich den Abschluss­grund aller­dings dann vor zwei Jah­ren, weil mobi­les zugrei­fen via Smart­pho­ne, Tablet und Co. zum Blog­gen eben­so weg fällt und der Zugriff via SSh auch immer so eine Sache ist und manch­mal hakt.

    Also kei­ne Lan­ze 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-Engi­ne mit puren Text­files, einer ein­zel­nen Datei, simp­le, respon­si­ve Mög­lich­keit auch von woan­ders oder unter­wegs zugrei­fen und blog­gen (oder ändern) zu kön­nen, ein schlich­tes Kom­men­tar­sy­stem mit einer Datei und den Rest bit­te per Hand. Und eine, die aber nicht nach 500 oder 1000 Bei­trä­gen schlapp macht oder 15 Minu­ten „ren­dern“ muss für ein­mal Wort aus­bes­sern. :x :)

    • Mobi­les Blog­gen mit Peli­can geht eigent­lich recht leicht: Mobi­le­Org und ein post-com­mit-Hook auf dei­nem git-Server.

      Ist halt eine arge Baste­lei, 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.