WordPress: Eine Hölle aus alten Versionen

Wozu führen massenhaft unsichere WordPress-Installationen in einem Web, das von der organisierten Internet-Kriminalität der Zehner Jahre geprägt ist? Zu einem Botnetz aus gepwnten WordPress-Installationen, und zwar auch bei namhaften Institutionen.

Problematisch sei, so das Anti-Botnetz-Beratungszentrum, dass momentan nur rund 18 Prozent der Top 1 Million WordPress-Blogs die aktuelle Version nutzen

Ja, das ist problematisch.

Es ist allerdings einen Blick wert, zu analysieren, woher dieses Problem kommt: Warum kommen Menschen auf die Idee, einer im Dashbord nach jedem Login sichtbaren Aufforderung zu einem Upgrade ihrer WordPress-Installation nicht zu folgen? Obwohl dieser Upgrade in den gegenwärtigen Versionen so einfach wie ein Klick und die anschließende Eingabe eines FTP- oder SFTP-Passwortes ist?

Meiner Meinung nach liegt diese Scheu vieler Nutzer vor Upgrades – die sich bemerkenswerterweise ausgerechnet unter den beliebtesten und damit auch für ihre Betreiber wichtigen Blogs so deutlich zeigt, dass in fast vier Fünfteln der Installationen ein veralteter Versionsstand vorliegt – auch an der Vorgehensweise der WordPress-Entwickler: Zwar wird das Kernsystem von WordPress mit jeder Version aufgeblähter, aber die große Mehrzahl der Features ist aus Nutzersicht schlicht nutzlos, so dass es zu dem Urteil kommt, dass der Upgrade selbst nutzlos ist. Behobene sicherheitskritische Fehler werden schließlich von keinem »normalen« Benutzer bemerkt; die Auflistungen von bearbeiteten Tickets im Bugtracker von WordPress werden nur von technisch interessierteren Menschen überflogen. Was als Eindruck beim durchschnittlich denkenden Nutzer ohne technische Ambitionen verbleibt, ist »Dieses Upgrade kann ich mir schenken, es bringt mir keinen Vorteil, und wenn ich es mir erspare, kann es auch nicht schiefgehen und mir eine Downtime und eventuell stundenlange Nacharbeit bescheren«.

Denn ein WordPress-Upgrade kann schiefgehen. Das liegt daran, dass beim Upgrade sehr häufig Probleme mit installierten Plugins auftreten, die mit der neuen Version nicht mehr richtig arbeiten, gar nicht mehr arbeiten oder gar so schwere Fehler verursachen, dass eine leere weiße Seite (oder auf schlechten PHP-Installationen: eine PHP-Fehlermeldung, die Details der Installation verrät) an die Stelle des Blogs tritt.

Natürlich wurden die Plugins nicht zum Vergnügen verbaut, sondern weil sie Funktionen in ein WordPress-Blog einbauen, die im Internetprojekt erwünscht oder erforderlich sind – und es sind ja gerade die »großen Blogs«, welche in einer solchen, oben nach Heise zitierten Liste von »Top-Blogs« aufscheinen, die eine erhebliche »Verbastelung« durch Plugins haben.

Wer für ein solches »verbasteltes« Blog technisch verantwortlich ist und schon seine WordPress-Erfahrungen gesammelt hat – Erfahrung ist übrigens immer die Summe von Misserfolgen – lernte im Laufe der Jahre von WordPress-Konditionierung folgende Vorgehensweise bei Hinweisen auf eine neue WordPress-Version:

1. Ein Sicherheitsupgrade der laufenden Version? Das ist gut und wichtig, das mache ich mal schnell, ich will ja kein gehacktes Blog haben…
2. Oh, uh, oh, eine neue WordPress-Version. Das gibt oft Kopfschmerzen. Das mache ich heute lieber nicht mehr, dafür bräuchte ich eigentlich ein Testsystem mit gleichem Installationsstand, das ich aber nie mit der gleichen Hingabe gepflegt habe wie die eigentliche Blog-Site. Ich werde Arbeit haben. Ich werde möglicherweise viel Arbeit haben…

Der zweite Punkt wird durch eine weitere, ebenfalls stark demotivierende Erfahrung ergänzt: Die neue Version, die schwere Probleme bereiten kann, ist zunächst objektiv sinnlos. Die aktuelle Beglückungsidee der WordPress-Entwickler enthält in der Regel keine benötigten oder gewünschten zusätzlichen Features, sondern zusätzlichen Bloat ohne Nutzen. Kaum jemand, der eine Site mit WordPress betrieb, benötigte oder wünschte sich etwa…

• …einen im Kern integrierten Drag-and-Drop-Uploader;
• …eine im Kern integrierte »Schlagwortverwaltung«, die in ihrer ersten Version ohne jede Verwaltungsfunktion daher kam und deutlich schlechter implementiert war als entsprechende, sehr ausgereifte Plugins;
• …eine integrierte Bildverarbeitung mit minimaler Funktionalität;
• …eine Admin-Bar, die sich für angemeldete Benutzer über das Blog legt und sich nicht gut mit einigen Themens verträgt;
• …eine voll aufgeplusterte Versionsverwaltung für Blogbeiträge;
• …unausgereifte GUI-Experimente mit dem Dashboard, die die tägliche Bedienung erschwerten (vor allem bei den 2.5er- und folgenden Versionen, lange ists her, aber es tat nachhaltig weh);
• …eine von großen CMS abgeschaute Menüverwaltung zum Erstellen einer Navigation; oder
• …ein im Kern verbautes, aus Nutzersicht weitgehend unsichtbares, voll aufgeplustertes hierarchisches Taxonomie-System, um damit die relativ einfachen Konzepte der Schlagwörter und Kategorien zu implementieren.

Diese Liste ist natürlich fragmentarisch. Es gab so viele Anreicherungen des WordPress-Kernsystems von zweifelhaftem Nutzen, dass die Erstellung einer vollständigen Liste mit viel Arbeit verbunden wäre.

Aber schon diese kleine Auflistung zeigt, dass ein Upgrade in vielen Fällen keine Verbesserung aus Nutzersicht bedeutete, aber sehr wohl große Probleme bereiteten konnte – zuweilen sogar so große Probleme, dass ein Nutzer ohne technische Kenntnisse keine Chance hatte, diese Probleme selbstständig zu lösen. Wer wird da einen Upgrade machen, wenn die alte Version noch läuft?

Für den Versionsstand der WordPress-Installationen sind die WordPress-Entwickler unter Matt Mullenweg mit ihren oft schwer nachvollziehbaren strategischen Entscheidungen also ein Stück weit mitverantwortlich. Natürlich kann man sich auf den Standpunkt stellen, dass ein Mensch ohne technische Kenntnisse keine eigenverantwortlich betriebene Website haben sollte, und dieser Standpunkt hat durchaus seine berechtigten Anteile. Man kann sich aber auch auf den – in meinen Augen angemesseneren – Standpunkt stellen, dass Software dafür da ist, das Potenzial der Technik einem möglichst großen Nutzerkreis aufzuschließen und zugänglich zu machen, und dass die Technik sinnvollerweise nur dafür da ist, dass Menschen besser und einfacher das tun können, was sie tun möchten. Diese Dinge sind kein technikverliebter Selbstzweck.

Bloggen bedeutet: Einen neuen Post schreiben. Darin ist nichts strukturell Komplexes. Der Nutzer hat ein Feld zum Tippen und eine Schaltfläche zum Veröffentlichen, ferner kann er ein paar Meta-Angaben (Schlagworte, Kategorien, Zeitpunkt der Veröffentlichung) machen. Ein Blogsystem hat für diesen einen, wichtigsten Anwendungsfall eine möglichst gute Benutzerschnittstelle zu bieten. Alles andere ist Kür.

Meiner Meinung nach ist die Idee eines »fetten«, möglichst universellen Kerns ein Design-Fehler für eine Blogsoftware.

WordPress enthält ein Plugin-System, das es möglich macht, gewünschte Funktionen nachzurüsten. Das ist eine gute Idee, die von den Entwicklern bemerkenswert wenig ausgearbeitet wurde. Der Weg, ein reines Blogsystem als Kern zu entwickeln, das mit einem Satz von mitgepflegten Plugins um häufig gewünschte, aber prinzipiell optionale Funktionen erweitert wird (hierzu gehören etwa Kommentare, Pingbacks, XMLRPC, Schlagwörter und einige der weiter oben beschriebenen Features, die zurzeit zum Kernsystem gehören, aber vieles mehr), würde zu einer robusteren Software führen – die überdem nur den »Ballast« bei jedem Seitenaufruf mitschleppt, der explizit gewünscht ist. Ein solches Kernsystem einer Blogsoftware brauchte nur sehr selten eine komplett neue Version, wenn es erst einmal »fertig« wäre, und es wäre durch die Auftrennung auch überschaubarer. Was immer noch nötig wäre, das wären Sicherheits-Updates.

Die von Entwicklern mitgepflegten Kern-Plugins bedürften einer klaren Kennzeichnung. Diese bedeutet aus Nutzersicht: Wenn du dieses Plugin benutzt, dann versprechen wir dir, dass du so wie keine Probleme mit diesem Plugin haben wirst. Selbstverständlich sollten auch die Standard-Themes für diese Plugins vorbereitet sein, denn kein »gewöhnlicher Nur-Blogger« fühlt sich besonders wohl, wenn er in für ihn unverständlichen PHP-Quelltexten ein paar für ihn genau so unverständliche PHP-Anweisungen einpflegt.

Aber natürlich könnte dann nicht alle paar Monate eine neue Version presseerklärt werden. Solange die WordPress-Entwickler den »Fortschritt« darin sehen, dass neue Versionen veröffentlicht werden und nicht darin, dass sie kontinuierlich eine Software entwickeln, die ihren Nutzern (im Idealfall: immer besser) dient und der die Nutzer auch bei jedem Update vertrauen können, so lange wird es auch so bleiben, dass etliche WordPress-Installationen veraltet sind – und dass die Vorstellung einer neuen Version bei vielen Menschen in erster Linie Widerwillen und Kopfschmerz auslöst.

Einmal ganz davon abgesehen, dass individuelle Installationen, die nur die benötigten Funktionen implementierten, in vielen Fällen auch dazu führten, dass kein relativ aufwändiges Plugin für das Caching verwendet werden muss, um das langsame »Moppelchen« WordPress auf eine einigermaßen erträgliche Geschwindigkeit zu bringen. Ein ausgereiftes Caching-Plugin gehört übrigens meiner Meinung nach unbedingt zu jenen Kern-Plugins, die mitgepflegt werden müssen – ich weiß aus eigener Erfahrung, dass ansonsten recht bescheidene 3.500 Leser am Tag bereits hinreichen können, um ein WordPress-Blog so in die Knie zu zwingen, dass es zu Stoßzeiten nur noch kriecht.

Vielleicht entstünde dann sogar endlich einmal die erforderliche Luft, um ein paar schwere WordPress-Designfehler der Vergangenheit zu behandeln und eine neue Version zu machen, die wirklich etwas erneuert. Ein großes Problem von WordPress ist zum Beispiel die fehlende Trennung von Implementation und Darstellung in den Themes. Diese Schwäche zeigt sich am deutlichsten bei den Blogs, die auf WordPress.com gehostet werden; dort kann den Anwendern nicht die (gern kostenpflichtige) Möglichkeit geboten werden, ihre eigenen Themes zu machen, sie müssen stattdessen aus einem angebotenen Repertoire vorhandener Themes eines auswählen, das ihren Vorstellungen nahe kommt und können bei Bedarf noch ein paar Dollar pro Jahr dafür bezahlen, die CSS für dieses Theme anzupassen. Ansonsten erhielten sie nämlich die Möglichkeit, beliebigen PHP-Code auf den Servern von WordPress.com auszuführen, was ein großes Sicherheitsrisiko wäre. Ein solches Teilprojekt innerhalb der WordPress-Entwicklung wäre zwar eine Riesenaufgabe, die sowohl den Kern als auch sämtliche derzeit existierenden Themes beträfe, aber es wäre lohnend – zumal dann auch niemanden mehr »freie« Malware-verseuchte Themes für WordPress oder für von WordPress abgeleitete Projekte untergejubelt werden könnten.

Aber ich fange gerade an, zu träumen… 🙁