Erste Screenshots vom WordPress 3.2-Dashboard

5. Mai 2011, 08:05

Für WordPress 3.2 wird das Dashboard ein wenig aufgefrischt. Verschwunden sind die vielen abgerundeten Ecken, statt dessen hat das Menü deutlichere Kanten und eine solide Trennung zwischen den Funktionsgruppen für die Inhalte einerseits und die Präsentation und Technik des Blog andererseits.

WordPress 3.2 - Dashboard

WordPress 3.2 - Neuer Artikel

Mir gefällt die neue Optik.

Kommentare [3]

Warum die deutsche Sprachdatei WordPress um 44 Prozent langsamer macht

13. April 2011, 22:32

Jeder deutschsprachige WordPress-Anwender kennt vermutlich diese kurze PHP-Zeile:

define ('WPLANG', 'de_DE');

Mit dieser einen Zeile wird WordPress deutschsprachig – und jeder Seitenaufruf rund 44 Prozent langsamer.

Im Folgenden zeige ich, warum dieser Performance-Einbruch eintritt und welche Möglichkeiten existieren, dem entgegenzuwirken.

Warum kann WordPress Deutsch?

WordPress verwendet im gesamten Code englische Originaltexte. Zur Lokalisierung der Software in anderen Sprachen muss WordPress Übersetzungen aus zusätzlichen Dateien im verbreiteten PO-Format einlesen. Die deutschsprachige Lokalisierung von WordPress 3.1.x enthält fast 3.200 Textschnippsel für den WordPress-Kern und 87 Übersetzungen für das Theme “TwentyTen”. Je nach Konfiguration kommen dann noch lokalisierte Texte der aktiven Plugins dazu.

Was kostet Zeit?

Ziemlich früh bei jedem Request wird innerhalb von wp-settings.php die Funktion load_default_textdomain() aufgerufen.

Über ein paar weitere Aufrufebenen erreicht WordPress dann import_from_reader(), die tausende kurzer Textschnippsel aus der Sprachdatei des WP-Cores einliest. Wenig später ruft das Theme “TwentyTen” über den Wrapper load_theme_textdomain() ein zweites Mal import_from_reader() auf, um die Übersetzungen der Theme-Texte zu laden.

Die lokalisierten Texte werden für jeden Aufruf der öffentlichen Website, bei jeder Aktion im Backend, bei jedem AJAX-Request und bei der Generierung der XML-Feeds geladen. load_default_textdomain() verbraucht nach meinen Messungen etwa 30 bis über 50 Prozent der gesamten Zeit, die für die Bearbeitung eines Requests nötig ist.

Zusammengefasst heißt das: Ein deutschsprachiges Blog ist für menschliche Besucher, Googlebot und Administratoren wesentlich langsamer als das exakt gleiche Blog auf einem englischen WordPress.

Messmethode

Zur Auswertung der Laufzeit-Unterschiede zwischen der deutsch- und der englischsprachigen Variante habe ich eine lokale WordPress-Installation mit Xdebug vermessen und die so gewonnenen Profiling-Daten für folgende drei Requestrouten mit webgrind visualisiert:

  1. Darstellung von zehn einfachen Posts auf der Blog-Homepage mit dem Standardtheme “TwentyTen”
  2. Aufruf der Dashboard-Übersicht im Backend
  3. Darstellung des RSS-Feeds

Der Testaufbau bestand aus:

  • WordPress 3.2-bleeding r17633
  • Theme “TwentyTen” 1.1
  • Keine aktiven Plugins
  • Lokaler Webserver ohne Last
  • Apache 2.2.9
  • PHP 5.2.6
  • MySQL 5.0.67
  • Xdebug 2.1.1
  • webgrind 1.1
  • Windows 7 SP1

Messergebnisse

Die Zeit, die WordPress benötigt, um einen einzelnen Request zu erfüllen, variiert je nach Route (Frontend, Backend, RSS). In jedem Fall verschlechtert der Wechsel auf die deutsche Sprachdatei die Geschwindigkeit um zweistellige Prozentsätze.

Für die Darstellung der Frontpage mit zehn Blogbeiträgen benötigt die deutsche Fassung fast doppelt so lange wie das englische Pendant, das Backend wird um etwa ein Drittel gebremst und die RSS-Feeds werden über 60% langsamer erzeugt.

Der Webgrind-Report liefert die Laufzeiten jeder einzelnen Funktion, die WordPress zur Generierung der Frontpage aufruft. Sehr schön sieht man hier, dass MO->make_entry() für jedes einzelne Textschnippsel ein Mal aufgerufen wird. 3.273 übersetzte Texte werden in 618 ms geladen.

Webgrind-Analyse der Laufzeiten für das WP-Frontend in Deutsch

Man erkennt deutlich, dass gerade die Lokalisierungsfunktionen aus der POMO-Bibliothek den Löwenanteil der Zeit verbrauchen.

Mit MO->import_from_reader, MO->make_entry, Translation_Entry->key und POMO_REader->substr sind vier der fünf zeitaufwändigsten Funktionen bei jedem Seitenaufruf für die deutsche Übersetzung nötig. Es gilt ein annähernd linearer Zusammenhang: Je mehr übersetzte Texte, desto höher der Zeitbedarf.

Der selbe Ablauf in der englischsprachigen Variante sieht zum Vergleich so aus:

Webgrind-Analyse der Laufzeiten für das WP-Frontend in Englisch

Ein ähnliches Verhältnis ergibt sich auch für das Backend1 und Feeds2.

Die Messung eines Profiling-Durchlaufs auf meinem Testsystem ergab diese in weiteren Durchläufen recht gut reproduzierbaren Laufzeiten:

Route Laufzeit [en] Laufzeit [de] Relative Leistung [de]
Frontend 2343 ms 4327 ms 56%
Backend 3003 ms 4283 ms 70%
RSS-Feed 1129 ms 2952 ms 38%

Diese Zahlen sollte man auf jeden Fall mit ein wenig kritischer Distanz werten: Ich habe Messungen auf einem einzigen System durchgeführt und auf einem zweiten Rechner auf Plausibilität geprüft. Ergebnisse mit Webspace auf anderen Betriebssystemen oder Dateisystemen können abweichen, und ich würde sehr gerne Zahlen von Apple- oder Linux-Systemen zum Vergleich sehen. Trotzdem glaube ich, dass das Lokalisierungspackage in WordPress einen merklichen Anteil an der Performance einer WordPress-Site hat.

In der grafischen Darstellung wird deutlich, wie eklatant der Leistungseinbruch der deutschen Fassung ausfällt:

Leistungsvergleich [en] vs. [de]

Verbesserungspotential

Was kann man tun, um diesen Klotz am Bein los zu werden? Leider habe ich dazu keine ideale Lösung, sondern nur ein paar Denkansätze:

Ein Frontend-Cache ist immer nützlich und hilft auch hier. Die negativen Auswirkungen der Lokalisierung im Backend lindert ein Cache aber nicht.

Eine weitere Möglichkeit wäre, auf die deutsche Sprachdatei komplett zu verzichten. Im Backend findet man sich eventuell auch auf Englisch zurecht, und für das Frontend setzt man einfach ein Theme ein, dass auch ohne Lokalisierung Deutsch spricht.

Drittens könne man einen Vorteil aus der Tatsache ziehen, dass der Leistungseinbruch mit der Zahl der übersetzten Texte zusammenhängt, und eine auf das Wesentliche verkürzte deutsche Sprachdatei einsetzen. Ein radikaler Löschkreuzzug in der Sprachdatei, dem ein paar hundert Hilfetexte oder unbenutzte Texte für WP-Multisite zum Opfer fallen, ist mit Hilfe von Poedit nicht schwierig. Die Ladezeit sinkt mit jedem entfernten Eintrag in der Sprachdatei um etwa 0,3 Promille.

Weitere Verbesserungen erfordern, dass seitens der WordPress-Programmierer an der Optimierung der POMO-Bibliothek selbst gearbeitet wird und zum Beispiel persistente Caches für die translation entries genutzt werden. Das Trac-Ticket dafür gibt es schon

Fußnoten

1 Profilingdaten für das Backend in Englisch und Deutsch.

2 Profilingdaten für den RSS-Feed in Englisch und Deutsch.

Kommentare [17]

Exploit Scanner: Hashwerte fürs deutsche WordPress

30. Dezember 2010, 20:27

Das Plugin Exploit Scanner hat ja aus aktuellem Anlass trotz der Feiertage wohl ein paar Downloads mehr als üblich erlebt. Wer versucht, dieses Plugin in einer deutschsprachigen WordPress-Variante einzusetzen, wird gleich zum Einstieg damit überrascht, dass sieben von 707 Dateien des WordPress-Cores verändert wurden:

  • wp-admin/setup-config.php
  • wp-config-sample.php
  • wp-includes/functions.php
  • wp-includes/load.php
  • wp-includes/version.php
  • wp-includes/wp-db.php
  • wp-load.php

Die Meldung “Modified core file” sollte eigentlich die Alarmglocken klingeln lassen.

WordPress Exploit Scanner: Modified core file

Aber immer mit der Ruhe: Die angemeckerten sieben Dateien sind absichtlich gegenüber den Originalen verändert, weil sie nicht über die Sprachdatei ins Deutsche übersetzbare Texte enthalten. Davon weiss leider das Plugin nichts – aber es ist lernfähig: Die Prüfung auf den Originalzustand läuft über eine MD5-Prüfsumme, die im Plugin mit einem mitgelieferten Sollwert aus einer Hashdatei verglichen wird.

Ich habe die MD5-Hashwerte für ein unmodifiziertes deutsches WordPress, wie es von hier herunterzuladen ist, neu errechnet und die Hashdatei dazu passend erstellt. Wenn du also das Plugin Exploit Scanner auf einem deutschsprachigen WordPress einsetzt (was ich jedem verantwortungsvollen WordPress-Anwender unbedingt empfehlen würde) und sicher sein willst, dass sich kein Virus oder WordPress-Hack auf deinem Webspace eingenistet hat, solltest du folgende Schritte durchführen:

Hashwerte für WordPress 3.3.1 de_DE

  1. Aktualisiere WordPress jetzt auf die allerneueste Version.
  2. Stelle sicher, dass das Plugin Exploit Scanner installiert und aktiviert ist.
  3. Lade die Hashdatei hashes-3.3.1.php für die deutsche Fassung von hier herunter.
  4. Speichere diese Hashdatei über FTP im Verzeichnis <wordpress_ordner>/wp-content/plugins/exploit-scanner/ auf deinem Webserver.
  5. Prüfe deine WordPress-Installation auf unbefugte Veränderungen mit dem Menüpunkt “Werkzeuge > Exploit Scanner”.

Der MD5-Hash der Datei hashes-3.3.1.php selbst ist f61b81bf61a98c34ac3b5c5d1164a1a6. Dieser Wert sollte auch am Fuß der Seite unter “Werkzeuge > Exploit Scanner” angezeigt werden.

FAQ: Wie kannst du sicher sein, dass ich ehrlich bin und es in Ordnung ist, Code von meiner Site auf deinem Server zu installieren? Tja… No risk, no fun.

Hashwerte für aktuelle und ältere WordPress-Versionen

Obwohl es sicher nicht sicher genug ist, alte WordPress-Versionen zu lange weiter zu verwenden, gibt es doch manchmal technische Umstände, die ein Update auf die neueste WordPress-Version unmöglich machen. Passende Exploit-Scanner-Hashdateien sind hier herunterladbar:

Version Download Hash
3.3.1 hashes-3.3.1.php 46deb2248e224023a3c27c39cad0dea5
3.2.1 hashes-3.2.1.php f61b81bf61a98c34ac3b5c5d1164a1a6
3.1.2 hashes-3.1.2.php 1615a43c16bcea8c036a6820d1b3e2a1
3.1.1 hashes-3.1.1.php e3d3191f21c5821354548edd3213041a
3.1 hashes-3.1.php 50a8ad99d47b6fb57297f575142b4259
3.0.5 hashes-3.0.5.php 9a24c6dbcb1e6028bd854f7ca8136259
3.0.4 hashes-3.0.4.php 81543a22aee2ea03a4b9e39a03fca384

Diese Hashdateien werden mit einem weiteren Plugin erzeugt, das ich zur Zeit nur privat einsetze. Im Prinzip wäre es mit diesem Plugin für jeden User möglich, Hashes für jede Version oder Lokalisierung von WordPress zu berechnen, darum will ich das Plugin später wie alle anderen auch im WordPress-Plugin-Repository veröffentlichen, sobald die dazugehörige Dokumentation brauchbar ist.

FAQ

Wie kannst du sicher sein, dass ich ehrlich bin und es in Ordnung ist, Code von meiner Site auf deinem Server zu installieren? Tja… No risk, no fun.

Kommentare

WordPress beschleunigen - mit nur einem Klick

14. Dezember 2010, 13:08

Weil’s in diesem Beitrag um Geschwindigkeit geht, gibt’s gleich vorweg die Kernaussage für alle Eiligen:

Wenn du dein Blog mit einer Version von WordPress vor 3.0 aufgesetzt hast und “schöne” Permalinks verwendest, speichere jetzt die Permalink-Einstellungen noch einmal. Dein Blog wird dadurch schneller – sonst ändert sich nichts.

WordPress-Einstellungen "Permalinks"

Und nun das Ganze noch mal langsam zum Mitlesen1

Um schöne Permalinks nach dem Muster http://www.example.com/2010/12/hello-world an Stelle der “hässlichen” Variante http://www.example.com/?p=123 erzeugen zu können, benötigt WordPress das Apache-Modul mod_rewrite und einige Zeilen in der Datei .htaccess, die im Wurzelverzeichnis des Blogs am Webspace liegt. In diesen Zeilen definiert WordPress, wie der Webhost auf Anfragen nach diesen “schönen” Permalinks reagieren soll.

Das macht WordPress schon seit Urzeiten so. Aber erst am 9. Januar 2010 wurde bekannt, dass die bisher benutzen Regeln für mod_rewrite den Webserver dazu angeleitet hatten, diese Regeln häufig zwei Mal für jeden Seitenaufruf durchzuackern – mit der damit einhergehenden Geschwindigkeitseinbusse für jeden Besucher. Diese Scharte wurde am 11. März 2010 ausgewetzt und mit dem Release von WordPress 3.0 im allgemein genutzten Produkt beseitigt.

Bessere RewriteRules ab WordPress 3.0

Ab Version 3.0 schreibt WordPress also bessere Rewrite-Regeln in die .htaccess – aber nur auf Aufforderung: Beim automatischen Update werden zwar alle Programmdateien aktualisiert und auch Datenbankstrukturen angepasst, aber etwaige Verbesserungen in der Konfiguration des Webservers bleiben aus Stabilitätsgründen außen vor.

So sieht der Block mit Rewrite-Regeln in .htaccess auf einer Installation von WordPress vor Version 3.0 häufig aus:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Erst mit dem Klick auf “Speichern” in den Permalink-Einstellungen werden die Rewrite-Regeln aktualisiert und um die eine Zeile ergänzt, die den zweiten Durchlauf durch das Regelwerk verhindert:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Schnellere Seiten, zufriedene Besucher

Diese eine zusätzliche Zeile erhöht im Fall von Hosting auf einem günstigen Webspace die Geschwindigkeit, mit der Seiten an die Besucher und auch an Google ausgeliefert werden, um etwa 10 bis 20 Prozent. Das ist zwar nicht atemberaubend, aber sowas von “geschenkter Gaul” wie nur irgend möglich.

Wie schaut die Situation bei dir aus?

1 …für die G’studierten ;)

Kommentare [14]

T-Shirts. Lausige T-Shirts.

3. November 2010, 20:36

Wofür schreibt man Sachen ins Internet schreibt…

Zu allererst: T-Shirts gibt es bei Nautilus Tauchreisen gratis im Tausch gegen eine Taucher-Story oder einen freundlichen Link. Ich habe mitgemacht und bin jetzt für den kommenden Sommer passend eingekleidet ;)

T-Shirt gratis von der Nautilus

Aber: Über zwei Jahre sind seit dem ersten Beitrag hier vergangen. Ganz am Anfang stand die Idee, zusätzlich zum WordPress-Urgestein Frank Bueltge noch was zu machen für die Nerds im WordPress-Ökosystem. Wer außer Frank noch WordPress auf Deutsch ausgereizt hat, habe ich erst später mitbekommen. Heiko, Micha oder Sergej sind mir jetzt spontan präsent.

Seit WordPress “Crazy Horse” pflege ich ein Demo-Installation für WordPress. Ergebnis: Ich kriege als einer der Ersten jede Spam-Kommentar-Innovation mit, die für WordPress in Indien, Russland und China erfunden wird. Positives Feedback? Weitgehend Fehlanzeige.

WordPress im Jahr 2010 heißt: Der wohlwollende Diktator beteiligt sich an der WordPress-Entwicklung mit obskuren Ideen oder Code, der das Leben von Profis erschwert. Die Core-Entwickler ignorieren Probleme aus der Wirklichkeit. Automattic engagiert sich in Glitter-Projekten und zieht dort Geld aus dem Vertrauen, den die Millionen User auf wordpress.com eingebracht haben. Pascal macht ein Flash-Magazin – über die Software, die Publishing im Web für die Massen ermöglicht hat. Nichts gegen die Idee und die Umsetzung, aber wie schräg ist das denn?

Im Einzelfall sind alle diese Indizien nicht relevant, aber in Summe heißt das für mich: WordPress ist langweilig, etabliert und so interessant wie das Wasser, das beim Drehen am Hahn aus der Leitung fließt… Für das Engagement von Einzelpersonen ist WordPress zu erwachsen geworden und ins CMS-Establishment von TYPO3, Alfresco und Konsorten abgewandert.

Was bleibt von TalkPress.de nach zwei Jahren? Ein Vergleich von Plugins für die Suchmaschinenoptimierung ist der populärste Beitrag hier. Was das über das technische Niveau der teuren WP-Themes aussagt, brauche ich wohl nicht weiter aufzudröseln…

Lausige T-Shirts für Links. Das bleibt.

</rant>

Kommentare [3]