So wird das deutsche WordPress ab Version 3.4 gravierend schneller

28. Februar 2012, 13:39

Die deutsche Spracheinstellung kostet WordPress teilweise über 40 Prozent Geschwindigkeit im Vergleich zur englischen Variante. Die Hauptursache ist die aufwendige und speicher-fressende Übersetzungsbibliothek, die WordPress bei jedem Seitenaufruf abarbeiten muss, um die originalen englischen Texte in ihr deutsches Gegenstück zu übersetzen.

Dazu wird der Webserver durch eine träge in PHP geschriebene Nachahmung von Funktionen gequält, die in vielen Fällen bereits als schneller C-Code im Betriebssystem des Webservers vorhanden sind – die sogenannte gettext-Bibliothek.

Langsames WordPress als Resultat von “günstigem” Webspace

Kann das deutsche WordPress auf diese “nativen” C-Funktionen zurückgreifen, reduziert sich der Übersetzungs-Overhead auf schlanke vier Prozent. Gleichzeitig sinkt der Hauptspeicher-Verbrauch des Webservers, sodass als Konsequenz WordPress auch wieder auf billigeren Webhosting-Paketen mit etwas niedrigerem memory_limit laufen könnte. Es gibt ja immer noch günstige Webspace-Angebote, bei dem der Hoster dieses Speicherlimit für PHP auf asketische 32 MB gesetzt hat.

Und beim Webspace-Anbieter liegt auch in Zukunft “der Hund begraben”: Die gettext-Erweiterung für PHP ist ein optionaler Bestandteil, den der Webhoster bereitstellen muss. Nicht auf jedem Webspace ist PHP mit dieser schnellen Extension eingerichtet, und in diesen Fällen wird sich an der Geschwindigkeit wahrscheinlich auch in Zukunft nichts ändern.

Licht → Tunnel

Für Nutzer aller anderen Webspace-Angebote ist Licht am Ende des Tunnels zu erkennen. Beim WordPress-Team ist ein Patch eingetrudelt, der die im Betriebssystem eingebauten schnellen gettext-Funktionen in WordPress integriert, und Andrew Nacin hat vorsichtig signalisiert, dass dieser Patch in die Version 3.4 eingearbeitet werden könnte.

Leider zeigt WordPress nirgendwo im Dashboard an, ob die schnelle oder die langsame Variante der Übersetzungsbibliothek genutzt wird – die Auswahl erfolgt vollständig ohne Eingriffsmöglichkeit für den Anwender, indem die vorhandenen Fähigkeiten (oder eben auch Unfähigkeiten) des Webservers benutzt werden.

Ein Diagnose-Plugin

Ich habe darum das Plugin Native gettext diagnosis geschrieben, das sich als zusätzlicher Eintrag im Menü “Werkzeuge” einnistet und eine Reihe von Tests durchführt.

Screenshot des Plugins “Native gettext diagnosis”

Ist die PHP-Erweiterung “gettext” geladen und das Ergebnis des Tests “WordPress kann das locale setzen” ein “Ja”, kann WordPress zumindest nach dem derzeitigen Stand der Entwicklung in Version 3.4 schneller werden.

Das Plugin funktioniert auch ab WordPress 3.2 und kann daher schon jetzt benutzt werden, um festzustellen, ob der eigene Webspace mit WordPress 3.4 schneller oder langsam arbeiten wird.

Mein Tipp: “Native gettext diagnosis” installieren, den Menüpunkt “Werkzeuge → Gettext-Diagnose” aufrufen und bei negativem Resultat entweder den eigenen Webhoster kontaktieren oder schlimmstenfalls den Webspace-Anbieter wechseln.

Meine eigenen Tests zeigen, dass zum Beispiel Host Europe, Uberspace und Dreamhost die schnelle gettext-Extension anbieten, während auf Windows basierende Hoster da leider oft passen müssen.

Kommentare [28]

21 nützliche Code-Schnippsel für functions.php

20. Februar 2012, 06:54

Die Darstellung des Volltexteditors anpassen, Einbruchsversuche mit leicht erratbaren Benutzernamen und Passwörter erschweren, jQuery direkt aus den Google-Netzwerk laden lassen und vieles mehr kann man in WordPress über einige wenige Zeilen in der Datei functions.php des Themes steuern.

Eine wachsende Sammlung solcher nützlicher Schnippsel stellt Merlin Mason zusammen mit einer einfachen Copy & Paste-Funktion auf wpfunction.me zur Verfügung.

wpfunction.me

Gut abgelagerte WordPress-Veteranen werden wahrscheinlich den größten Teil schon kennen oder ein Plugin für den einen oder anderen Zweck aus dem Ärmel schütteln. Aber wer ohne großen Rechercheaufwand das Plugin-Arsenal auf seiner WordPress-Installation ein wenig abmagern möchte, sollte mal einen Blick auf die Sammlung werfen.

Kommentare

5 Wege, um sich in WordPress 3.4 anzumelden

14. Februar 2012, 09:54

Welcher Webdesigner kennt nicht solche Fälle: Ein Kunde hat eine bestehende, etwas in die Jahre gekommen Website, die im Prinzip noch gut genug ist. Aber schön wär’s doch, wenn der Bereich mit den Neuigkeiten aus dem Unternehmen und den Pressemeldungen etwas einfacher zu verändern wäre und er nicht immer einen Dienstleister beauftragen müsste, um nur ein paar Absätze zu veröffentlichen.

Also installiert man WordPress in einem Unterordner auf dem Webspace, baut ein passendes Theme und zeigt dem Kunden kurz, wie er sich anmelden und einen neuen Beitrag schreiben kann.

Kaum ein paar Monate später möchte der dann schon seine zweite Meldung eingeben und meldet sich ganz verzweifelt: Weg ist er, der Zettel mit den Zugangsdaten, die Adresse zum Anmelden findet er nicht mehr in den Explorer-Favoriten, und probiert hat er auch schon alle möglichen URLs. Ob “WordPress.php”, “login”, “admin”, überall kommt nur eine Seite mit diesem hämischen

Seite nicht gefunden. This is somewhat embarrassing, isn’t it? It seems we can’t find what you’re looking for.

Das ist verständlich. Mit der Zeit gewöhnt man sich als Dienstleister sogar an, schon vorbeugend ein paar solcher Shortcuts direkt in der .htaccess anzulegen und seinen Kunden den Stress zu ersparen.

WordPress 3.4 hilft bei Gedächtnisschwäche

Mit WordPress 3.4 kommt eine kleine Verbesserung für Leute, die den Zugang zum WordPress-Dashboard vergessen haben: Für eine Reihe von “beliebten” Rate-Versuchen leitet WordPress automatisch auf die korrekten URLs für Login und Dashboard um. Voraussetzung dafür ist, dass “schöne” Permalinks verwendet werden.

Hier ist die vollständige Liste von Pfaden, die WordPress 3.4 zur Anmeldung und zum Dashboard führen:

Ich hatte vorgeschlagen, diese Liste noch um /wordpress und /WordPress zu erweitern, aber Andrew Nacin hielt das für doch zu verwirrend und ließ sich (leider) nicht überzeugen.

Kommentare [4]

Sicherheitsanalyse reiht WordPress vor Joomla und TYPO3

7. Februar 2012, 04:16

Für eine Studie über die Sicherheit von WordPress, TYPO3, Joomla, Drupal und anderen Content-Management-Systemen hat Philipp Krenn die Release Notes und Security Advisories der jeweiligen Projekte analysiert. Die Systeme wurden nach Häufigkeit und Schwere der in den Jahren 2010 und 2011 veröffentlichten Sicherheitslücken gereiht.

Dieses Diagramm zeigt eine Zusammenfassung der Analyse:

CMS-Sicherheit (qualitativ)

Wie man sieht, zeigen sich große Unterschiede zwischen den Systemen:

  • WordPress hatte nur eine schwere Sicherheitslücke in diesen beiden Jahren.
  • Joomla hängt der Ruf eines unsicheren Systems nach. Für dieses schlechte Image liefert die Analyse keine Beweise. Es gab zwar relativ viele, aber nur leichte Sicherheitsprobleme.
  • TYPO3 ist das Schlusslicht unter den beteiligten CMSen und zeigt die meisten, auch schweren Sicherheitslücken.

Natürlich lässt sich die Sicherheit eines CMS nicht objektiv nur über das Auszählen der gemeldeten Fehler messen.

Bei WordPress werden zum Beispiel weder Sicherheitslücken in Themes noch in Plugin offiziell gemeldet, während Drupal Advisories sowohl für den CMS-Kern als auch alle Module veröffentlicht. Drupal und TYPO3 verwenden eine definierte Systematik, um die Schwere der Sicherheitsmängel zu kategorisieren. Für WordPress gilt das nicht.

Die vollständige Studie ist hier zu finden.

Grafik: Phillipp Krenn, CC-BY-SA.

Kommentare [7]

Wie die WordPress Admin Bar als Datenkrake missbrauchbar ist

2. Februar 2012, 11:28

TL;DR

Über die mit WordPress 3.3 eingeführte erweiterte Admin Bar kann eine in den USA angesiedelte Firma E-Mail-Adressen von Nutzern der selbstgehosteten WordPress-Variante mit den Adressen der von ihnen bearbeiteten Blogs zusammenführen.

Matt Mullenweg erfährt, was du gestern getan hast

In der Version 3.3 hat WordPress die erweiterte Admin Bar erhalten, eine Kopfleiste im Dashboard zum schnellen Zugriff auf viele häufige Funktionen des WordPress-Administrationsbereichs. Diese Admin Bar ist bei jeder Aktion am oberen Seitenrand im Dashboard sichtbar.

In der rechten Ecke zeigt die Admin Bar ein individuelles Avatar des angemeldeten Benutzers.

Kennst du den: Kommt ein Gravatar in die "Admin Bar"...

Um diese Grafik anzeigen zu können, führt das Dashboard folgende Schritte durch:

  1. Die E-Mail-Adresse aus dem Profil des angemeldeten Benutzers wird an Gravatar.com1 übertragen.
  2. Der Browser übergibt bei dieser Gelegenheit auch die URL des Dashboards als Referrer an Gravatar.com.
  3. Gravatar.com verwendet die übertragene E-Mail-Adresse und sucht den zugehörigen Benutzer.
  4. Kennt Gravatar.com den Benutzer zu dieser E-Mailadresse, wird sein Avatarbild an den Browser des Benutzers zurückgeliefert.
  5. Ist die E-Mailadresse bei Gravatar.com unbekannt, wird ein neutrales Ersatzbild geliefert.
  6. In beiden Fällen erhält Gravatar.com die E-Mailadresse des Benutzers und die Adresse des Blogs.
  7. Nach Ablauf der Cache-Dauer von fünf Minuten wiederholt sich dieser Vorgang.

Ich habe die relevanten Passagen in diesem Netzwerkprotokoll gelb markiert:

Hardcore: Protokoll des Datenaustauschs zwischen Browser, dem Dashboard und gravatar.com

Nach meinen Recherchen lässt sich die Informationsübertragung an Gravatar.com weder über eine Einstellung noch durch ein Plugin unterbinden, ohne die Gravatar-Funktionalität vollständig stillzulegen und damit zum Beispiel auch für die Anzeige der Kommentator-Avatare zu verlieren.

Gravatar.com weiß klarerweise, welches Bild zu einer bestimmten E-Mail-Adresse gehört:

E-Mail-Adresse redigiert. Aus Gründen.

Matt Mullenweg hält dich für uninteressant

Ich glaube nicht, dass sich die WordPress-Entwickler bei Automattic diese Verbindungen bewusst gemacht oder gar mit Absicht eingebaut haben.

Aber ich halte es für eine eklatante Lücke, dass die Datenübertragung an Gravatar.com praktisch fortlaufend während jeder Benutzersession im Dashboard passiert, während fast jedes andere Fitzelchen im Dashboard über Einstellungen, Plugins und Filter beeinflussbar ist.

Eine Offenlegung dieses Verhaltens habe ich weder in der Privacy Policy von Automattic noch bei der rein nominell ja von Automattic Inc. unabhängigen2 WordPress Foundation finden können.

Noch ein Grund für “German Internet Angst”

Deutsche Datenschützern beginnen ja schon wegen der Übertragung von IP-Adressen an ausländische Unternehmen zu hyperventilieren. Ich wäre gespannt auf deren Reaktion, wenn die wüssten, dass eine kleine Firma in San Francisco mit über den ganzen Globus verteilten Mitarbeitern Zugang zu den E-Mail-Adressen der Betreiber eines großen Teils der deutschen Websites hat.

Gegenmaßnahmen

Am schönsten wäre es aus meiner Sicht, wenn die Darstellung des Gravatars im Dashboard über einen Filter oder eine Einstellung unterbindbar wäre. Der Unterhaltungswert des Bildchens für den Benutzer ist ohnehin gering, und ein paar hundert Millisekunden für den doppelten Roundtrip zu Gravatar.com würden auch noch eingespart.

Eine Ausweichlösung wäre die Verwendung des verschlüsselten Protokolls HTTPS für den Zugriff auf das Dashboard. Dann würde die URL des Dashboards nicht mehr via Referer an Gravatar.com übertragen.

Und schlussendlich lässt sich das Problem auch noch mit der Holzhammermethode erledigen: Admin Bar komplett ausschalten.

1 Gravatar.com ist ein Dienst der Automattic Inc.

2 Wer die Trennschicht zwischen Automattic (gewinnorientiertes Startup, Arbeitgeber diverser WordPress-Entwickler) und der WordPress Foundation (karitativer Verein zur Förderung demokratischen Publizierens via GPL-Software und Inhaber der Rechte an der Marke “WordPress”) durchschaut, darf mich bitte in den Kommentaren erleuchten.

Kommentare [15]