WP Performance Pack

FAQ

Wie kann ich erkennen, ob das Caching funktioniert?

Der Cache wird nur benutzt, wenn die alternative MO-Implementierung verwendet wird. Zum Überprüfen, ob der Cache verwendet wird, aktiviere das WPPP-Debugging (benötigt das Plugin Debug Bar). Dies fügt der Debug Bar eine neue Seite WP Performance Pack hinzu. Auf dieser werden u.a. Informationen über aus dem Cache geladene Übersetzungen angezeigt.

Welche Object-Cache-Plugins werden empfohlen?

Jeder persistente Object-Cache funktioniert, allerdings muss er vom Webserver unterstützt werden. Prüfe, ob Caches wie APCu, XChache, Memcache o.ä. auf dem Webserver installiert sind und wähle ein entsprechendes Cache-Plugin. Datei oder Datenbank basierte Caches funktionieren ebenfalls, wirken sich aber weniger positiv auf die Geschwindigkeit aus.

Unterstützt WPPP Multisite-Installationen?

Die Verbesserungen der Übersetzung funktionieren auch mit Multisite-Installationen. Wird WPPP netzwerkweit installiert, kann nur der Netzwerk-Admin die WPPP-Einstellungen sehen und bearbeiten. Die verbesserte Bildbehandlung ist nur verfügbar, wenn WPPP netzwerkweit installiert ist.

Was ist der Unterschied zwischen dem Plugin Dynamic Image Resizer und WPPPs dynamischen Bildgrößen?

In den ersten Versionen basierte WPPPs dynamische Bilderzeugung auf dem Plugin Dynamic Image Resizer, lediglich mit ein paar kleinen Änderungen. Die erste große Änderung bestand darin, Rewrite-Regeln statt des 404-Handlers für die Erzeugung der Zwischengrößen zu verwenden. Mit WPPP 1.8 kam die Verwendung von Ableitungen von WP-Image-Editor, um das Erzeugen von Zwischengrößen beim Upload zu verhindern. Diese Methode ist deutlich effektiver und funktioniert auch beim Bearbeiten von Bildern.

Laut Autor ist Dynamic Image Resizer lediglich ein Proof-Of-Concept. WPPPs dynamische Bilderzeugung könnte man als funktionierende Implementierung dieses Proof-Of-Concepts bezeichnen.

Wie repariere ich meine Bilder, wenn diese nach Verwendung der dynamischen Links nicht mehr funktionieren?

Zuerst solltest Du die Funktion „Statische URLs wiederherstellen“ in den WPPP-Einstellungen versuchen. Diese Funktion wird auch automatisch beim Deaktivieren von WPPP ausgeführt. Falls dabei Fehler auftreten (wenn ja, bitte die Fehler im Support-Forum posten, damit ich die Funktion entsprechend anpassen kann), kannst Du die folgende SQL-Funktion direkt verwenden, um die Links wiederherzustellen:

UPDATE wp_posts SET post_content = REPLACE ( post_content, ‚{{wpppdynamic}}‘, ‚http://your.base-url/wp-content/uploads/‘ )

Die Basis-URL (dritter Parameter von REPLACE) muss durch Deine Basis-URL ersetzt werden!

Funktionsweise der Übersetzungs-Beschleunigung.

WPPP überschreibt WordPress‘ Standardimplementierung über den Hook override_load_textdomain. Die schnellste Übersetzungsmethode ist die Verwendung von nativem Gettext. Hierfür wird die PHP-Erweiterung Gettext benötigt. WPPPs Gettext-Implementierung basiert auf Bernd Holzmuellers Translate_GetText_Native.

Als zweite Möglichkeit bietet WPPP einen komplett neu geschriebenen MO-Reader (MO_dynamic bzw. alternativer MO-Reader). Der WordPress eigene MO-Reader lädt immer komplette Übersetzungsdateien in den Speicher, auch wenn nur eine einzige Übersetzung davon verwendet wird. Dies kostet Zeit und Speicherplatz. MO_dynamic lädt nur verwendete Übersetzungen in dem Moment, wenn sie verwendet werden. Auch wenn die gezielte Suche nach einzelnen Übersetzungen etwas langsamer ist, sorgt die deutlich schnellere Ladezeit und der geringere Speicherverbrauch insgesamt für eine wesentlich schnellere Übersetzung.

Die Verwendung eines Caches kann die Geschwindigkeit weiter erhöhen. Wird der alternative MO-Reader verwendet, werden Übersetzungen über WordPress‘ Object-Cache-API gecachet. Frontend-Seiten verwenden üblicherweise wenige Übersetzungen, daher wird für alle Frontend-Seiten ein Cache verwendet. Backend-Seiten hingegen verwenden meist viele Übersetzungen, weshalb jede Backend-Seite ihren eigenen Cache verwendet, mit einem extra Basis-Cache pro Textdomain. Dieser Basis-Cache enthält diejenigen Übersetzungen, die auf allen Backend-Seiten verwendet werden (Übersetzungen, die vor dem Ereignis admin-init verwendet wurden). Dies dient dazu, die Cache-Größe zu verringern, da diese häufig recht begrenzt ist. Um die Größe noch weiter zu reduzieren, werden die Übersetzungen komprimiert, bevor sie gecachet werden.

Funktionsweise der dynamischen Bildzwischengrößen.

Zwischengrößen von Bildern werden nicht beim Upload erzeugt. Statt dessen werden die Bilder und die dazugehörigen Metadaten erst beim jeweiligen ersten Zugriff erzeugt. Dazu leitet WPPP alle registrierten WP-Image-Editor-Klassen ab und überschreibt die Funktion multi_resize. Da die Ableitung dynamisch erfolgt, funktioniert dies mit jeder Image-Editor-Implementierung. Die Zwischengrößen werden dann über Rewrite-Regeln erzeugt. Wird auf eine nicht existierende Zwischengröße zugegriffen, wird die Anfrage auf eine spezielle PHP-Datei umgeleitet, die nur ein Minimum an WordPress-Code lädt. Die Umleitung erfolgt über die htaccess-Datei.

Wenn ein nicht existierendes Bild angefordert wird, prüft WPPP ob die angeforderte Bildgröße einer der registrierten Bildgrößen entspricht (entweder eine der Standardgrößen „thumbnail“, „medium“ oder „large“ oder eine andere, von Plugins oder vom Theme registrierten Zwischengrößen). Hieran erkennt WPPP auch, ob das Bild beschnitten werden soll, oder nicht.

How does WPPPs disable widget feature differ from other plugins

Most other plugins which allow you to disable widgets just unset the respective widgets in WordPress‘ global widget list. This doesn’t prevent the widgets‘ code to be loaded. WPPP disables default loading of widgets completely and only loads those files required to create the enabled widgets. Available widgets are detected when the modules settings page is displayed by scanning the wp-includes/widgets folder for any classes extending WP_Widget. It only has a small impact on performance and memory usage but many small improvements can become quite big.