Doch warum interessiert mich die Codequalität von funktionierenden Plugins? Ganz einfach, sie funktionieren nicht, oder nicht so wie ich das will. Bestes Beispiel die Tag-Cloud in der Seitenleiste. Ich wollte eine Tag-Cloud die eben nicht nur die Schriftgröße verändert umso häufiger der Tag vorkommt, deshalb fällt die standard WordPress Tagcloud schonmal raus. Zum Ändern der Farbe gibts 2 fertige Plugins, eines davon funktioniert gar nicht (ich denke das liegt irgendwie an WordPress 3, anders kann ich mir die positiven Bewertungen nicht erklären), das andere Produziert invaliden HTML Code und kann auch nur zufällige Farben vergeben (Palette kann man einstellen aber die Farben aus dieser werden zufällig auf die Tags verteilt). Ich wollte aber etwas anderes: Meine Vorstellung war, dass das Tag-Cloud Plugin einfach CSS Klassen vergibt die ich dann in meinem Stylesheet vernünftig beschreiben kann. Somit könnte man eben nicht nur Schriftgröße und Farbe richtig anpassen sondern auch die Schriftart ändern zum Beispiel.

Plugin abändern?

Das dachte ich mir auch, dann nehm ich halt das vorhandene Plugin her und bau das um. Dann hat mich allerdings der Schlag getroffen in welchem katastrophalen Zustand der Code ist. Geschockt wie ich war hab ich mal die anderen Plugins die ich so installiert habe in meinen Texteditor geworfen und bei allen existiert dasselbe Chaos.

Anderes Thema: Themes

Ich dachte, da WordPress so verbreitet ist müsste man eine Menge Themes finden auf die man Aufbauen kann, doch zumindest mit der in WordPress integrierten Suche findet man fast nix. Also hab ich mir ein möglichst minimalistisches Theme genommen und angefangen das umzubauen. Auch hier wieder: Totales Chaos!

Was mir bei der Bastelei weiterhin aufgefallen ist: Das ganze Theme Konzept von WordPress ist totaler Murks. Möchte ich z.B. auf der Frontpage (index.php) meines Blogs einen Blogeintrag komplett ausgeführt haben statt ihn automatisch beim “more”-Tag abschneiden zu lassen, muss ich eine Variable namens $more auf den Wert -1 setzen bevor ich das Kommando the_post() aufrufe. (Dieses the_post() ist nochmal so ne ganz andere Geschichte) Kurzgesagt: Das Template design in WordPress ist totaler Murks. Magische Variablen die irgendwie im globalen Kontext existieren müssen um etwas total unbeteiligtes zu verändern? Das gehört im besten Fall als Parameter in the_post(), aber am besten schafft man dieses Konstrukt gleich mit ab.

Reengineering WordPress: The right way!

Konzept

Wie macht man es also Richtig? Meiner Meinung nach muss alles was nicht integraler Bestandteil des Blogs ist in externe Plugins ausgelagert werden. Also auch Tags, Kategorien und sogar Kommentare. Erstens kann man so schnell Teile austauschen ohne das ganze System updaten zu müssen und zweitens werde ich damit gezwungen vernünftig zu Programmieren.

Am besten sollten alle Plugins sich konventionell prozedural bei den Systemfunktionen einklinken (Hooks registrieren) und dann als reine Klassen und Objekte weiter existieren. Bei der Architektur würde ich das Android Modell bevorzugen. Ein Plugin benötigt “Dienste” und stellt dem System auf der anderen Seite wieder andere Dienste zur verfügung. Beispielsweise würde ein Tags Plugin sich in die Adminseite für die Posts mit einklinken und auf dieser Seite zusätzliche Steuerelemente zur Verfügung stellen, weiterhin klinkt es sich automatisch in den “Postings” Dienst ein und ergänzt zu jedem Posting die vorhandenen Tags. Auf der anderen Seite benötigt das Tags Plugin natürlich Zugriff auf die Datenbank in der es eine eigene Tabelle für die Tags anlegt und die Posts mit den Tags verknüpft.

Das Theme Template wiederum könnte das System fragen ob ein “Tags” Service existiert und die Tags anzeigen sobald es welche erhält. Das Theme wäre also ebenfalls von Systemdiensten abhängig, allerdings auf zweierlei unterschiedliche Weisen: Erstens könnte es einen Dienst Zwingend benötigen oder zweitens ihn optional unterstützen (wenn keine Tags da sind zeig ich halt keine an vs. ich benötige dringend JQuery da sonst die Seite nicht funktioniert). Auf der anderen Seite stellt das Theme Template dem System aber auch Dienste zur Verfügung in Form von Containern (z.B. Posting/Archiv Bereich und eine Navigationsleiste oben und eine Sidebar). Diese Container könnten dann wie im WordPress Admin Interface mit Widgets gefüllt werden die ebenfalls als Plugins angelegt sind.

Ich habe das ganze mal als Mindmap (klick auf das Bild führt zum ganzen Ausmaß) grob zusammengefasst weil ich mir selber darüber klar werden wollte wie viel Aufwand es wäre ein Blog auf dieser Basis zu entwickeln. Ich muss sagen das ganze wirkt recht umfangreich auf mich, doch ich denke ich werde es probieren (auch einfach aus dem Grund weil mein altes Blog aus historisch gewachsenem Code besteht und mittlerweile ein wenig aus der Mode gekommen ist da ich dort rein prozedural Programmiert habe). Ich vermute das Backend an sich wird der meiste Aufwand, doch die Plugins können ja stückweise entstehen.

Das ganze soll nachher OpenSource werden, da ich es auch als Referenz für zukünftige Bewerbungen benutzen möchte und einfach weil ich denke, dass WordPress (sofern es nicht überdacht wird, wobei… das hatte ich bei 3.0 schon erwartet) ausgedient hat und eine flexiblere Alternative her sollte.

Den Fortschritt könnt ihr, sobald etwas Sichtbar wird, auf http://devel.dunkelstern.de/ mitverfolgen, aber erwartet nicht dort etwas funktionierendes zu finden.

Get it while it's hot

Ich veröffentlich das Ding jetzt einfach mal mit einem sehr einfachen Style ohne besonderes Theme oder so. Ein Automatischer Setup Assistent ist schon dabei, eigentlich muss man es nur runterladen und entpacken.

http://projects.dunkelstern.de/blog/dunkelstern_blog-1.0.1.tar.gz

Setup

Systemvorraussetzungen

• Apache Webserver
• URL Rewriting muss eingeschaltet sein
• PHP 5.2+
• Datenbank (SQLite reicht auch).

Momentan unterstützt das Dunkelstern Blog SQLite, MySQL und PostgreSQL über das PHP-PDO Objekt.

Um das Blog zu installieren müssen die Dateien lediglich auf einen Webserver hochgeladen werden (die .htaccess nicht vergessen!) und mit einem Browser das Verzeichnis angesurft werden. Der Setup Assistent sollte sich nun automatisch Öffnen.

Will man das Blog einfach mal kurz antesten, so muss lediglich ein Passwort für den ersten User eingetragen werden und auf "Erstellen" geklickt werden. Danach sollte sich das Blog dann mit dem ersten Eintrag zeigen. In diesem Eintrag ist auch ein Link zum Admin Interface eingebunden, diesen sollte man sich entweder merken oder als Lesezeichen im Browser abspeichern.

Funktionen

• Standardkonformer Atom Feed
• Komplett webbasiertes Admin Interface
• Automatischer Setup Assistent
• Komplett mittels CSS und Template Dateien veränderbares Theme
• XML-RPC Interface welches ermöglicht das Blog mit einem Standalone Blogging client zu verwenden
• WYSIWYG Editor im Webinterface
• Mehrere Autoren Accounts moeglich (siehe Roadmap)
• Erstellen von Blogeintraegen mit Datum in der Zukunft, diese erscheinen ab dem eingestellten Datum im Feed und auf der Webseite
• Erstellen von Entwürfen die nicht Veröffentlicht werden
• Moderierbare Kommentare
• Captcha Einbindung zur Verhinderung von Spam
• Taggen von Beiträgen moeglich
• Suche nach Tags und Autoren für den Benutzer und Leser möglich
• Automatisches Kürzen von Beiträgen für die Frontpage ("Weiterlesen…" Link)
• Baumstruktur des Blog Archivs anzeigbar
• Kommentare, Reaktionen und Trackbacks via Disqus

XML-RPC Zugriff

Es wurden verschiedene Blogging clients getestet (am besten funktioniert immer noch der Windows Live Writer, aber auch Marsedit und Blogo auf dem Mac wurden ausgiebig getestet.)

Einstellungen für den Blogging Client:

Anpassen

Das Aussehen des Blogs kann total an die Seite in die es Integriert werden soll angepasst werden. Die nötigen Dateien dazu findet man in ./templates/

Beim parsen der Templates werden alle Tokens die mit %-Zeichen umschlossen sind durch entsprechende Werte ersetzt. Umschliesst man ein Wort mit zwei Hash-Zeichen (#) so sucht die Engine nach einer Datei mit diesem Namen im Template Ordner und bindet diese anstatt dem Token ein. Wenn die Datei eine PHP Datei ist so wird sie ganz normal ausgeführt.

Möchte man die Templates Sprachabhängig gestalten so sind die entsprechenden Dateien aus dem Template Ordner in den entsprechende Unterorder der jeweiligen Sprache zu verschieben.

Die Anpassung des Captcha Mechanismus ist sehr einfach über die Datei captcha.php möglich.

Was noch fehlt…

• Benutzerverwaltung im Webinterface
• Einfache Statistik
• Google LaTeX API einbinden
• Trackback Links und Pingback Interface
• Trackbacks Senden
• Spamfilter ohne Captcha (akismet o.ae.)
• Twitter Authentifizierung
• Twitter Kommentare einbinden

Kontakt

Für Bugreports und Anregungen schreibt mir einfach eine E-Mail oder Kontaktiert mich auf Jabber oder Skype.

Twitter: @dunkelstern

E-Mail: jschriewer@gmail.com

Jabber: dunkelstern@jabber.org

Skype:  dunkelstern738

http://blog.dunkelstern.de