Gastartikel: Arbeiten an WordPress nur Notepad-Entwickler?

Eine These ist eine Behauptung, die der Autor nicht beweisen will oder kann – und so eine habe ich. Es geht im Prinzip um WordPress, aber eigentlich im weitesten Sinne um die Open-Source-Gemeinde. „Denn sie wissen nicht, was sie tun“.

WordPress 4.3 grillt den Server

Vor Kurzem ist WordPress 4.3 erschienen, das einige eher unspektakuläre Änderungen an der Oberfläche hat, dafür einige unter der Haube. Beispielsweise wollte man ein Problem mit den Schlagworten angehen, wenn es zufällig genauso heißt wie eine Kategorie. Schön! Weniger schön ist ein kleiner Bug, der sich eingeschlichen hat. Der Bug sorgt dafür, dass die Server-Last ins Unermessliche steigt. Schuld daran ist ein Cronjob, der Tags bereinigen soll. Leider gibt es bei der Entwicklung einen Fehler; der Cronjob wurde mit vertauschten Parametern aufgerufen. Das wirft keinen Fehler, sorgt aber dafür, dass die Abbruchbedingung niemals erfüllt wird – die Datenbank wird „vollgemüllt“ und der Server immer langsamer. Das Problem ließ sich eingrenzen, wenn der „Load“ stieg und stieg, obwohl man temporär sämtliche Plugins deaktivierte und ein Standard-Theme keine Fehler behobt. Der lang diskutierte Fix von Samuel Wood (Otto) im Forum brachte die Lösung. Vielen Dank dafür!

Notepad-Entwickler am Werk?

„Der beste Code-Editor ist immer noch Notepad“ – viele sogenannte Programmierer vertreten scherzhaft diese Meinung, weil Notepad dermaßen einfach gestrickt ist, dass man sich selbst um Luxus wie Code-Einrückungen und korrekte Parameter kümmern darf. Wenn der Code dennoch funktioniert, ist man ein bemitleidenswerter Nerd, aber der eigene „Skill“ ist dann offenbar „Over 9000„. Hätte der verantwortliche WordPress-Entwickler eine richtige IDE genutzt, wäre das nicht passiert, denn dank Code-Hinting hätte man nur mal auf den Bildschirm schauen müssen und die Reihenfolge der Parameter wäre klar gewesen. Bam!

Niemand hat große Projekte

In mir macht sich langsam der Verdacht breit, dass niemand von den Entwicklern seinen Code mal auf gut besuchten (und entsprechend großen) Projekten testet, sondern immer nur in der Theorie mit irgendwelchen Scripten auf nicht-reale Weise abklopft. Denn bei kleineren Seiten merkt man so etwas freilich nicht. Doch gerade bei Scripten wie WordPress, das Abermillionen Installationen zählt, ist es von oberster Dringlichkeit, dass so etwas nicht passiert, wenn man die Software für stabil erklärt. Andernfalls schadet das dem Ruf und kostet den Anwendern im schlimmsten Fall jede Menge Geld. Debuggen, langsame Seiten (die Google überhaupt nicht mag) und Benutzer, die das Weite suchen, weil die Seite nicht laden mag, sind die Folge.

WordPress kann nicht mit Performance umgehen

Dieses Problem zieht sich leider durch WordPress wie ein roter Faden. WordPress hat einen schlechten Quellcode (dafür eine herausragende Usability, immerhin) und die Software ist langsamer als sie sein müsste. Das fängt bereits bei der Datenbankklasse an. Auf Macnotes beispielsweise wurde testweise ein selbst entwickeltes Plugin integriert. Prinzip-bedingt gibt es den Fall, dass alle vorhandenen Beiträge bearbeitet werden müssen – SELECT ID, post_content FROM wp_posts WHERE post_type = 'post' AND post_status = 'publish'. In einer Schleife werden alle post_content-Zeilen angepasst und per UPDATE-Anweisung wieder gespeichert. Mit der WordPress-Datenbank-Klasse dauert das 31 Minuten. Eine halbe Stunde! Die exakt selben SQL-Abfragen hat PDO in 11 Sekunden abgefrühstückt. Aber bei WordPress diskutiert man lieber jahrelang über Sinn oder Unsinn von MySQLi und wenn PHP 5.5 dann eine Deprecated-Meldung für MySQL-Funktionen wirft, wird – aber nur dann, wenn PHP 5.5 oder neuer installiert ist! – MySQLi verwendet.

Suchfunktion – für die Tonne

Das war ein schönes Beispiel für Missmanagement bei WordPress, aber wenn man auf der Startseite 10 Beiträge abfragt und in der Beitragsansicht nur einen, merkt man das fast nicht. Aber es gibt ja noch die Suche, die ist ebenfalls hoch ineffizient. Sucht man beispielsweise in der Frontend-Suche bei Macnotes nach „iPhone„, generiert WordPress daraus folgende Suchabfrage:

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND (
((wp_posts.post_title LIKE '%iphone%') OR (wp_posts.post_content LIKE '%iphone%')))
AND (wp_posts.post_password = '')
AND wp_posts.post_type IN ('post', 'page', 'attachment', 'tablet', 'entwickler', 'event', 'game', 'plattform', 'publisher', 'cheats')
AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'closed')
ORDER BY wp_posts.post_date DESC LIMIT 0, 10

Laut phpMyAdmin dauert es 0,7 Sekunden, bis allein der Query fertig ist. Das Problem ist gleich die erste (nicht sinnlose) WHERE-Bedingung: Weder die Spalte post_title noch post_content sind mit einem Index versehen. Jetzt könnte man argumentieren, dass post_content vom Typ longtext ist und deshalb ein Index nicht möglich ist – stimmt. Aber ein FULLTEXT wäre möglich. Dafür müssen nur folgende Änderungen gemacht werden:

ALTER TABLE wp_posts ENABLE KEYS;
ALTER TABLE wp_posts ADD FULLTEXT(post_content);
ALTER TABLE wp_posts ADD FULLTEXT(post_title);

Und die Suchabfrage muss leicht geändert werden:

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND (
((MATCH(wp_posts.post_title) AGAINST ('iphone')) OR (MATCH(wp_posts.post_content) AGAINST ('iphone'))))
AND (wp_posts.post_password = '')
AND wp_posts.post_type IN ('post', 'page', 'attachment', 'tablet', 'entwickler', 'event', 'game', 'plattform', 'publisher', 'cheats')
AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'closed')
ORDER BY wp_posts.post_date DESC LIMIT 0, 10

Das Ergebnis: Die SQL-Abfrage dauerte nur noch 0,1 Sekunden, ist also siebenmal so schnell, das Ergebnis ist identisch. Herausragend.

Problem ist weit verbreitet

Leider sind derartige Probleme in der Open-Source-Gemeinde extrem weit verbreitet und nicht nur auf WordPress beschränkt. Es ist nur so, dass WordPress am Ende immer noch der beste Kompromiss aus Ressourcen bei Google und Benutzbarkeit ist.

Beispielsweise scheint ModX an manchen Stellen ebenfalls mit Notepad entwickelt worden zu sein. Dass man sich den Problemen nur bedingt annimmt, liegt mit Sicherheit auch an der geringeren Verbreitung. Bei ModX hat man, zumindest in den früheren Versionen, offenbar noch nicht allzu viel von Indexen in der Datenbank gehört. Jeder Fliegenschiss wurde in der Datenbank protokolliert und wenn man bei Google News einen schönen Treffer hatte, über mehrere Tage hinweg, wurde der Server-Load irgendwann dreistellig. Und dann ist da die Sache mit den großen Seiten – das Admin-Menü von ModX lädt alle verfügbaren Seiten per JavaScript in eine Navigation. Das mag ja ganz praktisch sein, wenn man nur 10 statische Seiten hat, aber bei mehreren Tausend Newsartikeln, kann man sich schon mal einen Kaffee aufkochen, während das Backend lädt.

„Dann verbessere doch den Code, es ist Open Source!“

Ja, das würde man gerne. Das Problem ist, dass die meisten der anderen Entwickler das Problem nicht sehen, weil sie anscheinend nicht mit gut besuchten Seiten zu tun haben. Diese haben nämlich eigene Programmierer, die dann entweder neue Hardware kaufen dürfen oder den Code bis zur Unkenntlichkeit verändern, damit die Software läuft. Versucht man dann, wie oben beim Vorschlag, PDO zu verwenden, einen validen Punkt anzusprechen, stößt man auf taube Ohren. Es könnte ja 1-2 Plugins geben, die sich nicht an die Coding-Richtlinien halten und davon kaputt gehen. Das ist wichtiger, als dass man selbst mit gutem Beispiel vorangeht und einen sauberen, performanten Code verbreitet. My Ass!

„Dann mach halt einen Fork, es ist immer noch Open Source!“

Forken ist, besonders wegen kleinerer Änderungen, ziemlich albern. Beispielsweise macht es nicht allzu viel Sinn, die Usability des Backends von WordPress neu zu erfinden, weil die recht gut ist. Wenn es nur wenige Änderungen sind, die man selbst gerne im Core-Paket hätte, ist es einfach sinnlos, einen Fork anzufertigen, weil man dann bis ans Ende aller Tage dem Original hinterherläuft, um die Änderungen in den eigenen Fork zurückzuportieren. Und außerdem ist Meckern ohnehin attraktiver als selbst Hand anzulegen, das wissen wir ja alle.

Ähnliche Nachrichten