WordPress im Ongoing

Über WordPress selbst muss man eigentlich nicht mehr viel sagen. Oder darüber wie man es installiert, konfiguriert und mit Leben füllt. Hierfür gibt es im Internet unzählige Anleitungen und Hilfestellungen. Die braucht es auch, weil so einfach, wie man immer behauptet, ist es eigentlich gar nicht. Zumindest nicht für Neulinge, die zum ersten Mal und völlig unvorbelastet mit webbasierten Anwendungen in Berührung kommen. Einfach ist nur, wenn man sich mit der Informatik etwas auskennt. Einfach ist es nur, wenn man so etwas ähnliches schon mal gemacht hat. Einfach ist es nur, wenn man die Installation und Konfiguration geschafft hat. Danach kann man loslegen und hemmungslos publizieren. Publizieren ist immer gut, denn es macht das Internet reicher. Wenn man dann so eine Weile rumpubliziert hat und sich auch innerlich der Blogosphäre etwas zugehörig fühlt, dann geht es erst richtig los! Das eigene Blog, es wird Schritt für Schritt funktional erweitert und optisch verbessert. Zeitgleich macht WordPress im operativen Betrieb aber auch immer wieder Zicken.

Zicken machen Arbeit. Und Arbeit ist immer schlecht. Vor allem, wenn die Arbeit darin besteht, den Betriebszustand wieder herzustellen. Betreiben ist eine völlig andere Kiste als Erschaffen. Etwas erschaffen, das ist toll. Die Inspiration durchflutet den Kreativen und mit viel Mühe und Leidenschaft entsteht etwas Neues, etwas ganz eigenes, etwas, was die Welt zuvor noch nicht hatte. Das macht viel Spaß. Ganz wunderbar! Dagegen mutet das Betreiben richtig langweilig an. Schließlich geht es nur darum, den stabilen und fehlerfreien Betrieb zu gewährleisten. Das Ding soll funktionieren. Und zwar immer gleich und nicht mal so und dann so. Und keine Fehler auswerfen oder andere Zicken machen. Klingt simpel, ist es aber nicht. Ein stabiler Betrieb, das muss man erst mal hinbekommen. Tatsächlich sind wir immer wieder mit dem Gegenteil konfrontiert. Von heute auf morgen funktioniert irgendwas nicht mehr. Plugins geben ihren Geist auf, das Layout ist plötzlich kaputt oder die ganze Seite ist nicht mehr erreichbar. Total unverständlich, schließlich „hab ich doch nichts gemacht“.

Dann muss man alles stehen und liegen lassen und sich darum kümmern. Obwohl wir eigentlich etwas ganz anderes geplant hatten. Und wie kommen wir nun überhaupt in den Betrieb zurück? Denn wir haben ja „nichts gemacht“ und können deswegen auch keine Einstellung zurückdrehen. Wie hat sich WordPress überhaupt selbst aus dem Betrieb gebracht? Tatsächlich werden fast alle Ursachen im Schaffensprozess gelegt. Beim Erschaffen geht es einzig und allein um die Qualität dessen. Muss geil aussehen, muss crazy Funktionen haben, muss rocken! Ob das Ding später mit wenig Aufwand überhaupt zu betreiben ist, daran verschwendet man keinen Gedanken. So macht man das übrigens auch in der professionellen Informatik. Deswegen können sich Berater und Administratoren in der Regel auch nicht leiden. Der Berater legt das Hauptaugenmerk bei der Konzeption auf die Anforderungen des Kunden. Der Kunde hat meistens ganz schön abgefahrene Vorstellungen. Und was am Ende dabei rauskommt, diese Suppe muss dann der Administrator im Betrieb auslöffeln (also jemand anderes). Beim eigenen WordPress bleiben wir leider selbst in der Verantwortung. Und deswegen sollte man bei der Konzeption einer WordPress Instanz und dessen fortlaufender Optimierung immer den späteren Betrieb im Hinterkopf haben.

Plugins

Bei den Plugins geht das ganze schon los. Plugins gehören zu den beliebtesten Funktionen von WordPress. Mit Hilfe von Plugins kann man sich genau das WordPress bauen, das man braucht. Und Plugins gibt es unendlich viele. Mittlerweile über 33.000 Stück im offiziellen WordPress Plugin Directory (eins von diesen 33.000 ist übrigens von mir). Zustände wie im Paradies. Jetzt ist nur blöd, dass sehr viele Plugins nicht den gängigen Qualitätsstandards entsprechen (meins auch nicht). Die Qualität bezieht sich hierbei nicht auf die Funktionalität, sondern auf die Bereiche Quellcode, Sicherheit und Stabilität. Noch doofer ist, den Qualitätsgrad können wir von außen weder erkennen noch beurteilen.

Wie geht man nun an diesen Sachverhalt heran? Eigentlich ist das gar nicht so dramatisch. Prinzipiell sollte man ausschließlich Plugins verwenden, die sich aktiv in Entwicklung und Support befinden. Denn jedes Programm muss gepflegt und gewartet werden. Wird ein Programm nicht mehr gepflegt, dann geht es irgendwann kaputt (genauso wie die Liebe). Ob ein Programm noch gewartet wird, kann man am Datum des letzten Updates erkennen. Liegt das Datum schon mehr als ein Jahr zurück, sollte man den Einsatz noch mal überdenken. Noch besser ist es, wenn man auf beliebte Plugins setzt. Eine hohe Verbreitung bringt implizit mehrere Vorteile mit sich.

Je verbreiteter ein Plugin, desto geringer ist die Wahrscheinlichkeit, dass schlechter oder instabiler Code ausgeliefert wird. Je verbreiteter ein Plugin, desto schneller sind Korrekturen im Ernstfall verfügbar. Je verbreiteter ein Plugin, umso höher ist die Chance, dass andere Betreiber den Fehler schon gefunden haben, bevor man selbst in das Fehlerszenario hinein läuft. Das beliebte Jetpack ist ein schönes Beispiel. Es kam schon ab und an mal vor, dass ein Jetpack-Release mit kritischen Fehlern im Rahmen eines Update ausgeliefert wurde. Das ist natürlich nicht so schön. Schön ist aber, die Korrektur für das Update gab es dann meistens gleich am nächsten Tag. In dieser Zeitspanne haben viele WordPress Betreiber noch gar nicht gemerkt, dass hier überhaupt ein Fehler war.

Themes

Natürlich sind Daten, Präsentation und Logik in WordPress sauber getrennt. WordPress selbst stellt die Funktionalität bereit (Logik). Das Theme bedient sich dieser Funktionalität und kombiniert die Inhalte (Daten) mit dem Design (Präsentation). Nun ist es so, dass ein Theme in der Regel nicht die gesamte WordPress-Funktionalität abdeckt, sondern nur eine Teilmenge beinhaltet. Umgekehrt kommen viele Themes mit zusätzlicher Funktionalität daher, welche WordPress selbst gar nicht eingebaut hat. Im Idealfall erfüllt ein Theme alle Anforderungen. Für den laufenden Betrieb wäre das optimal. Denn jede Erweiterung und Änderung am Quellcode zu Lasten der Stabilität.

Der Quellcode eines Themes ist meistens relativ einfach zu lesen und deswegen macht man in solchen Fällen gerne den Fehler und wurschtelt im Originalquellcode des Themes herum. Wenn man aber den Originalquellcode ändert, nennt man das eine Modifikation und eine Modifikation ist immer schlecht. Ein Theme kann man eigentlich auch als Programm verstehen. Und Programme enthalten üblicherweise Fehler (so ist das nun mal in der Informatik) und müssen deswegen von den Programmautoren gepflegt und gewartet werden. Neue WordPress-Versionen, neue Browser und neue Internet-Standards bringen ebenso neue Anforderungen mit sich und bedingen fortlaufend die Anpassung bestehender Themes. Also müssen Themes immer mal wieder aktualisiert werden (nicht nur Plugins). Bügelt man nun das Update direkt über die bestehende Version (so wird das in der Regel auch gemacht), sind alle eigenen Änderungen weg (überschrieben) und das eigene Theme quasi kaputt. Umgekehrt kann man aber auch nicht auf das Update verzichten (weil sonst das Theme irgendwann kaputt geht) – ein Teufelskreis! Also muss man das Eine in das Andere einarbeiten. Entweder das Update in das geänderte Theme oder die eigenen Änderungen in das Update. Das ist mühsam (und qualvoll).

Modifikationen sind meistens aber trotzdem nicht zu vermeiden. Einerseits hat man beim Design oft noch Änderungswünsche, andererseits möchte man gewisse Funktionalität ergänzen. Weil die Sache aber so viel Arbeit verursacht, hat man sich bei WordPress das Konzept der Child-Themes ausgedacht. Der Ansatz ist so einfach wie überzeugend. Durch ein Child-Theme kann man Logik und Präsentation dem Parent-Theme (Original-Theme) hinzufügen – ohne den Quellcode des Originals zu ändern. Auch ein Überschreiben und Verändern von bestehender Logik und Präsentation ist möglich. Der Mechanismus ist eigentlich ganz simpel. WordPress lädt beim Anzeigen einer Seite erst das Original-Theme und hängt dann alle Änderungen des Child-Theme in einem zweiten Schritt dazu. Das bringt sehr viele Vorteile mit sich. Zuerst ist es sehr übersichtlich. Es ist nämlich auf einen Blick im Theme-Ordner zu erkennen, welche Dateien geändert wurden. Weiterhin kann das Original aktualisiert werden, ohne die eigenen Erweiterungen zu verlieren. Denn die Erweiterungen befinden sich alle im Child-Theme und nicht im Parent-Theme. Generell gibt es nur recht wenige Szenarien, welche einen Einsatz von Child-Themes ausschließen.

Im Zusammenspiel von Themes mit Plugins ist noch ein weiterer Sachverhalt erwähnenswert. Die Funktionalität von Plugins wird hauptsächlich über den Mechanismus der sogenannten Hooks in der WordPress Instanz bereitgestellt. Hooks kann man sich als vordefinierte Einstiegspunkte im Programmablauf vorstellen. An diesen Einstiegspunkten kann ein Plugin weitere Logik und Präsentation in das WordPress einbringen. Das hat viele Vorteile, aber auch Nachteile. Der Nachteil liegt hauptsächlich darin, dass der Einstiegspunkt nicht variabel, sondern fest definiert ist. Aus diesem Grund bieten viele Plugins dem WordPress-Betreiber die Möglichkeit an, die Plugin-Funktionalität über einen Shortcode oder ein Snippet selbst an beliebiger Stelle ins Theme hinein zu programmieren. Das ist sehr praktisch, hat aber schon wieder Nachteile. Denn jetzt besteht eine feste Abhängigkeit zwischen Theme und Plugin. Deaktiviert man beispielsweise das Plugin, läuft das Theme auf einen Fehler, weil der Quellcode interne Funktionen aufruft, die nicht mehr zur Verfügung stehen. Deswegen muss man in diesen Fällen immer erst den Quellcode ausbauen, bevor man das entsprechende Plugin deaktiviert. Aus Betriebssicht ist das quasi eine Katastrophe. Deswegen sollte man weitgehend solche Abhängigkeiten vermeiden.

Updates

Normalerweise sind automatische Updates in der Informatik nicht sehr beliebt. Das kann man hauptsächlich auf zwei Gründe zurückführen. Erstens, durch ein Auto-Update gibt man Kontrolle ab und die Anwendung entwickelt damit in gewisser Sicht ein Eigenleben. Zweitens, bei einem Update kommen oft Fehler mit. Diese Fehler sind dann quasi sofort aktiv. Ich selbst finde aber, das Auto-Update ist einer der besten Erfindungen der Informatik überhaupt.

Das Problem mit den Updates ist einfach die Zeit, die man mit den Updates verbringt. Sie kommen immer in dem Moment, wo man es grad gar nicht gebrauchen kann. Ein Update ist zwar schnell gemacht, aber meistens kommt ein Update nicht allein, es kommen noch ganz viele andere Updates mit. Da will man kurz was erledigen, macht drei Programme auf und wird überall mit einem Update-Fenster begrüßt. Das Update zerstört ein wenig die Idee der Informatik. Was bringt all die gewonnene Zeit, wenn wir die Effizienz gleich wieder an anderer Stelle (durch Updates) verlieren? Kein Update ist auch keine Lösung, weil ein Update wichtige Fehlerkorrekturen mitbringt, was auch der wesentliche Grund für das Update ist.

Aus diesem Grund nehme ich hier eine andere Position ein und empfehle das Auto-Update ausdrücklich. Natürlich gibt es jetzt immer noch das Problem der fehlerhaften Updates. Das muss man leider in Kauf nehmen. Überhaupt, die Gegenargumentation erscheint mir auch nicht ganz schlüssig. Denn wenn man sich wirklich vor fehlerhaften Updates schützen möchte, ist das ziemlich aufwändig. Bei jeder neuen Version von WordPress oder eines seiner Plugins muss man ausgiebig im Internet recherchieren und die Foren der Community lesen, um herauszufinden, ob es Probleme mit dem neuen Release gibt. Auch Stable-Releases und -Zweige schützen vor diesem Aufwand nicht. Von selbst kommen diese Informationen nicht zugeflogen, das geschieht nur bei Updates von Programmen mit richtig viel Aufmerksamkeit (z.B. iOS von Apple). Jedenfalls, diesen Aufwand betreibt eigentlich kein Mensch. Das würde auch keinen Mehrwert schaffen und empfiehlt sich nur bei geschäftskritischen Anwendungen.

Es gibt jedoch eine grundsätzliche Voraussetzung, die für das Auto-Update erfüllt sein muss. Die WordPress Instanz muss vollständig modifikationsfrei laufen. WordPress selbst, die eingesetzten Plugins und das verwendete Theme. Eine einzige Modifikation und das Auto-Update ist aus dem Spiel. Denn jedes Update würde natürlich automatisch die Modifikationen überschreiben. Hier in diesem Blog gab es anfangs recht viele Modifikationen (hauptsächlich im Präsentationscode der verwendeten Plugins). Diese Modifikationen sind mittlerweile alle wieder ausgebaut und auf anderem Wege realisiert. Einerseits war der Pflegeaufwand auf Dauer einfach zu groß, andererseits wollte ich nicht auf die Effizienz der Auto-Updates verzichten.

Backups

Über ein regelmäßiges Backup müssen wir auch nicht diskutieren. Ein regelmäßiges Backup der eigenen WordPress Instanz ist Pflicht. Zwar hat man die eigenen Inhalte oft noch lokal gespeichert, aber für die Kommentare der Leser gilt das nicht. Und wenn ein mehrjährig altes Blog crasht, so schnell baut man das nicht wieder auf, das tut richtig weh. Deswegen sollte das Backup auch das ganze Paket enthalten, also die Datenbank und alles, was im Root-Verzeichnis von WordPress rumliegt. Das Backup selbst muss zwingend automatisiert sein. Ein manuelles Backup ist nämlich das gleiche wie kein Backup. Außerdem ist manuell wieder Arbeit und Arbeit wollten wir ja vermeiden. Automatisierung kann man leider nicht herzaubern, der Backup-Mechanismus muss die Automatisierung auch unterstützen. In der Regel gibt es dabei zwei Möglichkeiten, die internen WP-Jobs von WordPress oder die externen CronJobs vom Provider. Diese beiden Jobs machen nichts anderes als das Backup anzustoßen, indem sie in regelmäßigen Abständen eine URL aufrufen (welche wiederum ein Programm ausführt, welches das Backup durchführt). Einfach und praktisch.

Aber nur automatisch Backup machen, das reicht noch nicht. Das Sicherungsprogramm sollte unbedingt auch die Verwaltung der Backups unterstützen. Was ist damit gemeint? Der Sicherungsmechanismus sollte in der Lage sein, alte Backups nach einer zuvor definierten Regel wieder zu löschen. Kann er das nicht, läuft irgendwann der Zielspeicherort voll. Das wäre dann schon wieder nervig, weil man periodisch und manuell die alten Backups löschen muss. Ist natürlich schnell gemacht, aber viel besser ist es, wenn das automatisch durchgeführt wird und man sich nicht weiter drum kümmern muss.

Theoretisch kann man das Backup übrigens auch direkt auf den Webspace machen, wo das WordPress selbst liegt. Die goldene Regel besagt zwar, dass Backups unbedingt woanders abgelegt werden sollen. Wenn im Arbeitszimmer ein Feuer ausbricht und den Computer vernichtet, dann hilft das Backup nicht weiter, wenn sich die Backup-Festplatte auch im Arbeitszimmer befand. Allerdings sind solche Ernstfälle (Zerstörung von Außen) oft schon beim Provider durch entsprechende Redundanzen (beispielsweise Spiegelung aller Server in ein anderes Rechenzentrum) abgesichert. Unser eigenes Backup hat mehr den Zweck, die eigenen Scherben aufzukehren. Also zu helfen, wenn wir selbst etwas kaputt gemacht haben. Der Provider ist hier nicht zuständig. Würde auch nichts bringen, weil unsere Code-Fehler ja auch ins zweite Rechenzentrum gespiegelt werden würden. Es ist also anzuraten, den Sicherungsmechanismus genau zu betrachten.

Automatisierung

Neben überlegter technischer Konzeption ist Automatisierung auch der größte Hebel, um Aufwände im Betrieb von WordPress zu minimieren. Kurzum, alles was man automatisieren kann, sollte automatisiert werden. Und alles was automatisiert ist, das brauchen wir nicht mehr selbst erledigen. Damit etwas automatisiert werden kann, muss es strukturell für die Automatisierung konzipiert sein. Ein paar Dinge wie Update und Backup wurden zuvor schon angesprochen. Aber man kann noch mehr automatisieren. Sogar Teile der Präsentation auf dem User Interface, die Funktion „Ähnliche Artikel“, zum Beispiel.

Beim Stichwort Automatisierung denkt man auch gerne an den Spam-Ordner der Kommentare. Es gibt viele Plugins, welchen den Ordner periodisch leeren. In diesem Fall würde ich allerdings wiederum von einer automatischen Lösung abraten. Denn es verirrt sich immer mal wieder ein richtiger Leserkommentar in den bösen Ordner. Dieser Kommentar wäre dann natürlich auch weg. Und das wäre sehr schade, denn jeder Leserkommentar ist ein Geschenk. Den Spam-Ordner deswegen lieber nach eigener Kontrolle selbst leeren. Dieser Ratschlag ist aber auch schon wieder Quark, weil auf großen Blogs gerne mal täglich über hundert Spam-Kommentare eingehen. Das ist einfach viel zu viel Volumen und deswegen eine manuelle Kontrolle nicht möglich. Und so ist das eigentlich auch immer in der Informatik. Jegliche Aufgabenstellung erfordert stets eine Einzelfallbetrachtung und keine Empfehlung ist allgemeingültig (auch dieser Artikel nicht).

Qualitätssicherung

Mir persönlich stellen sich immer die Haare zu Berge, wenn Kollegen auf ihrem laufenden Blog neue Plugins ausprobieren oder neuen Code testen. Das ist wie Operieren am offenen Herzen. Schließlich klappt selten alles auf Anhieb. Und der Besucher darf live und in Farbe zusehen wie sich das Blog verschiebt, verdreht und verzwirbelt. Is nicht cool, is Bullshit!

Nach der klassischen Lehre geht man bei solchen Dingen mehrstufig vor. Zuerst entwickelt und konfiguriert man eine neue Funktion in der Entwicklungsumgebung. Wenn der Entwickler dann fertig entwickelt hat, führt er einen sogenannten Modul-Test durch (meistens ist er aber viel zu faul dafür). Dann wird diese Entwicklung in eine Testumgebung geschoben und dort wird dann aber wirklich geprüft, ob die Funktion überhaupt funktioniert und auch nichts anderes kaputt macht (oft wird dann nur eine kurze Sichtprüfung durchgeführt). Und erst zum Schluss kommt das Teil in die Produktion, also in das laufende WordPress für die Öffentlichkeit (und dort geht dann trotzdem alles kaputt, weil zuvor nicht richtig getestet wurde).

Für einen privaten Blogger ist dieser Prozess natürlich oversized. Trotzdem empfiehlt es sich, das Konzept in Teilen anzuwenden. Der dreistufige Prozess macht natürlich zu viel Arbeit und bringt zu wenig Mehrwert, aber zweistufig ist oftmals akzeptabel. Tekkies halten sich dafür ein lokales WordPress auf dem eigenen PC. Dort wird entwickelt, getestet, neue Plugins ausprobiert. Man braucht dazu einen Apache-Server mit PHP-Installation sowie einen MySQL-Server. Quasi die gleiche Infrastruktur wie im Netz. Das ist ziemlich kompliziert und deswegen auch nicht wirklich eine gute Lösung. Auch Profis haben damit ständig Probleme, weil die Versionsstände zwischen lokaler Installation und Installation beim Provider meistens nicht identisch sind. Was lokal unter PHP 5.0 funktioniert, ist nach dem Upload ins Netz kaputt, weil der Provider PHP 5.soundso einsetzt und das Skript aus irgendwelchen Gründen nicht mit PHP 5.soundso funktioniert.

Ich bin persönlich bin schon lange von diesem Konzept weg und eine simple Alternative ist beispielsweise, das eigene Blog noch ein zweites Mal im Internet beim gleichen Provider unter einer Subdomain zu hinterlegen (mit Zugriffsschutz). Die Infrastruktur entspricht 1:1 der Produktionsinstanz. Dort werden dann alle Entwicklungen und Änderungen vorgenommen. Und erst, wenn alles sauber funktioniert, werden diese Sachen im produktiven WordPress nachgezogen. Zugegeben, das macht Arbeit. Sogar viel mehr Arbeit als man im ersten Moment annimmt. Aber das Ergebnis dieser Arbeit ist ein stabil laufendes Blog, das funktioniert. Zudem hat man einen kleinen Spielplatz, um neue Plugins, Themes oder Konzeption in Ruhe auszuprobieren und der Besucher bleibt davon verschont. Ein weiterer Vorteil ist, dass die produktive Datenbank nicht mit Konfigurationsresten zugemüllt wird, die von Plugins stammen, die man mal kurz ausprobiert hat.

Insgesamt wird Software einfach zu wenig getestet. Das ist mitunter ein Grund, warum Software so fehleranfällig ist. Ein neues Widget einbauen, Blog aufrufen, wird das Widget angezeigt, ja, funktioniert. Das ist kein Testen. Wenn man richtig testen möchte, dann muss man die Änderung herausfordern und vor Probleme stellen. Auf allen Seiten angreifen und kreativ werden. Das ist Testen. Eine Änderung kurz auf dem SmartPhone und Tablet anschauen, das ist zu wenig. Man muss die Geräte beispielsweise auch drehen (Landscape-Modus, Portrait-Modus); ein gutes responsive Design bringt hier schon völlig anderes CSS zum Einsatz. WordPress ist gemeinhin als Anwendung klassifiziert, aber eigentlich ist es viel mehr als eine Anwendung. Es ist ein System und das System besteht aus WordPress selbst, den Plugins, dem Theme und den eigenen Daten. Zwischen diesen Elementen besteht Interaktion, Rückkoppelung und eine feste Logik. Wenn man jetzt in diese Logik eingreift und nur ein kleines Detail verändert, verändert man damit einhergehend auch alle anderen Elemente und dadurch das ganze System. Und die Veränderung wird an Stellen wirksam, die man niemals im Verdacht hatte. Deswegen sollte man bestehende Systeme immer nur sehr behutsam verändern und stets ausgiebig testen.

Inhalte

Nun bieten moderne Themes viele coole Features an. Features wie spezielle Boxen, mehrspaltiges Layout oder andere nützliche Dinge. All diese Sachen kann man in seinen Texten verwenden. Das ist hilfreich, hat aber auch Nachteile. Diese Nachteile spürt man am Anfang aber nicht (sondern erst später, was ziemlich fies ist). Zum Beispiel, wenn man irgendwann das Theme wechselt (und das ist so sicher wie das Amen in der Kirche). Danach stehen die Features, die man nun überall in die Artikel eingebaut hat, natürlich nicht mehr zur Verfügung. In der Konsequenz werden die betroffenen Texte auch nicht mehr richtig dargestellt. Inhalt und Logik wurden nämlich miteinander verkettet. Der Inhalt ist noch da, aber die Logik fehlt. Die Problematik wurde oben schon einmal angesprochen. Solche Konstellationen sind richtig arbeitsaufwändig. Schließlich müsste man nun alle betroffenen Artikel bearbeiten und die Funktion entfernen. Sofern man überhaupt noch weiß, in welche Posts man beispielsweise einen Shortcode eingebaut hat. Deswegen sollte man sich gut überlegen, ob und in weit man Funktionalität in die Inhalte hineinzieht. Einmal Logik in den Content eingebaut, muss man diese Logik dauerhaft erhalten.

Das gibt ebenso für CSS-Deklarationen. Für den Text Verloren im Unterbewusstsein musste ich weitere Style Sheets zusätzlich implementieren, weil der Funktionsumfang des Themes für die Inszenierung nicht ausreichend war. Das ist schon ein bisschen verrückt (finde ich). Diese Individualität hab ich mir jedoch mit Nachteilen im Betrieb erkauft. Schließlich muss ich diese Style Sheets nun in jedem neuen Theme erneut implementiert und diesen Ballast quasi über die Lebenszeit dieses Blogs mitschleifen.

Eine ähnliches Problem umgibt auch die gewöhnliche Auszeichnung von Elementen im Text (Überschriften, Textabschnitte, Zitate). Diese Elemente sind recht schnell über den Editor von WordPress durchformatiert. Man kann Schriftgröße und Schriftgewicht individuell definieren und sogar Bilder mit Textumfluss einbauen. Diese Formatierungen werden anschließend zusammen mit dem Inhalt abgespeichert. Das Problem ist nun, dass sich diese Auszeichnungen natürlich auch im nächsten Theme aktivieren, aber dort ganz anders zu Geltung kommen. Jetzt muss man schon wieder hingehen, alle Beiträge öffnen und anpassen (ist doch Scheiße). Diesem Sachverhalt kann man entgegen wirken, in dem man die Elemente im Text so einfach wie möglich präsentiert und jegliche Formatierung in das zentrale Style Sheet auslagert. Einschränkend wirkt diese Vorgehensweise nicht, weil sich durch logische Auszeichnung (h1, strong, quote, etc), Containern (div, span) oder die Definition von Klassen (class) das gleiche individuelle Ergebnis erreichen lässt. Das Paradigma besagt, Inhalt und Präsentation konsequent zu trennen.

Outsourcing

In der Wirtschaft ist Outsourcing immer ein großes Thema. Besonders bei wachsenden Unternehmen. Durch Outsourcing kann man sich auf die Kernthemen fokussieren (soweit zumindest die Idee) und alles nervige Beiwerk in fremde Hände geben. Dabei muss man noch nicht mal einen Kompromiss in der Qualität hinnehmen, sondern bekommt für weniger Geld in der Regel auch mehr Qualität (sagen zumindest die Betriebswirtschaftler). Denn für den in Anspruch genommenen Dienstleister sind die ausgelagerten Leistungen das Kerngeschäft und kein nerviges Beiwerk. Deswegen legt der Dienstleister dort auch viel mehr Energie rein. In Wirklichkeit gilt das nicht nur für Unternehmen, sondern auch für das eigene, kleine Blog. Viele Funktionen kann man einfach auslagern. Und tatsächlich fühlt sich das auch im kleinen privaten Maßstab richtig gut an.

Die meisten Blogger haben die Webseitenstatistik beispielsweise an Google oder Jetpack abgegeben. Ist auch gut so, weil technisch ist Webseitenstatistik recht anspruchsvoll. Auch der Newsletter ist eine Komponente, die man gerne in fremde Hände gibt. Aus Betriebssicht ist das optimal, weil den Betrieb muss jetzt jemand anderes machen. Die Arbeit ist man los und kann sich anderen Dingen zuwenden. Es ist immer gut, wenn Spezialisten am Werk sind. Denn wenn wir ehrlich sind, sind wir selbst keine Spezialisten. War uns überhaupt bewusst, dass wir Personaldaten speichern, wenn wir einen Newsletter anbieten? Personaldaten sind sehr sensible Daten, deren Handhabung gesetzlich geregelt ist. Kennen wir die deutschen und europäischen Vorgaben, denen wir unterliegen, wenn wir Personaldaten speichern?

Eine Sache sollte man allerdings bedenken. Die Welt verändert sich und vielleicht möchte man irgendwann die Funktion in das eigene Blog zurückholen oder den Dienstleister wechseln. Aus diesem Grund sollte der Anbieter unbedingt auch Werkzeuge anbieten, um die betroffenen Daten (z.B. Newsletter-Empfänger) in einem maschinell lesbaren und standardisierten Format zu exportieren. Auf diese Details muss man achten, sonst hat man später eventuell ein richtig großes Problem (im besten Fall nur Arbeit in Form von manueller Datenerfassung).

Performance

Was die Performance angeht, da gehen die Meinungen über WordPress weit auseinander. Eine allgemeingültige Bewertung fällt schwer. Fakt ist, das Basissystem ist eigentlich recht zackig unterwegs. Dass man WordPress so einfach erweitern kann, ist natürlich toll. Dummerweise geht jede Erweiterung zu Lasten der Performance.

Auf Erweiterungen wollen wir aber trotzdem nicht verzichten. Im Internet kursieren viele Tipps und Anleitungen, wie man die Performance von WordPress steigern kann. An erster Stelle steht immer die Empfehlung, sich auf das Wesentliche zu beschränken. Dieses Paradigma würde ich auch unterschreiben. Funktionen, die man nur selten braucht, oder die keinen spürbaren Mehrwert bringen, auf die kann man dann auch verzichten. Das Wesentliche bedeutet in der Konsequenz natürlich so wenige Plugins wie nur möglich einzusetzen. Ein anderer Ratschlag besagt, die nötige Funktion einfach selbst in der functions.php einzubauen oder gar direkt in das Theme hinein zu programmieren. Ein kleiner Code ist dem Plugin aus Sicht der Performance stets im Vorteil. Trotzdem rate ich davon ab, weil der Nachteil einfach stärker wiegt. Denn auf lange Sicht man muss sich natürlich wieder selbst um diese „Eigenentwicklung“ kümmern. Aber damit nicht genug. Denn bei jeder Anpassung (z.B. Customizing) muss man in den Quellcode. Sehr umständlich. Mir persönlich ist ein Plugin, das aktiv von einem Profi gepflegt wird, und das ich über ein User Interface konfigurieren kann, viel lieber.

Kleider machen Leute, aber ein optisch ansprechendes Theme kostet auch Geschwindigkeit. Bei entsprechender Optimierung kann man aus dem Theme viel Performance herausholen. Das gibt Pluspunkte von Google und Pluspunkte von Google bringen weitere Besucher. Toll! Nicht so toll ist der Sachverhalt, dass eine solche Performance-Optimierung richtig viel Arbeit macht. Da muss man schon an sehr vielen Schrauben drehen. Über den Gewinn freuen sich dann auch nur die Bots, weil der Mensch den Unterschied zwischen ein oder zwei Millisekunden gar nicht merkt. Am Ende geht bei diesen Optimierungen oft auch sehr viel kaputt (schließlich hat sich der Theme-Programmierer ja schon was dabei gedacht, dass er das genau so und nicht anders programmiert hat). Dass etwas kaputt geht, merkt man aber leider nicht gleich, sondern wieder erst später und dann muss mal erst mal den Zusammenhang zwischen Fehler und Optimierung herstellen.

Caching geht in die gleiche Richtung. Caching ist technisch eine sehr komplizierte und anspruchsvolle Sache. Lieber die Finger davon lassen! Caching, das kann sich man mal auf die Liste setzen, wenn das Blog richtig brummt oder tatsächlich spürbare Probleme mit der Performance hat. Ansonsten holt man sich nur Schwierigkeiten ins Haus. Dass der Leser den gerade abgeschickten Kommentar nicht gleich sieht, weil WordPress eine gecachte Version (ohne Kommentar) der Seite an den Browser des Besuchers schickt, und in der Konsequenz der Besucher denkt, er wäre geblockt oder der Kommentar wäre im Spam-Ordner gelandet, und der Leser sich dann ärgert, weil er sich viel Mühe beim Schreiben gab und das alles nun für die Katz war, das ist noch das kleinste Problem.

Dokumentation

Bei Dokumentationen verhält es sich genauso wie mit Backups. Jeder weiß, eine Dokumentation ist wichtig, aber trotzdem verzichten viele Leute darauf. Es ist so wie das immer ist. Das Schreiben einer Dokumentation kostet Zeit und der Mehrwert kommt erst verzögert zum Tragen. Aber eigentlich liegt genau hier drin die Zielstellung, mit einer Dokumentation soll man Zeit sparen. In der Regel ist es nämlich so, man macht irgendwas und vergisst, was man da gemacht hat. Und irgendwann muss man da wieder ran und quasi sich selbst recherchieren, also herausfinden, was man da damals komisches gemacht hat, was viel länger dauert.

In dieser Hinsicht habe ich mir persönlich viel Disziplin antrainiert. Das kleine Blog hier ist sehr genau vermessen. Ich dokumentiere sogar für jeden Text alle Content-Typen, die eingesetzt wurden. Welcher Post enthält Bilder? Welcher Post enthält Tweets? Welcher Post enthält Videos? Mit Hilfe einer solchen Dokumentation bin ich sofort in der Lage bei jeglichem Wechsel von technischen Komponenten (Theme, Plugin, Code) festzustellen, an welchen Stellen man testen, eingreifen oder etwas anpassen muss. Das ist ebenso hilfreich, wenn man konzeptionell die Richtung ändert und alte Inhalte entsprechend umstellen möchte. Im ersten Moment mag eine solche Dokumentation zwar übertrieben erscheinen, aber im Ernstfall ist sie ein wahrer Schatz.

Wenn man den Quellcode modifiziert hat, ist eine Dokumentation besonders zwingend. Neben der Beschreibung in einem externen Dokument, sollte man die Änderung zusätzlich auch im Quellcode sichtbar durch einen Kommentar auszeichnen. Und den Code als solches ebenfalls noch mal ausgiebig kommentieren. Lieber etwas mehr als etwas weniger. Wenn man jeden Tag programmiert, kann man einen Quellcode wie eine natürliche Sprache lesen und unmittelbar verstehen. Wenn man jedoch nur ab und zu im Bedarfsfall programmiert, dann muss man meistens den eigenen Code immer wieder neu erlernen und verstehen. Das ist nicht dramatisch, aber es kostet Zeit. Hat man eine Dokumentation, kostet das auch Zeit, aber weniger Zeit.

WordPress im Betrieb

Insgesamt kommt man immer wieder an den gleichen Punkt. Jeder logische Eingriff in ein bestehendes System zieht einen Schwung von Pflichten nach sich. Diese Arbeit würde nicht existieren, wenn man sich mit dem gegebenen Standard (Theme, Funktionalität, Plugins) begnügt. Das sollte man sich von Zeit zu Zeit bewusst machen. Und sich fragen, ob der eigene Anspruch diesen Aufwand auch wert ist. WordPress diente in diesem Text als Beispiel, aber alle angesprochenen Problematiken haben für Joomla, Typo3 oder Drupal die gleiche Gültigkeit. Auf der Meta-Ebene gelten diese Sachverhalte für jegliches IT-System.

WordPress im Betrieb kann sehr einfach sein, aber zeitgleich auch richtig kompliziert, also das Gegenteil. Ich selbst habe mit obigen Strategien sehr gute Erfahrungen gemacht und mittlerweile kann ich mich gar nicht mehr daran erinnern, wann es zuletzt mit diesem Blog technische Probleme gab. Obwohl hier ziemlich viel verbogen und mit spezieller Konfiguration läuft. Stabilität und Fehlerfreiheit ist also möglich und dafür muss technische Individualität auch nicht geopfert werden. Selbst maßgeschneiderte Blogs können smooth laufen. Dafür muss man aber im Schaffensprozess die Auswirkung auf den Betrieb mitbeleuchten und zwischen Perfektion und Arbeitsaufwand auf vielen Ebenen abwägen. An dieser Balance hängt eigentlich am Ende alles.