Ihr bewährter Begleiter.
Viele Nutzer schätzen die vertraute Umgebung des Classic-Editors, die eine einfache und schnelle Bearbeitung ermöglicht.
Mehr Funktionen, mehr Möglichkeiten.
Der Advanced Editor erweitert den Funktionsumfang des Classic-Editors und ermöglicht es, Inhalte noch effektiver zu bearbeiten.
Der Classic-Editor für alle.
Der Classic-Editor zeichnet sich durch Stabilität und Zuverlässigkeit aus, was für professionellen Anwender von Bedeutung ist.
Der Advanced Editor für kreative Köpfe.
Mit dem Advanced Editor können Designer und
Content Creatoren kreative Ideen umsetzten.
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.
Wenn du die Cache-Mechanismen besser verstehen möchtest, siehe auch zum Beitrag WP: Caching unter der Lupe – Einblicke in die Unterschiede.
Info zum Cache: Ein WP-Plug-in wie Cache Enabler cacht vor allem die Daten auf der Website (Texte, Bilder, etc.) und wird als "Seitencache" benannt. Beachte: 'Cache Enabler' ist nicht konform mit dem Plug-in 'Blackhole for Bad Bots'.
Cache Enabler, 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 schon mit dem Seiten-Cache und der Minimierung von HTML & JavaScript.
Die grundlegenden Informationen sind hiermit erläutert, und der Cache funktioniert! Falls weitere Informationen von Interesse sind, setzen wir das Thema hier fort.
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 war schwerlich feststellbar. Jedenfalls ist es ungleich anspruchsvoller. Dies sei jedem Interessieren ans Herz gelegt selbst zu erproben. Hier für uns der Website hat sich das so entwickelt, dass "WP Super Cache" das Supreme ist.
Ich möchte vorerst auf Folgendes hinweisen bezüglich des Cache Enablers. Insbesondere wird im Tab 3 "Mit Snippet PHP-Ausführung verhindern" darauf eingegangen, was in der .htaccess
-Datei durch Mod_rewrite
-Regeln erreicht wird.
Die Anwendung dieser Regeln in der .htaccess
-Datei hat praktisch weder mit dem Cache Enabler noch mit WP Super Cache Verbesserungen gebracht. Die Überladung der .htaccess
mit zusätzlichen Regeln zeigt sich ebenfalls als wenig vorteilhaft.
Cache Enabler!
Mein Beitrag bemüht sich mithilfe der original Beschreibung und Anmerkungen meinerseits. Also, die folgende Darstellung der Website keycdn.com (Aktualisiert September 2021) 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.
Tab 1: Installation / Überprüfung
Tab 2: Einstellunen zum Cache
Tab 3: Mit Regeln in der .htaccess
PHP-Ausführung verhindern
Tab 4: FAQ – oft gestellten Fragen
Tab 1
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?
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 oder in anderem Browser öffnen und im Quelltext 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) ->
Tab 2
Einstellungen zum 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
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:
- In 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.
Tab 3: Mit Regeln in der.htaccess
PHP-Ausführung verhindernTab 3: .htaccess-Snippet 🙄
Mit Regeln in der .htaccess
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.
Fachsimpel
Des Beispiels zur Umgehung der PHP-Ausführung
Die Frage
… folglich meine Frage an Host-Support, ob diese Regeln in der .htaccess
das Optimierungspotenzial negativ beeinflussen können? – und ob sich das mit dem opCache spießen kann und so weiter. 😉
Die Antwort
Das Plug-in als auch die Umgehung der PHP-Ausführung konkurriert sich nicht mit unseren Einstellungen und dem opCache. 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
Folgendes ist nur relevant, falls man keine eigene Domain hat, also die Website nur mit der Hauptdomain seines Hosts betrieben wird.
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.
Tab 4: FAQ – oft gestellten FragenFAQ
FAQ – oft gestellten Fragen
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.
Der Beitrag wurde mit fachlicher Unterstützung erstellt.
Aktualisiert im Jahr 2024 März