Tag: Wordpress

Posted on

Die eigene Homepage: CMS, Blogkompilierer und statisches XHTML

Ich stand vor der Entscheidung wie ich die Homepage für mein neues Spieleserverprojekt gestalten sollte. Ich schwankte anfangs zwischen einem dynamischen Portal für freie Spiele und selbst geschriebenen statischen HTML-Seiten. Ich habe mich schließlich gegen PHP und Datenbanken entschieden und auf statische Inhalte gesetzt, die zum einen durch Chronicle, einen Blogkompilierer, und zum anderen durch manuell erstelltes XHTML erzeugt werden. Die restlichen Statistiken und Graphen für die einzelnen Spiele werden täglich durch das Auswerten von Logdateien und mit Hilfe von Munin dargestellt.

Die Frage bei so einem Projekt ist: Wie viel Interaktion möchte man eigentlich haben?
Linuxiuvat.de ist keine Clan- oder Gildenseite, sondern lediglich das Erscheinungsbild des virtuellen Servers, auf dem einige freie Spiele laufen. Ich übernehme hier die klassischen Aufgaben als Serveradmin und Macher der Homepage, kann aber natürlich nicht alle Mitglieder eines Clans ersetzen.
Meiner Meinung nach sind Foren oder sogar ein Wiki nur dann sinnvoll, wenn man gleichzeitig eine Community rund um die Spiele aufbauen will, die das Projekt mit Leben füllt. In meinem Fall gibt es nur mich und die Idee irgendwann das Ganze abzuschließen und zum Fazit zu kommen, dass die Möglichkeiten des vServers ausgeschöpft sind. Danach möchte ich nur noch das Bestehende weiterpflegen, selbst eine Runde spielen und zum nächsten Projekt weiterziehen.
Vor diesem Hintergrund und der Tatsache, dass der Spieleserver auch ein praktisches Beispiel ist (es macht vor allem Spaß), wie man mit Freier Software, wenig Ressourcen und auch kostengünstig ein Projekt gestalten kann, wollte ich die Interaktion auf das Notwendige und Sinnvolle beschränken.

Hilfreiche Software

Es gibt sehr viele Möglichkeiten die eigene Homepage zu gestalten. Einige Ideen finden sich z.B. bei Debian und Ubuntu mit

aptitude search '~sweb'


In der Sektion "Web" stecken zahlreiche Content-Management-Systeme, Blogsoftware und Hilfsmittel statische Inhalte zu erschaffen. Eigenes Vorwissen, die verwendete Programmiersprache, Performance und verfügbare Angebote des Webhosters spielen natürlich eine Rolle. Bei einem eigenen VPS kann man aus dem Vollen schöpfen, da es keine technischen Beschränkungen gibt.

Bekannte Content-Management-Systeme

Es gibt hervorragende freie CMS darunter die großen Joomla, Drupal, Typo3, Movable Type und WordPress. Allen ist gemein, dass sie hochentwickelt, stark erweiterbar und vielfältig einsetzbar sind. Vom kleinen Linuxblog bis zur Unternehmenskette mit eigenem Franchise ist alles denkbar. Inhalte und Seitengestaltung sind unabhängig voneinander. Wissen über HTML oder Skriptsprachen ist nützlich jedoch nicht zwingend notwendig. Jeder kann Dank des umfangreichen Backends Inhalte einstellen und verwalten.

  • Anforderungen: PHP, MySQL/PostgreSQL
  • Vorteile: Dynamische Inhalte, Interaktion mit Benutzern ist einfach, unzählige vorgefertigte Plugins und Themen, große Gemeinschaft, gute Dokumentation, sehr flexibel
  • Nachteile: Speicherintensiv, Datenbank und PHP wird benötigt, potentielle Sicherheitslücken, komplexe Bedienung, Einarbeitungszeit notwendig

Eher unbekannte Content-Management-Systeme

Dann gibt es die eher unbekannten CMS, die meist weniger Feature als die großen haben, aber nicht weniger geeignet sind, um kleinere dynamische Projekte zu verwirklichen. Mir fielen insbesondere Zine, PyLucid und TDiary auf, da ich ein wenig mit Zine wegen der Programmierung in Python geliebäugelt habe. PyLucid ist ebenfalls in Python geschrieben und benutzt Django, während TDiary in Ruby verfasst wurde. Hier sind Japanisch- und Englischkenntnisse von Vorteil. Eine weitere interessante Alternative ist WebGUI in Kombination mit Perl und MySQL und DotClear. Leider forderten alle mindestens noch die Installation einer zusätzlichen Datenbank.

  • Anforderungen: Python, Ruby, Perl, MySQL/PostgreSQL
  • Vorteile: Dynamische Inhalte, einfache Interaktion mit Benutzern, einige zusätzliche Plugins und Themen, flexibel, interessante Programmiersprachen
  • Nachteile: Relativ speicherintensiv, Datenbank, Python oder Ruby notwendig, potentielle Sicherheitslücken, weniger umfangreich als die großen CMS

Die Welt der statischen Webseitengeneratoren

Ein Trend unter Techies sind sicherlich Webseitengeneratoren wie Jekyll für Ruby und Hyde für Python, die mit Hilfe von Templates aus Text, Markdown oder HTML die komplette Seitenstruktur einer Webseite unabhängig vom Inhalt erstellen können.
Etwas einfacher aufgebaut, aber nicht weniger effektiv, sind z.B PubTal (Python), WebGen (Ruby) und Blazeblogger.
Mein Favorit, für den ich mich schließlich entschieden habe, war Chronicle, den ich im nächsten Beitrag etwas ausführlicher vorstelle.

Was ist so toll an statischen Blogkompilierern und Webseitengeneratoren?

Ich habe mich für diesen Typ entschieden, weil ich sie für sicher, leichtgewichtig und effizient halte. Natürlich kann man auch Plugins für ein CMS benutzen, die den dynamischen Inhalt in statischen überführen (Stichwort: WP-Super-Cache). Ein Blogkompilierer wie Chronicle macht das von Haus aus. Statische Inhalte werden extrem effizient durch den Webserver ausgeliefert, so dass selbst bei einem mickrigen vServer die Performance selbst unter mittelgroßer Last nicht leiden wird.
Ein normales Projekt benötigt nicht einmal ansatzweise alle Funktionen eines CMS. Hier geht es auch darum realistisch zu bleiben. Weniger ist oft mehr. Außerdem sind diese Generatoren einfach zu bedienen und benötigen weder Datenbank noch eine Skriptsprache um zu funktionieren, was im Regelfall gleichbedeutend ist mit mehr Leistung und geringeren Kosten.
Einen Haken hat die Sache. Interaktion ist ohne zusätzliche Software nicht möglich, woraus ein neues Problem erwächst.

Disqus und Co. sind böse

Wirklich, ist das so? Fakt ist, wenn man auf ausschließlich statische Inhalte setzt, muss man dennoch irgendeine serverseitige Anwendung/Skript installieren, damit Kommentare von Besuchern irgendwie in die Webseite eingebunden werden können. Viele verfallen dann auf externe Dienstleister wie Disqus oder IntenseDebate.
Als Webseitenbetreiber muss man lediglich ein Stück Javascript-Code einbinden und schon werden Kommentare an die Server von Disqus und Co. weitergeleitet und dann auf der eigenen Webseite dargestellt. Disqus macht es wirklich einfach. Keine Spam-Probleme, keine Last auf dem Server, perfekte Integration mit Sozialen Netzwerken. Als Alternative könnten Besucher z.B. eine E-Mail schicken und man bindet dann den Inhalt manuell in die Seite ein, aber hey, wer macht das schon. 😉
Ich bin nicht wirklich der Typ, der hinter jedem erfolgreichen Internetunternehmen den nächsten faschistischen Weltbeherrscher vermutet. Man sollte sich aber schon die Frage stellen, ob man für jede Webseite die Kontrolle über seine Daten an eine externe Stelle abgegeben muss oder nicht. Diese Bedenken hat Jeremy Scheff auf den Punkt gebracht.
Ich persönlich denke, dass man Interaktion und Kontrolle über die Daten auch anders haben kann und das auch nutzen sollte. Im Falle von Chronicle war das z.B. das einfache Einbinden einer einzigen CGI-Datei. Andererseits vielleicht sollten wir einfach an einem wirklich quelloffenen und freien Disqus arbeiten!

Fazit

Die Wahl der Software hängt entscheidend von den eigenen Ansprüchen ab. Wem Geschwindigkeit und Sicherheit wichtig ist, sollte statische Inhalte veröffentlichen, die bevorzugt mit einem Blogkompilierer oder Webseitengenerator erzeugt werden oder auf die händische Methode zurückgreifen. Für mein kleines Projekt werde ich diesen Weg auf jeden Fall weitergehen.

Posted on

WordPress-Plugin Subscribe 2 gelöscht

Ich musste mich leider von der E-Mail Benachrichtigung für mein Blog, Subscribe 2, trennen. Nach dem letzten Update hatte ich erneut den Code geändert, damit der komplette Artikel als Textmail verschickt werden konnte, jedoch gab es wohl mehrere weitere Änderungen, so dass die Formatierung dadurch auch verloren ging.
Des weiteren gibt es keine eingebaute Warteschlangenfunktion für E-Mails, so dass sich die Veröffentlichung neuer Artikel durch das Versenden der E-Mails deutlich verzögert.
Kurzum das Plugin entspricht im Moment nicht meinen Vorstellungen und ich möchte keine weitere Zeit mehr in die Wartung investieren, weswegen es besser ist, wenn es direkt aus WordPress verschwindet, bevor es in einem unfertigen Zustand verbleibt.
Alle eingetragenen E-Mail-Adressen wurden gelöscht. Als Alternative zu Subscribe 2 bleibt natürlich weiterhin der Feed erhalten. Sorry, wegen der Unannehmlichkeiten.

Posted on

WordPress-Plugin Subscribe2 in Deutsch mit ganzem Artikel in Reintext auch für öffentliche Abonnenten

Ich hatte vor kurzem erwähnt, dass ich das WordPress-Plugin Subscribe2 verwende. Später fiel mir auf, dass einige Optionen gut versteckt oder von Haus aus nicht so vorgesehen sind, wie ich mir das für mein Blog vorgestellt habe.
Zuerst einmal musste ich etwas nach der deutschen Übersetzung suchen. Dazu gibt es diese englische Anleitung. Vorausgesetzt das eigene Blog wurde schon auf Deutsch eingestellt, genügt es die .mo Datei subscribe2-de_DE.mo der aktuellen Version herunterzuladen und in das Subscribe2-Plugin-Verzeichnis zu kopieren.
Mein zweites Problem war eine Einstellung von Subscibe2, die es nur erlaubt Auszüge der Blogposts an öffentliche Abonnenten zu verschicken. Da ich aber nicht wollte, dass man sich extra für das gesamte WordPress-Blog registrieren muss, habe ich mich etwas umgeschaut.
Um vollständige Textbeiträge zu erhalten, muss der PHP-Code von Hand angepasst werden. Leider findet sich auf der Pluginseite selbst kein Hinweis auf die Stelle im Code, aber jemand hatte wohl die gleiche Idee und hat den entsprechenden Patch auf pastebin.com hochgeladen.
Ich habe das für die aktuelle Version 7.1 gerade noch einmal mit diff im unified Modus nachgestellt.

diff -u subscribe2_alt.php subscribe2.php > patch

--- subscribe2_alt.php  2012-01-20 23:41:41.438566663 +0100
+++ subscribe2.php      2012-01-20 23:41:39.286566663 +0100
@@ -723,7 +723,7 @@
                        } else {
                                $recipients = array_merge((array)$public, (array)$registered);
                        }
-                       $this->mail($recipients, $subject, $excerpt_body);
+                       $this->mail($recipients, $subject, $full_body);
                        // next we send plaintext full content emails
                        $this->mail($this->get_registered("cats=$post_cats_string&format=post&author=$post->post_author"), $subject, $full_body);

Dieses diff lässt sich mit patch leicht wieder einspielen, wonach standardmäßig nur noch ganze Artikel und keine Auszüge mehr verschickt werden.
patch subscribe2_alt.php patch
Wie man aber auch schnell erkennen kann, das Ersetzen der Variable $excerpt_body mit $full_body ist in diesem Fall schon der ganze Trick. Hoffe das spart einigen Benutzern von Subscribe 2 etwas Zeit. 🙂

Posted on

Jetpack ade: Neue Plugins für Kommentar- und E-Mail-Benachrichtigung

Normalerweise schreibe ich nicht besonders viel zu WordPress, doch in diesem Fall haben ein paar Veränderungen im Hintergrund leider auch Auswirkungen auf diejenigen gehabt, die dieses Blog per E-Mail abonnieren oder über nachfolgende Kommentare informiert werden möchten.
Ich habe mich entschieden das WordPress Plugin Jetpack zu deinstallieren. Es hat mir in den letzten Monaten einige nützliche Funktionen geliefert, leider aber auch viele, die ich gar nicht gebrauchen konnte und die deswegen ungenutzt auf dem Server in Vergessenheit gerieten.
Der entscheidende Grund, warum ich Jetpack schließlich entfernt habe, war aber die Notwendigkeit mich mit wordpress.org verbinden zu müssen, um manche Funktionen überhaupt sinnvoll nutzen zu können.

Da mein Ziel aber immer war ein technisch unabhängiges Blog zu haben und für Dienste keine Drittanbieter in Anspruch nehmen zu müssen, war Jetpack in dieser Beziehung einfach eine inkonsequente Entscheidung gewesen. Im gleichen Atemzug will ich aber auch sagen, dass ich nicht denke, dass Automattic hier etwas schlechtes tun würde, sondern nur, dass ich mit den neuen Plugins flexibler bin.
Da wäre nun zum einen Subscribe-to-double-opt-in-comments, womit man die simple Möglichkeit hat über nachfolgende Kommentare per E-Mail informiert zu werden. Der Benutzer erhält zusätzlich noch eine Bestätigungsmail und kann sich auch jederzeit wieder über ein eigenes Profil abmelden.

Zum anderen hatte ich unter dem Kommentarfeld auch immer eine Möglichkeit angeboten alle Beiträge dieses Blogs per E-Mail zu abonnieren. Hierzu musste man aber auch umständlich zur Freischaltung auf der wordpress.org Seite navigieren.
Mit Subscribe2 habe ich nun ein Plugin, mit dem sich das E-Mail Abonnement beliebig gestalten lässt. Selbstverständlich kann man sich jederzeit davon auch wieder abmelden und wie bei meinem neuen Kommentarplugin erhält man vorher eine Bestätigungsanfrage. Auch wenn sicherlich viele heutzutage auf Feeds zurückgreifen, mag ich persönlich die E-Mail Funktion immer noch ziemlich gern, da ich mit einem E-Mail Programm bequem diese Nachrichten sortieren und auch zum späteren Lesen ablegen kann.

Das Subscribe2-Widget befindet sich bei mir nun in der rechten Seitennavigation und über einen Link in der E-Mail kommt man zu einer Seite in diesem Blog, wo man sich auch wieder abmelden kann.
Wie immer ist das alles natürlich nur ein Angebot, aber ich denke, ich habe dadurch ein wenig mehr Flexibilität gewonnen und für den Interessierten ist es deutlich einfacher geworden die Dienste zu nutzen.
Leider konnte ich die alten E-Mail-Adressen bis auf die E-Mail-Abonnenten nicht retten, so dass alle Kommentarverfolger die neue Funktion erneut benutzen müssten oder ab jetzt keine Benachrichtigung mehr erhalten. Ich bitte um Entschuldigung.
Sollten Probleme mit den neuen Plugins auftreten, lasst es mich bitte wissen.