produktivzone
13 Normseiten, geschätzte Lesezeit 13 Min.

Wordpress

Einleitung

Wenn man einigen Statistiken glauben darf, betragen die Marktanteile von Wordpress inzwischen über 50% (Stand Mitte 2014). Und so verwundert es nicht, dass unser Netzwerk immer wieder für Wordpress-Projekte angefragt wird. In den meisten Fällen verweise ich auf befreundete Agenturen, die sich auf Wordpress spezialisiert haben. Das tue ich nicht, weil ich Wordpress nicht mag, im Gegenteil. Wenn man mit Kunden zu tun hat, die nicht ganz so technikaffin sind, kann Wordpress durchaus eine Hilfe sein.

Wenn ich Wordpress Anfragen ablehne, dann hat das gewöhnlich technische Gründe. Nun ist es so, dass der Kunde in der Regel nicht allzuviel von der Technik versteht, sonst würde er ja nicht zu mir kommen. Und so kann es vorkommen, dass meine Absage trotz Erklärungen auf Unverständnis stößt. Schließlich werden heutzutage ja zahllose Internet-Auftritte mit Wordpress realisiert.

Und ja, es stimmt, in der Praxis kann tatsächlich so ziemlich jedes Problem mit Wordpress gelöst werden, wenn man nur will. Allerdings sind nur die wenigsten Imple­mentationen wirklich sinnvoll und das kann ich auch begründen. Und genau das möchte ich in diesem Artikel tun.

Wordpress ist nicht das, was es zu sein scheint

Wordpress wird gern in dieselbe Schublade gesteckt, wie Joomla, Typo3, Contao oder Drupal. Aber das ist verkehrt. Denn Wordpress ist von Haus aus gar nicht als Content Management System konzipiert worden, sondern als reine Blog-Software. Eigentlich wäre damit bereits alles gesagt, gäbe es da nicht soviele Internetseiten, die Wordpress als CMS nutzen.

Dass Wordpress überhaupt als CMS eingesetzt werden kann, erklärt sich durch den simplen Umstand, dass das System mit Hilfe von Plugins zu einem solchen aufgerüstet werden kann. In seiner Grund­struktur bleibt das System aber dennoch eine Blog-Software, was auch die hohe Bediener­freundlichkeit erklärt. Denn die Anforder­ungen an ein Blogsystem sind naturgemäß sehr viel geringer, als die Anforderungen an ein klassisches CMS. So gesehen baut der gute Ruf von Wordpress eigentlich auf einer Illusion auf.

Grundsätzlich ist nichts gegen Wordpress als CMS einzuwenden, wenn diese Lösung auch wirklich nachhaltig funktionieren würde. Aber leider ist das nicht ganz so einfach, wie es oft dargestellt wird. Denn nur weil sich der Mainstream für diesen Weg entschieden hat, muss das noch lange nicht der kürzeste sein. Weshalb andere Systeme schwieriger zu bedienen sind, als Wordpress, hat berechtigte Gründe.

Dazu muss man vorausschicken, dass alle Internetseiten auf der Welt zwei Dinge gemeinsam haben: sie sind in der textbasierten Aus­zeichnungs­sprache HTML formatiert und sie werden über das Netz­werk­protokoll HTTP übertragen. Das bedeutet, die Anforderungen an eine Internetseite sind immer dieselben, egal ob sie mit Typo3, Contao oder Wordpress realisiert worden sind.

Man kann deshalb ganz allgemein die Aussage treffen, je mehr Einstellungen in einem Content Management System vorgenommen werden können, desto mehr kann dieses System. Daraus folgt, dass der Funktionsumfang eines CMS untrennbar mit seiner Komplexität verbunden ist. Das kann jeder bestätigen, der sich schon einmal etwas intensiver mit Content Management Systemen beschäftigt hat.

So wird Typo3 einerseits für seinen überragenden Funktionsumfang als eierlegende Wollmilchsau gerühmt, andererseits für seine enorme Komplexität verflucht. Dass Wordpress so einfach zu bedienen ist, dann liegt es schlicht daran, dass es von Haus aus weniger kann, als seine Konkurrenten. Und das entspricht auch der Realität. Ich werde das im nächsten Kapitel ausführlicher begründen.

Wenn man also Wordpress zu einem Content Management System aufrüstet, dann steigt naturgemäß auch der Komplexitätsgrad des Systems, was wiederum auf Kosten der Usability geht. Führt man das konsequent weiter, wird man irgendwann feststellen, dass es kaum einen Unterschied macht, ob man mit Wordpress arbeitet oder einem regulären CMS. Denn in dem Moment wo dieselben Anforderungen erfüllt werden, müssen auch dieselben Parameter konfiguriert werden und damit ist auch derselbe Komplexitätsgrad erreicht.

Aus der Sicht des Bedieners macht es am Ende keinen Unterschied, ob er mit einem CMS arbeitet oder mit Wordpress. Technisch gibt es allerdings sehr große Unterschiede: So ist der Quelltext und die Datenstruktur in einem regulären CMS auf die mitgelieferte Funktionsvielfalt eingestellt. Bei Wordpress sind die CMS-Features von Haus aus nicht im System enthalten. Deshalb müssen die dazu benötigten Funktionen in Form von Plugins nachgerüstet werden. Das Problem dabei ist, dass jedes Plugin seine Aufgaben autonom lösen muss. Denn die Kompatibilität zu zukünften Versonen muss erhalten bleiben.

Um es auf den Punkt zu bringen: Sie können mit Ihrem Motorroller dieselbe Strecke zurücklegen, wie mit einem Motorrad, keine Frage. Aber der Roller lässt sich nicht zu einem Motorrad aufrüsten, ohne dass Sie den Motor austauschen. Und wenn das einmal geschehen ist, dann kann der Roller auch nicht mehr als solcher gewartet werden. Schauen wir uns die Unterschiede einmal etwas genauer an:

Was Wordpress von einem CMS unterscheidet

Rolle/Rechte-Verwaltung

Es gibt in Wordpress keine echte Rolle/Rechte-Verwaltung, sondern nur die fünf festgelegte Benutzerrollen Administrator, Redakteur, Autor, Mitarbeiter und Leser, wobei es sich hier genau genommen um Rechte handelt, nicht um Rollen.

Das System lässt sich zwar mit Hilfe von zusätzlichen Plugins um weitere Rechte erweitern, aber eine Zuweisung von über­geordneten Rollen ist technisch nur indirekt möglich. Denn die vorgegebenen Datenstruktur darf wegen der Aufwärts-Kom­patiblität zu zukünftigen Updates ja nicht verändert werden.

geschützte Bereiche

In Wordpress können einzelne Seiten mit einem Passwort ge­schützt werden. Allerdings muss jeder Benutzer dieses Passwort kennen, was in den wenigsten Fällen Sinn macht. Deshalb setzt man zu diesem Zweck Membership-Plugins ein. Natürlich sind auch diese nicht im System integriert, sondern nur "aufgepfropft". Deshalb beziehen sich die Memberships gewöhnlich nur auf die regulären Blog-Einträge oder Seiteninhalte. Auch hier gilt: wenn die Rechte auf einzelne Funktionen erweitert werden sollen, muss das von Hand ausprogrammiert werden. Wenn man dabei auch noch auf Kompatiblität achten muss, können die Workarounds entsprechend umständlich werden.

Mehrsprachigkeit

Man mag es kaum glauben, aber Wordpress unterstützt von Haus aus tatsächlich keine Mehrsprachigkeit. Auch hierfür werden separate Plugins benötigt, was bedeutet, dass auch die sprachlichen Abhängigkeiten nur aufgesetzt sind. Ab­hängig­keiten in den verschiedenen Modulen und Funktionen müssen ebenfalls von Hand ergänzt werden. Besonders problematisch kann es werden, wenn bestimmte Plugins mehrsprachig gemacht werden müssen. Denn dadurch geht naturgemäß die Aufwärts-Kom­patiblität verloren.

Inhalttypen

In Wordpress gibt es nur zwei Inhalttypen (Blog-Eintrag und statischer Content). Diese Inhalte können auf den Internetseiten von Haus aus nur untereinander dargestellt werden, so wie man es von Weblogs gewohnt ist. Deshalb braucht es für jede Dar­stellungsart jeweils eine eigene HTML-Vorlage (Theme). Das kann bei anspruchsvollen Darstellungen ausgesprochen umständlich werden. Auch dieser Aufwand kann nur schwer eingeschätzt werden.

Templatesystem

In Wordpress sind keine abstrahierten Template-Strukturen mit Vererbung vorgesehen. So wurde beispielsweise auf eine separate Templatesprache gänzlich verzichtet, ebenso auf ergänzende Template-Systeme. Das bedeutet, die Abbildung von komplexen Inhalten muss in den einzelnen Plugins manuell in PHP ausprogrammiert werden. Hierzu steht eine definierte Include-Hierarchie zur Verfügung, an die man sich aus Kompatiblitäts­gründen besser halten sollte. Spätestens hier endet der Komfort, den man vom Backend her gewohnt ist. Deshalb haben viele Agenturen aufgehört, selbst Templates zu erstellen. Statt dessen werden bestehende Templates angepasst oder neue eingekauft. Das spart Kosten.

Navigation

In einem Blog werden die Artikel gewöhnlich in einer Listen­ansicht aufgelistet, in der seitenweise vor und zurück navigiert werden kann. In einem CMS wird weniger mit Listenansichten gearbeitet, als vielmehr mit einer festen baumartigen Navigations­struktur, worüber man direkt zu den gewünschten Inhalten navigieren kann. Solch eine Navigations­struktur war in Wordpress ursprünglich nicht vorgesehen, wurde aber später nachgesrüstet.

Die Implementation erfolgte dabei leider nicht in einer separaten Datenbank-Tabelle, sondern über die dieselbe Tabelle, in der auch die einzelnen Artikel enthalten sind. Die Baumstruktur wird auch hier über Mutter/Kind-Datensätze hergestellt. Der Nachteil ist aber, dass die Parametrisierung des Navigatiosnbaumes nur im Rahmen der vorgegebenen Datenstruktur erfolgen kann. Will man damit komplexe Navigationsstrukturen abbilden, ist man deshalb auf ergänzende Metainformationen angewiesen, was den Umgang umständlich machen kann.

Datenschutz

Zu Beachten ist natürlich auch, dass Wordpress ein amerikanisches Produkt ist. Im Vergleich zu Deutschland spielt der Datenschutz in Amerika eine eher untergeordnete Rolle. So weiß man von einigen Plugin und Templates, dass sie ungeniert nach Hause telefonieren.

Am bekanntesten dürfte in diesem Zusammenhang das Plugin Askimet sein. Dabei handelt es sich um ein Tool, womit Spam aus den Kommentaren herausgefiltert werden kann. Dieses Tool sendet so ziemlich alle verfügbaren Umgebungsvariabeln nach Amerika. Das führt dazu, dass die Verwendung von diesem und vielen anderen Plugins in Deutschland rechtlich fragwürdig ist. Im Fall von Askimet kann auf Wunsch ein weiteres Plugin installiert werden, welche die Kommunikation verhindert.

Mandantenfähigkeit

Wordpress ist von Haus aus multisitefähig, was aber lediglich bedeutet, dass ein Wordpress-Auftritt über verschiedene Domänen erreichbar ist. In der Praxis macht dieses Vorgehen wenig Sinn, weil die Suchmaschinen dazu neigen die Domänen wegen Duplicate Content herunter zu stufen.

Dass man jeder Domäne eine eigene Navigation mit eigenen Templates zuweist, ist von Haus aus nicht vorgesehen. Somit ist Wordpress nicht wirklich multidomainfähig oder mandantenfähig. Das bedeutet, für jede Domäne wird eine eigene Wordpress-Instanz benötigt. Es soll sogar Auftritte geben, die mit mehreren hunderten Instanzen arbeiten. Dass solch eine Vorgehensweise nicht effizient sein kann, liegt auf der Hand.

Suchmaschinen

Wordpress wird von den Bots der Suchmaschinen nicht als CMS wahrgenommen, sondern als Weblog, was es ja auch ist. Das bedeutet, Google geht davon aus, dass die Inhalte schneller ändern, als es in einem regulären Content Management System üblich ist. In der Folge werden die Inhalte ebenso schnell indexiert, wie zurückgestuft. Wenn sie also mit Wordpress reguläre CMS-Auftritte realisieren wollen, müssen Sie dafür sorgen, dass die Inhalte regelmäßig aufgefrischt werden, denn sonst riskieren Sie, dass Ihre Inhalte bei den Suchmaschinen zu wenig Beachtung finden.

Datenbank

Dass Wordpress eine historisch gewachsene Bloggsoftware ist und kein CMS, wird spätestens dann deutlich, wenn man sich die Datenbankstruktur etwas genauer anschaut. Diese ist mit nur 11 Tabellen erstaunlich minimalistisch gehalten.

Zu beachten ist, dass sich alles um eine zentrale Tabelle dreht, die sich wp_posts nennt. Die Datensätze werden unterteilt in die Post-Types Post, Page, Attachment, Revision und Navigation. Das bedeutet, darin enthalten sind sämtliche Seiten, Artikel, Anhänge, Versionierungen und obendrein noch die vollständige Navigations-Struktur in Mutter/Kind-Anordnung. Alle anderen Tabellen sind um diese Tabelle herum angeordnet.

Wie es in einem historisch gewachsenen System üblich ist, wurden die Mastertabellen nicht erweitert, sondern um weitere Meta-Tabellen ergänzt. Die relationale Zuweisung erfolgt nicht konsequent genug, weshalb es in bestimmten Fällen zu Inkonsistenzen kommen kann, wofür es in den ein­schlägigen Foren besondere Workarounds gibt. Natürlich existieren auch hierfür Plugins. Volltext-Indexierung der Inhalte sucht man vergebens. Um ehrlich zu sein, es ist mir ein Rätsel, wie es dieses magere System zu einem derart großen Bekanntheitsgrad schaffen konnte.

Open Source ist nie wirklich umsonst

Wordpress ist eine Open Source Software, ebenso wie Typo3, Joomla, Contao, Drupal und viele andere. Die meisten dieser Tools stehen unter der GNU-Lizenz. Das bedeutet, die Software darf kostenlos verwendet werden, sofern bestimmte Bedingungen eingehalten werden, wie z.B. die Nennung der Autoren. Die wichtigste Bedingung wird in der Copyleft-Klausel definiert. Sie besagt, dass alle zukünftigen Änderungen und Ableitungen des Systems unter derselben Lizenz stehen, wie das System selbst. Das bedeutet, jede Änderung, die ich an dem System vornehme, darf von anderen Programmierern uneingeschränkt weiterverwendet werden. Wenn ich ihn daran hindere, verliere ich meine eigenen Rechte an dem System.

In der Praxis ist es so, dass die Content Management Systeme auf Servern gehostet werden, auf deren Dateisystem man im Normalfall keinen Zugriff hat. Und damit ist auch kein Zugriff auf den Quelltext möglich. Es käme auch niemand auf die Idee, nachzufragen, wie man ein bestimmtes Problem gelöst hat. Insofern muss man die Konkurrenz erst fürchten, wenn sich der Kunde dazu entschließt, den Dienstleister zu wechseln. Doch das ist nur die rechtliche Seite. Viel problematischer sind die technischen Implikationen.

Bei der Entwicklung von kommerzieller Software ist die Anzahl der beteiligten Programmierer normalerweise festgelegt. Für die Koordination des Projektes ist meist ein zentraler Projektleiter zuständig. Er verteilt nicht nur die Aufgaben, er legt auch fest, unter welchen Maßgaben ein Projekt realisiert werden soll. Dazu gehört beispielsweise die Wahl der zu verwendeten Werkzeuge (IDE, Repository, DB), die Wahl der zu verwendenden Bibliotheken (UI, etc.) oder die Art der Programmierung (MVC, OOP-Pattern). Und natürlich werden auch die Programmier-Konventionen festgelegt (Prä-/Post­fixes von Variabelnamen, Funktionen oder Klassen). Die Projektabläufe werden penibel ausgearbeitet und überwacht. Denn nur so kann sicher gestellt werden, dass die Kosten nicht aus dem Ruder laufen.

Eine Open Source Software entsteht meist durch das Engagement eines einzelnen Programmierers, der die Öffentlichkeit sucht, um Entwicklungskosten zu vermeiden. Dabei kann er froh sein, wenn andere Entwickler findet, da kann er nicht auch noch Bedingungen stellen. Und das bedeutet, er kann sich keine engmaschigen Kontrollen leisten. Und das wirkt sich natürlich negativ auf die Qualität des Quelltextes aus.

Wordpress wurde von dem Entwickler Matt Mullenweg ins Leben gerufen. Er übernahm 2002 die Blog-Software b2/cafelog von Michel Valdrighi und erweiterte es zu einem neuen System, dass er Wordpress nannte. Weil Wordpress Open Source ist, haben im Verlauf der Jahre viele Programmierer mitgewirkt. Viele haben ihre eigenen PHP- oder Javascript-Bilbliotheken, sowie ihre eigenen Programmier­konventionen mitgebracht. Aufgrund des hohen Bekanntheitsgrades musste die Kompatibilität zu anderen Versionen immer beibehalten werden, was im Verlauf der Jahre zu vielen umständlichen Workarounds geführt hat. Diesbezüglich kann das System in dieselbe Schublade gesteckt werden, wie die anderen Open Source Content Management Systeme.

Zusammenfassend kann man sagen, dass Wordpress ein historisch gewachsener prozeduraler Flickentepich ist, der von einer allgemeinnützigen Organisation demokratisch verwaltet wird. Die Software besteht aus aus einem bunten Gemisch von globalen Variabeln, Funktionen und Klassen. Detaillierte Programmier-Konventionen existieren nicht, was unter anderem dazu führt, dass es redundante oder fast gleichlautende Funktionsnamen gibt. Themes oder Erweiterung können nur über die Trial & Error Methode realisiert werden, was bestimmte Anpassungen nahezu un­kalkullier­bar macht.

Der hohe Bekanntheitsgrad sorgt ausserdem dafür, dass sich Sicherheitslücken schnell herumsprechen. Und das führt dazu, dass Wordpress als sehr unsicher gilt. Man ist deshalb gezwungen, so ziemlich jedes verfügbare Update mitzumachen. Dabei ist man darauf angewiesen, dass die Kompatiblität der Plugins erhalten bleibt. Diese müssen also jedesmal entsprechend getestet werden, was unter Live-Bedingungen nur mit einer gespiegelten Zweitinstallation möglich ist.

Um es auf den Punkt zu bringen

Um ein Wordpress Projekte verbindlich kalkullieren zu können, ist ein Erfahrungswert notwendig, den man nur erhalten kann, wenn man sich fast ausschließlich mit dieser Materie beschäftigt. Wenn man das nicht tut, empfiehlt es sich, den Quelltext unangetastet zu lassen. Doch selbst dann ist die Qualität des Quelltextes so schlecht, dass es nur eine Frage der Zeit ist, bis eines Tages ein Update fehl schlägt. Wenn es soweit ist, muss man sich nach der Trial & Error Methode an das Problem herantasten, um es anschließend in mühsamer Klein­arbeit zu beheben.

Unter dem Strich kommt man zu dem Schluss, dass der Wartungs­aufwand für Wordpress Projekte in 80 von 100 Fällen unver­hältnismäßig hoch ist. Und das kann nur kompensiert werden, indem Wartungs­verträge abgeschlossen werden oder die Projekte entsprechend großzügig kalkulliert werden.

Für viele Agenturen ist diese Vorgehensweise normal, denn sie kennen es nicht anders. Aber dass es auch anders geht, beweist der Umstand, dass ich in den letzten 12 Jahren nicht einen einzigen Wartungs­vertrag abgeschlossen habe. In dieser Zeit habe ich an über 300 Internet­auftritten mitgewirkt. Hätte ich mich dabei auf Wordpress beschränkt, wären es vermutlich nur ein Bruchteil davon gewesen. Und das ist der Grund, weshalb ich es mir gut überlege, ob ich ein Wordpress Projekt annehme, oder nicht. Und so kommt es, dass ich mich in 98 von 100 Fällen gegen Wordpress entscheide.

Um es mit einer Metapher abzuschließen: wenn ich die Option habe, grabe ich meine Löcher lieber mit einem Bagger, als mit dem Spaten. Das ist weniger eine Frage des Geschmacks, als vielmehr eine Frage der Effizienz. Denn ich sehe nicht ein, wieso ich etwas mit einem Werkzeug realisieren soll, wenn ich es mit einem anderen in der Hälfte der Zeit schaffen kann und das auch noch in einer höherwertigen Qualität ohne Nach­arbeiten oder sonstigen Update-Stress fürchten zu müssen.

August 2014/jw