Sonstiges

Coding-Analyse von WordPress und Plugins

Björn hat sich auf seinem Victory’s Blog mit dem Thema Perfomance der Datenbankabfragen von WordPress und WordPress Plugins beschäftigt. Er kommt zu einigen kritischen Punkten, die sehr ungeschickt programmiert wurden. Siehe WordPress ist inperformant

Über den Autor

Robert Basic

Robert Basic ist Namensgeber und Gründer von BASIC thinking und hat die Seite 2009 abgegeben. Von 2004 bis 2009 hat er über 12.000 Artikel hier veröffentlicht.

7 Kommentare

  • aber selbstverständlich! Super Analyse und ich hoffe, hilfreich für Interessierte. Denk daran, Matt Mullenweg oder einen der WP Developer über diese Fundstellen zu informieren. Möglicherweise haben die einen Grund gehabt, sich für diesen Weg zu entscheiden, zB Kommentarabfragen eben nicht in ein einzelnen Statement vor dem Loop zu packen.

  • WordPress selbst ist m.E. da auch noch nicht so weit, z.B. unter WP Codex: Writing a Plugin steht folgendes:

    Database Tips – Reading is Cheap, Writing is Expensive

    M.E. sollte allein schon im Codex für die Plugin-Entwickler mehr sensibilisiert werden. Hier fehlen einfach Tipps im Hinblick auf die Performance.
    Letztendlich sollte man IMHO die in den letzten Tagen gewonnenen Erfahrungen unbedingt an die WP-Verantwortlichen weitertragen. Ich bin mir noch nicht sicher, in welcher Form man das am besten macht; ein einzelner WP-Forumsbeitrag oder eine Email kann leicht übersehen werden. Vielleicht sollte man die festgestellten Punkte in einem Weblog-Artikel in Englisch sachlich und fundiert auf den Punkt bringen und dann den PermaLink entsprechend platzieren.

  • Ja stimmt, das wäre sicher eine gute Idee. Müsste noch jmd gutes English beherrschen 😉

    Dann müsste man Punkte zusammenfassen: Das bei mir erwähnte anfängliche Auslesen sollte das Auslesen im loop ersetzten!

  • @Björn,
    ich bin gerne bereit am Erstellen eines solchen Artikels mitzuarbeiten (auch wenn mein Englisch sicherlich nicht perfekt ist), also was Aufsetzen oder Korrekturlesen; sollte dann aber an geeigneter Stelle gepostet werden, z.B. mein Blog mit (noch 🙂 PageRank 0 wäre da IMHO völlig ungeeignet.
    In Robert’s Blog wäre ein solcher Artikel sicherlich sehr gut aufgehoben 😉 Robert, was hältst Du von der Sache?

  • Michael, würde den Entwicklern ne Mail zukommen lassen, indem auf die konkreten Knackpunkte stichwortartig hingewiesen wird. Auf dem Blog hier bringt der PageRank dazu eigentlich wenig, es geht ja weniger um Öffentlichkeit als um Verbesserung der SW. Ob Plugin oder WP selbst.

    Geht es mehr um allgemeine Punkte, wie zB die abstrakte Herangehensweise an ein WP Plugin unter den Gesichtspunkten Stabilität, Performance, Robustheit etc…. würde ich das ins Forum unter wordpress.org platzieren oder aber denjenigen suchen, der letztens den WP PLugin Wettbewerb gemacht hatte. Eventuell wäre sogar ein Vorschlag für ein Metaplugin denkbar, das die häufigsten Abfragen/Funktionen enthält und standardisiert zur Verfügung stellt, um diese nicht mehr selbst nachmachen zu müssen. Was man dann mit den Daten macht, ist wieder Sache des eigenen Plugins. Eigentlich nix anderes als ne Klasse mit ein paar methods&properties halt.

    Und das mit dem englisch, kann ich ja mithelfen, kanns zwar auch nicht, aber tue mich nicht da so schämen drum .-)))

  • Das mit dem Pagerank war mehr gemeint, um nicht rüberzukommen à la „kaum 2 Tage WordPress in Betrieb und schon meckern“ 😉
    Aber Du schon Recht. Hmm, und eigentlich gehört das schon auch ins WP-Forum.
    Es wäre statt einem „Metaplugin“ natürlich noch schöner, wenn das direkt in WP integriert wäre.
    D.h. z.B. 10-20 häufigst benutzte Queries. Das Ergebnis holt man sich im Plugin xy in eine Variable, z.B. $myvar = get_query_17(). Im Code von get_query_17() steht dann

    if (not isset($query17_result)) {
    // Query wurde noch nicht ausgeführt,
    // also machen wir es jetzt...
    ...
    ...
    } else {
    return $query17_result;
    }

    Und im Codex müsste das dann wirklich Noob-sicher beschrieben sein, mit einigen Beispielen.