Kommentar: 2. September 2015,

Gastartikel: Arbeiten an WordPress nur Notepad-Entwickler?

WordPress
Wordpress - Wallpaper

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.

Artikel bewerten

Ähnliche Beiträge

Nähkästchen #18, das letzte Wahrscheinlich das letze Nähkästchen lautet auf die Nummer 18. Das letzte deshalb, weil mein Abschied bei Macnotes sich anbahnt und ich nicht davon au...
Firefox OS sagt Lebewohl, endlich Firefox OS gibt es nicht mehr. Mozilla hat einen Strich unter das Projekt gemacht. Folglich werden Smartphones mit Firefox OS zu Sammlerstücken und de...
iPhone-Klage: Brite erfindet neues Geschäftsmodell... Ich schlage vor, wir überlegen uns ernsthaft, ob unser iPhone kaputt ist. Wir sollten zu dem Ergebnis kommen, dass es kaputt ist, und es dann zur Repa...
Keine News mehr verpassen! Unsere App für iOS und Android mit praktischer Push-Funktion.






Zuletzt kommentiert



 10 Kommentar(e) bisher

  •  DaSch (3. September 2015)

    Ich vermute das Problem ist zum großen Teil auch der Nutzung von Skript-Sprachen wie PHP geschuldet!

  •  Stefan Keller (3. September 2015)

    Die langsamen SQL-Queries werden durch PHP aber nur durchgereicht und sind in der Datenbank langsam. Die genannten Probleme sind unabhängig von der Programmiersprache – vertauschte Parameter (so sie logisch sinnvoll wären) kannst du auch in anderen Sprachen fabrizieren.

  •  Uwe (3. September 2015)

    Der Bericht bringt es schön auf den Punkt. Wobei ich denke, das eines der Probleme die gesellschaftliche Altersstruktur der Open-Source-Szene ist. Der Anteil an älteren, erfahrenen Leuten ist zu gering. Und gerade diese Leute haben dann auch noch die Lebenserfahrung um solchen unfruchtbaren Diskussionen aus dem Weg zu gehen…

    just my 2 cents

    LG Uwe

  •  Luke (3. September 2015)

    Ich glaube nicht, dass es ein primäres PHP-Problem ist. PHP entwickelt sich stetisch weiter und es gibt durchaus Möglichkeiten performante Systeme mit PHP zu schreiben.

    Der Artikel bringt vieles gut auf den Punkt.

    Nur: Was sind die Alternativen?

  •  Akroii (3. September 2015)

    @Luke
    sieh dir doch mal Contao an ;)

  •  Alfred E. Neumann (3. September 2015)

    Nennt mir bitte eine! IDE, die man auch dann benutzen kann, wenn man nicht extrem masochistisch veranlagt ist! Und kommt jetzt bitte nicht mit Java basierten IDEs wie Eclipse oder mit Visual Studio um die Ecke.

    Das Problem aller! mir bekannten IDEs ist, daß diese mit Features überladen und i.d.R. extrem schwerfällig sind (insbesondere Eclipse und Konsorten).

    Mal davon abgesehen ist die Benutzung einer IDE sicher kein Garant für hochwertigen und fehlerfreien Code. Dafür gibt es Tests und genügend Tools, mit denen man das sicherstellen kann. Genau so verhält es sich auch mit Datenbankabfragen. Ich kann mit einem einfachen Editor hochperformante Datenbankabfragen schreiben, wenn ich weiß was ich tue, oder aber mit einer IDE den größten Müll verzapfen, wenn ich keine Ahnung hab.

    „Hätte der verantwortliche WordPress-Entwickler eine richtige IDE genutzt, wäre das nicht passiert [..]“. Nein! Der Satz muss heißen: Hätte der verantwortliche WordPress-Entwickler auch Tests für seinen Code geschrieben, wäre das nicht passiert, da der entsprechende Test dann eben fehlschlägt. Das setzt natürlich eine entsprechende Projektstruktur und sowie einen entsprechenden Workflow voraus. Beides kann ich bei WordPress nicht erkennen.

    Ansonsten gebe ich euch zu einigen oben genannten Punkten absolut Recht. Insbesondere, was einige dieser fragwürdigen Diskussionen wie PDO vs mysqli und andere angeht. Einige der Core-Entwickler scheinen hier wirklich extrem unflexibel.

    Das derartige Probleme in der Open-Source-Gemeinde extrem weit verbreitet sind, sehe ich allerdings nicht so.

    @Uwe
    Ich glaube es ist ein vielen Bereichen genau anders herum. Meiner Erfahrung nach sind es eher die älteren, erfahrenen Entwickler, die sich mit (teils) gravierenden Änderungen/Neuerungen schwer tun (ab und an gehts mir selbst so), vor allem wenn es um Rückwärtskompatibilität geht.

  •  John Appleseed (3. September 2015)

    @Alfred E. Neumann
    Xcode und Coda. Sind schon zwei. Allerdings nicht für Windows verfügbar.
    Außerdem bieten IDEs bereits die Möglichkeit, Test-Units einzubinden, da beißt sich die Katze in den Schwanz.

    Das Problem ist leider auch, dass es anscheinend viele Fanboys gibt oder Leute, die wenig Ahnung haben und dennoch unterrichten. Beispielsweise meinte mein Java-Professor, dass es ja überhaupt nicht mehr stimmt, dass Java (und die darin programmierte Software) lahm und ressourcen-intensiv ist. Das sei früher mal so gewesen, aber das habe sich stark verbessert. Nun, dann möchte ich nicht wissen, wie langsam Java „früher“ mal war, wenn es jetzt „schnell“ ist.

    Bei den SQL-Abfragen muss ein Missverständnis vorliegen. Ich meinte nicht, dass man mit Notepad keine performanten Abfragen schreiben kann. Der Vorwurf war, speziell bei der Suchfunktion, ein anderer. Da hilft natürlich auch eine IDE nicht weiter, denn die weiß nicht, wie die Datenbankstruktur aussieht – der Slow Query Log von MySQL selbst hingegen weiß es. Aber dafür müsste man wissen, was man da überhaupt macht.

    Die Diskussion MySQL vs. MySQLi kam schon mindestens 5 Jahre zu spät. Aber die Diskussion wird noch lächerlicher, da man MySQL vs. PDO diskutierte und dann die „erlösende“ Deprecated-Meldung MySQLi als Kompromiss hervorbrachte. Und ja, ich habe den Eindruck, dass es in der Open-Source-Gemeinde Gang und Gäbe ist, dass wichtige Diskussionen ewig lang geführt werden, aber am Ende zu nichts führen. Das erlebe ich in der Tat sehr oft, weil jeder irgendeine Meinung hat und am Ende siegt die Angst, dass etwas kaputt gehen kann – bis etwas kaputt geht.

    Bei derartigen Debatten auf GitHub, in Trac oder sonstigen Feedback-/Bugtracker-Systemen sieht man leider nur selten, wie alt die Personen sind, die etwas zu sagen haben und die, die sich für den Fortschritt einsetzen. Erfahrung zu messen ist bald noch schwieriger. Ich möchte deshalb gar nicht auf dem Alter herumreiten. Vermutlich gibt es sowohl bei Alt als auch bei Jung Vertreter, die eher „Never change a running system“ oder „Wer nicht mit der Zeit geht, geht mit der Zeit“ vertreten. Nur wenn man zwei Jahre darüber diskutiert, ob es sinnvoll wäre, das Unaufhaltsame mal umzusetzen und sich dann für etwas entscheidet, was am Ende auch nur ein Auslaufmodell ist… ja, also dann hört es bei mir auf.

  •  Alexander Trust (3. September 2015)

    @Alfred: Ich nutze PHPStorm und RubyMine von JetBrains (https://www.jetbrains.com/). Beide basieren auch auf Java, sind aber halt spezialisiert. Ich kann mich nicht beschweren, gerade wenn ich eigene Funktionen und Klassen schreibe und diese projektweit erkannt und samt eigenen Parameter autovervollständigt werden. Sie bieten dutzende anderer Funktionen on top. Natürlich ist es manchmal ein bisschen umständlicher, sich in eine Software einzuarbeiten, aber wenn man das einmal gemacht hat, kann man bei der täglichen Arbeit sehr viel Zeit sparen. Es lohnt sich kaum für Leute, die nur ab und zu etwas an ihrem Template frickeln, aber wer schon eigenständig WordPress oder andere CMS um Funktionen erweitert, der kann davon profitieren.

  •  Matthias (5. September 2015)

    Guter Artikel! Klar könnte man sich in die Entwicklung einbringen, aber mir macht der unstrukturierte und „global“-Code auch einfach null Spaß…

    Im WP-Core ist sehr viel mehr schlecht, als hier beschrieben ist. OOP sucht man vergebens, findet dafür jede Menge anderen Unsinn.

    Ich habe mir vorgenommen, keine weiteren WP-Seiten mehr aufzusetzen. Suche aktuell nach einer anständigen Alternative…

    PS: phpStorm ist eine top IDE :)

  •  Pat (5. September 2015)

    Als IDE kann auch ich PHPStorm bzw. für andere Sprachen die anderen Produkte von Jetbrains empfehlen!

    Recht hast du mit deinem Artikel. WordPress ist unter der Haube „leider“ der letzte Dreck. Da wirds einem übel. Das System ist programmiert wie man vor 20 Jahren PHP programmiert hat.

    Ich hab einmal gelesen dass der Chef von WordPress meinte, das in jedem Major Relaise mindestens 60% des Codes neu geschrieben wird. Mag sich gut anhören, ist es aber nicht. Ein gescheites CMS/System hat ein ordentliches Framework dahinter welche das überflüssig machen. WordPress kann davon nur Träumen. Dort sucht man nach ordentlichen OOP vergeblich. Auch fehlt jegliche Art von Design Patterns (MVC etc.) und dergleichen! Das ist einer der Gründe warum es auch so anfällig auf Sicherheitslücken ist. Weil jedes PHP Script Kiddie meint damit ach so tolle Erweiterungen zu schreiben. Leider haben diese dann garkeine Ahnung von ordentlicher Architektur. Und WordPress gibt hier keine Funktionalität mit um zumindest die banalsten Fehler und Sicherheitslücken abzufangen.

    Das einzige was man über WordPress positives sagen kann ist die gute UI im Adminbereich. Alles andere ist Schrott und wird von Leuten gehyped die NULL Ahnung von der Materie haben.

    Und wer das Gegenteil behaupten will, dem sag ich gleich Vorweg: Lern erstmal nach den heutigen Regeln und Vorgehensweise zu programmieren. Und dann mach den Mund auf.


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>