Cache Enabler, das ist eine Erweiterung, die nur aktiviert und mit wenigen Einstellungen anzupassen ist. Im Grunde kann man damit nichts falsch machen. Ob für oder wider des Plug-ins Cache Enabler das möge jeder für sich entscheiden.
Info zum Cache: Ein WP-Plug-in wie Cache Enabler cacht vor allem die Daten auf der Website (Texte, Bilder, etc.) – der opCache agiert auf Serverebene und cacht im Arbeitsspeicher die PHP-Scripte.
Hier auf Wegerl ist kein Plug-in wie Cache Enabler in Anwendung. Und warum das? – siehe den Beitrag Autoptimize + Async JavaScript? …
Die Einstellungen
Erstens der ‚Cache Verfall‘ und das ‚Cache Verhalten‘ ist seinen Anforderungen entsprechend einzustellen.
Zweitens zu den Dingen mit ‚Cache Ausschluss‘. Folglich sind hier die Post- oder Pages-IDs, durch ein Komma getrennt, einzutragen. Diese Seiten / Beiträge werden dann nicht zwischengespeichert. Die nächst beiden Eintragungen sind dann etwas anspruchsvoller. Und da heißt es gern, wenn man nicht weiß, was zu tun ist, einfach leer lassen. Dasselbe mit ‚Cache Inclusions‘.
Und drittens, zur Cache-Minimierung. Da kommt es darauf an, ob du nur HTML zur Minimierung freigeben möchtest oder HTML & JavaScript.
So! – das war’s dann schon mit Cache inkl. Minimierung von HTML & JavaScript.
Werdegang? – der möchte da sehen.
Hier ist erst mal kleines vs. von Plug-in Cache Enabler und dem Plug-in WP Super Cache.
Indes durch den Hinweis zu WordPress.org ‚Optimization‘ Caching-Plugins – habe ich das WP Super Cache probiert. Eine bessere Performanz als mit Cache Enabler ist schwerlich feststellbar. Jedenfalls ist es ungleich anspruchsvoller. Dies sei jedem Interessieren ans Herz gelegt selbst zu erproben. Auf Eins möchte ich nur hinweisen. Und zwar dessen dasselbe ist wie hier bei Cache Enabler im Tab 3 ‚Mit Snippet PHP-Ausführung verhindern‘. Dies erfolgt ebd. in der .htaccess der Mod_rewrite-Regeln.Hiermit das Plug-in WP Super Cache originär: Wenn die Auslieferung des Expert Caches aktiviert ist, wird eine Datei namens .htaccess modifiziert. Diese Datei hat spezielle Regeln, die die zwischengespeicherten Dateien sehr schnell an Besucher weitergeben, ohne PHP auszuführen. Die .htaccess-Datei kann automatisch aktualisiert werden, aber wenn das nicht gelingt, werden die Regeln hier angezeigt und können von dir bearbeitet werden. Du musst die Regeln nicht aktualisieren, es sei denn, es wird hier eine Warnung angezeigt. Wenn eines Warning sind diese Regeln mit der Schaltfläche ‚Mod Rewrite Rules aktualisieren‘ aufzurufen. Danach sind diese Regeln zu kopieren und der .htaccess im Ordner wordpress einzutragen.
Weiter war hier das Plug-in WP Fastest Cache im TEST. Nicht zuletzt weil der ‚Cache Enabler‘ mit dem Plug-in ‚Blackhole for Bad Bots‘, dort lt. Hinweis, nicht konform ist. Fastest Cache, ist der Einstellung übersichtlicher als WP Super Cache. …
Wenn denn*, dann Cache Enabler!
* Dazu siehe auch oben im Info-Button den Hinweis: ‚Cache Enabler‘ ist nicht konform mit dem Plug-in ‚Blackhole for Bad Bots‘.
Zum Einlesen
Insbesondere auch zum Verständinis WP_CACHE, wie das so abläuft WordPress-Cache Grundlagen.
Mein Beitrag bemüht sich mithilfe der original Beschreibung und Anmerkungen meinerseits. Also, die folgende Darstellung der Website keycdn.com (Aktualisiert am 9. Januar 2020) ist keine 1:1-Übersetzung.
Cache Enabler
keycdn.com, erweiterte Erklärung
Originär keycdn.com: Das WordPress Cache Enabler Plug-in ist ein leichtes Caching Plugin, das statische HTML-Dateien erstellt und auf dem Webserver speichert. Dies bedeutet, dass eine statische HTML-Datei ausgeliefert wird, wann immer möglich, um den Nutzern die Antwortdaten zur Verfügung zu stellen. Denn diese würden den ressourcenintensiven Prozess der Verwendung des WP-Kerns, also der Plug-ins und der Datenbank beinhaltet, beanspruchen. Dieses minimalistische, aber leistungsstarke Plug-in ist einfach zu bedienen: d. h. minimale Konfiguration und am besten von allen hilft es, die Ladezeit der Website zu verbessern.
Weiter Cache Enabler, originär:
- Es wird empfohlen HTTP/2 auf dem Webserver zu aktivieren und wenn CDN in Anwendung mit HTTP/2 Unterstützung zu verwenden. „Domain Sharding“ und „Concatenation“ sollte vermieden werden für bessere HTTP/2 Performance.
[tabby title=“Install./Überpr.“]
Installation / Überprüfung
Plug-in installieren und durch selbigen Button aktivieren. Sie können nun zu den Einstellungen des Plugins navigieren, indem Sie auf Einstellungen/“Cache Enabler“ gehen.
Nanu: was macht Cache Enabler nach der Aktivierung?
Erst mal! – winzige Info: („Dashboard/Plugins/Installierte Plugins“ erscheint mithin Plug-in Cache Enabler, ober der Anzeige von Plugins (Alle (…), | Aktiviert usw,. auch der Hinweis „Drop-Ins“. Originär: „Drop-Ins sind weiterentwickelte Plugins im Verzeichnis wp-content, die, wenn vorhanden, WordPress-Funktionalität ersetzen“: den Eintrag anzeigend: advanced-cache.ph – erweitertes Caching-Plugin.
Nach der Aktivierung führt Cache Enabler zwei Dinge aus:
- Fügt
define('WP_CACHE', true);vom Cache Enabler zur Datei wp-config.php hinzu - Kopiert die Datei „advanced-cache.php“ aus dem Cache-Enabler in das wp-content Verzeichnis.
Der X-Cache-Handler: wp-Header wird angezeigt, wenn die Datei advanced-cache.php verwendet wird. Andernfalls wird, wenn WP_CACHE auf false gesetzt ist (‚WP_CACHE‘, false;), dann wird Cache Enabler PHP nicht umgehen und Sie sehen den folgenden Header X-Cache-Handler: php.
Wenn bei Aktivierung* Cache Enabler nicht in der Datei wp-config.php schreiben kann …
* … oder auch anderen Grund im Verlauf der Erstellung einer Website –.
… dann erhältst du eine Warnung in deinem Dashboard
define('WP_CACHE', true); is no set in wp-config.php
Bei erhalten diese Warnung kann man entweder die Dateiberechtigungen ändern und das Plug-in neu installieren oder der wp-config.php-Datei. manuell hinzufügen:
define('WP_CACHE', true);
Also bleibt die wp-config.php zu beachten:
/**
* Ersetze datenbankname_hier_einfuegen
* mit dem Namen der Datenbank, die du verwenden möchtest.
*/
define('WP_CACHE', true);
define('DB_NAME', '[…]');
FAQ: Wie kann ich überprüfen, ob der Cache-Enabler auf meiner Website arbeitet?
Zur Überprüfung dass der Cache Enabler eine zwischengespeicherte Version einer bestimmten Seite liefert: Der WordPress-Installation abmelden und die Seitenquelle für einen dieser Kommentare überprüfen:
Vertrauen ist gut – Kontrolle ist besser
<! – Cache Enabler von KeyCDN @ 10.11.2015 17:32:29 (webp gzip) ->
<! – Cache Enabler von KeyCDN @ 10.11.2015 17:32:29 (webp) ->
<! – Cache Enabler von KeyCDN @ 10.11.2015 17:32:29 (html gzip) ->
<! – Cache Enabler von KeyCDN @ 10.11.2015 17:32:29 (html) ->
[tabby title=“Einstellung“]
Einstellungen Cache
Cache Verhalten: Standardmäßig wird nur der Home-Cache gelöscht, wenn ein neuer Beitrag veröffentlicht wird.
Cache Verfall
Automatischer Cache-Ablauf in Stunden:
- Der Cache kann in vorgegebenen Zeitintervallen automatisch gelöscht werden. Ein Cache-Ablauf von 0 bedeutet, dass der Cache nie automatisch abläuft.
Optionen, um das automatische Clearing des Cache zu aktivieren
- Zwei Möglichkeiten bei „Beitrag aktualisieren“: Den gesamten Cache jedes Mal zu löschen (mit Häkchen) oder es wird nur der seitenspezifische Cache jedes Mal gelöscht, wenn ein Beitrag aktualisiert wird.
- Die Möglichkeit bei Kommentar: Das Clearing des vollständigen Cache jedes Mal zu aktivieren, wenn jemand einen neuen Kommentar platziert.
Integration von WebP-Bildern
- HTTP / 2 fokussiert
- Funktioniert perfekt mit Autoptimieren
- Unterstützt reagierende Bilder über srcset in WordPress 4.4
- Der WordPress Cache Enabler nutzt auch den If Modified Since Header, um dem Browser zu helfen, zu bestimmen, ob sich der Inhalt seit der Erstellung der statischen Cache-Datei geändert hat. Wenn sich der Inhalt nicht geändert hat, wird der Statuscode für das ursprüngliche HTML-Dokument an den Browser als 304 zurückgegeben. Wenn sich der Inhalt geändert hat, wird das HTML-Dokument erneut abgerufen und ein Statuscode von 200.wordpress-cache-304- Nicht modifiziert.
FAQ: Wie kann ich meine Bilder in WebP konvertieren?
Um Bilder in WebP zu konvertieren, benutze das Cache Enabler Plugin in Verbindung mit dem Optimus Image Optimizer Plugin und aktiviere die WebP Optionen auf beiden Plugins.
FAQ: Wie funktioniert die WebP-Integration?
Der WordPress Cache Enabler analysiert die jpeg und png Bilder in Ihrem Upload-Verzeichnis, um zu sehen, ob es ein gleichwertiges WebP-Bild (erzeugt von Optimus). Diese WebP-Bilder sind dann in der WebP-Cache-HTML-Datei enthalten.
Cache Ausschluss
- Option (Post-Typ-Unterstützung), das Caching von bestimmten Posts oder Seiten durch ID auszuschließen
Cache Minimierung
Option zur Aktivierung der Cache-Minifizierung
- Deaktiviert
- HTML oder
- HTML & Inline JS
Die Optionen sind im Grunde deaktiviert. In Anwendung alleinig ‚Cache Enabler‘ ist das nicht empfohlen. Normal ist ‚HTML‘ oder ‚HTML & Inline JS‘ einzustellen. Je nachdem, ob der Website Javascript dabei oder nicht. Anders bzw. Fachsimpel, ist das in Anwendung von bspw. Plug-ins ‚Autoptimize + Async JavaScript‘. Da hiermit das HTML & Inline JS von ‚Autoptimize‘ auszuführen ist. Somit wäre diese Einstellung mit ‚Deaktiviert‘ abzuspeichern.
Admin-Leiste Anzeige
Backends Admin-Leiste.
Manuelles Löschen von Cache:
- Aus der Admin-Leiste Löschen von Cache (gesamten Cache) und
- Löschen des seitenspezifischen Caches: Der Cache einer bestimmten URL kann direkt aus der WordPress-Admin-Leiste gelöscht werden, durch klick‘ auf „URL-Cache löschen“.
Bemerkungen:
- Im Backends Ansicht der Website (Frontend) ist die Schaltfläche „URL Cache löschen“. Dieses bewirkt dessen nur für selbige Seite.
- Der Button „Cache löschen“ ist für die gesamte Website.
Bspw. in Änderung eines Widgets bewerkstelligen diese Taster die aktuelle Ansicht gecoachten Website. Doch eines Beitrag/Seite durch „Aktualisieren“ und „Freischalten/Löschen“ eines Kommentars wird dessen automatisch auf den Webbrowsers (bei Neuladung der Website) übertragen. Daher sind hierfür diese Steuerelemente nicht anzuwenden.
Merke: Backends auf der Homeseite (Startseite) wird in Anwendung „URL Cache löschen“ der gesamte Cache gelöscht, gleich mit „Cache löschen“.
[tabby title=“Snippet“]
Mit Snippet PHP-Ausführung verhindern
Durch das Hinzufügen des erweiterten Konfigurations-Snippets zum Apache-Server besteht für eine noch schnellere Lieferung die Möglichkeit, PHP vollständig zu umgehen, um die statische HTML-Datei abzurufen, die vom WordPress Cache Enabler Plugin erstellt wurde. Die folgenden Konfigurations-Snippets können auf Apache- oder Nginx-Servern implementiert werden. Darüber hinaus sollte das Standard-Cache-Enabler-Setup die Mehrheit der Use-Cases erfüllen.
Das Snippet ist für welches die statische HTML-Datei abruft, die vom WordPress Cache Enabler Plugin erstellt wurde.
Diese Konfiguration ist optional und muss nicht implementiert werden, um das Cache Enabler Plug-in nutzen zu können. Es ist nur eine vorgeschlagene Konfiguration für diejenigen, die PHP vollständig umgehen wollen, wenn dann eine statische HTML-Datei existiert. Die Exspirationsrichtlinie wird auch mit der erweiterten Konfiguration umgangen.
Das Snippet vor dem # BEGIN WordPress-Abschnitt in der .htaccess-Datei hinzufügen. S. der Überschrift Advanced Configuration.
Fachsimpelei
Des Beispiels zur Umgehung der PHP-Ausführung
Die Frage
… folglich meine Frage an Host-Support bplaced, ob diese Regeln in der .htaccess das Optimierungspotenzial auf bplaced negativ beeinflussen können? – und ob sich das mit dem opCache spießen kann und so.
Die Antwort
Das Plug-in als auch die Umgehung der PHP-Ausführung konkurriert sich nicht mit unseren Einstellungen und dem opCache auf bplaced. Also du kannst das Plug-in problemlos einsetzen 😉
Das Plug-in Cache Enabler cacht vor allem die Daten der Website (Texte, Bilder, etc.). Der opCache aber agiert auf der Ebene des Servers und cacht die PHP-Scripte im Arbeitsspeicher.
… Das Folgende ist nur speziell von wegen
WordPress im Unterverzeichnis
Die Variable SUB_PATH muss entsprechend angepasst werden, wenn WordPress in einem Unterverzeichnis installiert ist (z. B. http://www.example.com/blog erfordert eine Änderung an
SUB_PATH=/blog/wp-content/cache/cache-enabler/).
Beispiel aufs Exempel (Dashboard/Einstellungen/Allgemein):
Zur Kenntnisnahme unterschiedl. Adresse, s. „vorhergehend“: WordPress im Unterverzeichnis über Hauptverzeichnis aufrufen
… somit lautete die Anpassung für die Variable:
SUB_PATH=/wordpress/wp-content/cache/cache-enabler/
Wohlgemerkt: wenn die .htaccess im selben Ordner wie die WP-Installation oder die WP-Installation offen mit der .htaccess am Web-Host-Server installiert, ist SUB_PATH=/wp-content/cache/cache-enabler/ richtig.
Standort von wp-admin
Wenn der Standort von wp-admin geändert, muss dies auch in der folgenden Bedingung angepasst werden:
RewriteCond %{ENV:CE_PATH} !^/wp-admin/.*.
Fachspezifisch (ich lass mal so stehen…): Das Snippet definiert bestimmte Bedingungen und wenn sie erfüllt sind, wird die RewriteRule ausgelöst. Für die gzip-Version, die letzte Bedingung, RewriteCond% {DOCUMENT_ROOT}% {ENV: SUB_PATH}% {HTTP_HOST}% {ENV: CE_PATH} index.html.gz -f, prüft, ob die HTML-statische Datei verfügbar ist und wenn Diese Bedingung und alle anderen Bedingungen erfüllt sind, wird ein Rewrite ausgelöst. Die statische HTML-Datei wird dann direkt abgerufen (verhindert PHP-Anrufe) und an den Client zurückgesendet.
… steht auf dem Blatt.
FAQ: Wird Cache Enablers Ablauffunktion noch funktionieren, wenn ich das erweiterte Snippet verwende?
Nein. Die Fähigkeit des Cache Enablers, den Cache auf der Grundlage eines definierten Zeitraums automatisch ablaufen zu lassen, wird nicht mehr funktionieren, da die für diese Funktion benötigten PHP-Aufrufe umgangen werden.
Cache über Dritte (s. bitte Website keycdn.com)
Das PHP-Snippet kann verwendet werden, um den Cache über einen Dritten wie z. B. einen Cron Job zu löschen. Der erste Abschnitt initialisiert die WordPress-Umgebung, normalerweise sollte diese PHP-Datei im WordPress-Stammverzeichnis liegen. Die zweite, wenn die Aktion des vollständigen Clearing des Cache und mit dem dritten, wenn die Möglichkeit besteht, festzustellen, für welche Post-ID.
Cache Ablauf mit Snippet
Es kann ein Cron-Job erstellt werden, um den Cache automatisch fortzusetzen. Fügen Sie dem Cron-Job den folgenden Befehl hinzu, sobald Sie den Zeitraum festgelegt haben, für den Sie möchten, dass der Cache abläuft */1 * * * * rm -rf /path/to/your/wordpress/wp-content/cache/cache-enabler/
Wie kann ich überprüfen, dass das erweiterte Snippet PHP umgeht?
Um sicherzustellen, tatsächlich PHP zu umgehen, nachdem das Snippet hinzugefügt wurde:
Wenn das erweiterte Snippet-Konfiguration hinzugefügt wurde, ist bei Überprüfung der Header festzustellen, dass keine speziellen WordPress Cache Enabler-Header hinzugefügt sind. Also der X-Cache-Handler-Header – HTTP-Header nicht ausgeben ist.
Die Überprüfung durch https://redbot.org – also wenn diese Zeile:
x-cache-handler: wp
nicht vorhanden ist, dann ist das erweiterterte Konfigurations-Snippet ordnungsgemäß implementiert.
[tabby title=“FAQ“]
Weitere FAQ
Inhalt
- Funktioniert Cache Enabler mit Disqus bedingtem Load Plugin?
- Funktioniert Cache Enabler mit mobilen Themen, wenn der Desktop und die mobilen Versionen anders sind?
- Warum ist meine Woocommerce-Bestandsaktualisierung nicht?
- Funktioniert Cache Enabler mit Standard-Permalinks?
- Kann ich Cache Enabler mit dem WordPress Nexus Thema verwenden?
- Wie verwende ich Cache Enabler auf einem WordPress Multisite Setup?
Funktioniert Cache Enabler mit Disqus bedingtem Load Plugin?
Ja. Um Cache Enabler ordnungsgemäß mit DCL-Plugin zu arbeiten, navigiere einfach zu DCL-Einstellungen und lege die Option Caching Support auf „Enable“. Die Einstellungen sichern und DCL funktioniert nun ordnungsgemäß mit Cache Enabler.
Dcl-Einstellungen
Funktioniert Cache Enabler mit mobilen Themen, wenn der Desktop und die mobilen Versionen anders sind?
Es wird nicht empfohlen, das Cache Enabler Plugin zu verwenden, wenn ein mobiles Theme oder Plugin verwendet wird, das verschiedene Layouts für Desktop und Mobile zeigt. Der Cache wird umgangen, wenn eines dieser Plugins verwendet wird:
- WPtouch
- Carrington
- Jetpack
- Handheld
Andernfalls wird die zwischengespeicherte Version an den mobilen Benutzer ausgeliefert.
Warum ist meine Woocommerce-Bestandsaktualisierung nicht?
Wenn ein Problem mit Woocommerce-Lager im Cache besteht und daher nicht aktualisiert, versuche es mit der neuesten Version von Woocommerce zu aktualisieren. Ab Version 2.5.2 ist das Problem behoben und die Bestandsnummer steht nicht mehr im Konflikt mit Caching-Plugins.
Funktioniert Cache Enabler mit Standard-Permalinks?
Nein. Cache Enabler funktioniert nicht mit Standard-Permalinks
Kann ich Cache Enabler mit dem WordPress Nexus Thema verwenden?
Ja. Allerdings müss bei der Installation des WordPress Cache Enablers auf einer Website mit dem Nexus-Thema die Permalinks neu erstellen. Dies kann getan werden, indem du Dashboard> Einstellungen> Permalinks und Save Changes wählen.
Wie verwende ich Cache Enabler auf einem WordPress Multisite Setup?
Mit dem WordPress Cache Enabler Plugin auf einem Multisite-Setup ist ganz einfach. Sobald das Plugin heruntergeladen ist, zwei Möglichkeiten:
- Cache Enabler über die Netzwerkaktivierung aktivieren und es wird anfangen, für jede Site zu arbeiten.
- Cache Enabler auf jeder Seite einzeln aktivieren, wenn es nicht über das gesamte Netzwerk aktiviert sein möchten.
Alle Cache- und Einstellungen sind so konfiguriert, dass sie für jeden Standort individuell arbeiten. Daher kannst du den Cache vor Ort 1 löschen, während Standort 2 und 3 den Cache behalten. Wenn du auf die zwischengespeicherten Dateien aus dem Backend zugreifen musst, befinden sie sich unter /wp-content/cache/cache-enabler/yourdomain.com.
[tabbyending]