Dokumentation

Cachify ist das ausgereifte, kostenlose Caching-Plugin für WordPress, welches die Blog-Performance steigert und Datenbankanfragen reduziert.

Mit zunehmender Anzahl an dynamischen Widgets, Templates und Plugins neigt ein WordPress-Blog dazu, träge zu werden. Unter Last des Besucheransturms häufen sich die Zugriffe auf die Datenbank, der Server hat durch die Abarbeitung flexibler Bereiche proportional mehr zu erledigen. Nicht verzögerungsfreie Auslieferung der Webseiten ist das Resultat der Belastung. Speziell für kleinere bis mittlere Projekte wurde Cachify entwickelt: smartes, übersichtliches Cache-Plugin, welches Seiteninhalte in statischer Form zwischenspeichert und Performance-schonend ausliefert. Dem Leser und Ranking zugute. Verfügbare Speichermethoden: Datenbank, APC, Festplatte und Memcached.

Installation

Cachify kann jederzeit im offiziellen WordPress-Pluginverzeichnis heruntergeladen werden: Download

Alternativ erfolgt die Installation direkt in WordPress im Administrationsbereich „Plugins“ → „Plugins hinzufügen“: Nach Cachify suchen, auswählen, installieren.

Nach der erfolgreichen Aktivierung des Plugins können verfügbare Cachify Einstellungen definiert werden. Im Auslieferungszustand verfügt Cachify über vordefinierte Optionen, so dass der Betrieb automatisch aufgenommen wird.

Funktionsweise

Zwar bietet Cachify nicht den Funktionsumfang einiger Monster-Plugins der Branche, das Caching-Plugin erfüllt jedoch den Zweck vollkommen und äußerst zuverlässig. Und das mit sehr minimalen Mitteln und überschaubarem Code. Dadurch bleibt es übersichtlich und schnell.

Was macht also Cachify? Ruft ein Besucher eine Blogseite auf, prüft das Cache-Plugin, ob diese Seite bereits im Cache als statischer Quelltext vorliegt. Im Positivfall kommt die zwischengespeicherte Version der Seite zur Ausgabe. Andernfalls befördert die smarte Cache-Lösung den aktuellen Seiteninhalt in den Zwischenspeicher, welcher sich je nach Einstellung in der WordPress-Datenbank, der Server-Festplatte oder im Server-Speicher via APC-Modul befindet. Beim nächsten Aufruf der Seite im Browser würde diese also aus dem Cache eingelesen und direkt an den Browser gesendet.

Der Vorteil der Technik wird schnell klar: Inhalte liegen in statischer Form zur Ausgabe vor und werden nicht erst durch unzählige Datenbankzugriffe und dynamische PHP-Scripte in die Ausgangsform zusammengeführt.

Zusätzlich profitiert auch die Ladezeit der Blogseiten, weil Webseiten prompter vom Server ausgeliefert werden. Im Testlabor konnte Cachify eine Reduzierung der Datenbankabfragen um 80 Prozent und die Ausführungszeit um bis zu 60 Prozent senken. Summa Summarum: Die Datenbank und der Server werden spürbar entlastet.

<!DOCTYPE html> <html lang="de-DE"> <!-- ... --> </html>

<!-- Cachify | http://cachify.de
Generated @ 23.05.2020 18:10:11 -->Code-Sprache: HTML, XML (xml)

Cachify im Einsatz: Plugin-Ausgabe im Quelltext

Cache-Reset: Automatisch und manuell

Nach neu angelegten oder modifizierten Beiträgen leert Cachify den kompletten Cache, da nach der Veröffentlichung des Artikels zu viele Veränderungen bzw. Verschiebungen innerhalb der Archivseiten zu erwarten sind. Ein effizienteres Management würde die Komplexität der Cache-Lösung steigern. Ausnahme: Änderungen an Kommentaren bewirken einen Neuaufbau des Cache ausschließlich für die betroffene Blogseite.

Ebenfalls zugunsten der Übersichtlichkeit und der Einfachheit des Codes stoßen selten ausgeführte Element-Aktionen wie beispielsweise neu angelegte Kategorien und Tags keinen Cache-Refresh an. Bei Bedarf die Cachify-Schaltfläche Cache leeren (Papierkorb-Icon) in der Admin Bar betätigen – daraufhin wird der aufbewahrte Zwischenspeicher eliminiert, mit der Neuindexierung der Daten wird begonnen. Netzwerkweit aktiviertes Plugin leert in diesem Fall den Cache aller Multisite-Blogs.

Die Einblendung der Schaltfläche “Cache leeren” kann über den Plugin-eigenen Filter cachify_user_can_flush_cache gesteuert werden. Im Lieferzustand bekommen alle WordPress-Nutzer mit der Rolle Administrator den Button angezeigt und können diesen für die Leerung des Cache-Bestandes nutzen.

Cachify-Cache leeren bequem in der WordPress Adminbar

Automatische Leerung des Cache-Vorrats

  • Nach Veröffentlichung neuer Beiträge
  • Nach Veröffentlichung neuer Seiten
  • Nach Veröffentlichung neuer Custom Post Types
  • Nach Veröffentlichung geplanter Beiträge (nur Cachify DB)
  • Nach WordPress-Aktualisierung
  • Beim Klick auf den Papierkorb-Button in der Adminleiste
  • Beim Speichern von Cachify-Optionen

– Interne Ausnahmeliste (Bereiche, die vom Cache ausgenommen sind)

  • Passwort-geschützte Seiten
  • Feeds
  • Trackbacks
  • Robots
  • Vorschau
  • Mobile-Themes (WP-Touch, Carrington, Jetpack Mobile)
  • Suche
  • Fehlerseiten
  • Sitemaps

Schlusswort

Die Dimension der Blogs mit eingesetztem Caching-Plugin ist sekundär: Das Ziel ist immer, die Datenbankanfragen und PHP-Ausführungen zu reduzieren, um den Server zu entlasten und die Anzeige-Geschwindigkeit zu beflügeln. Als Faustregel gilt: Je weniger Dynamik und Flexibilität, desto kluger der Cache, desto geschwinder die Webseiten.

Caching-Methoden

Cachify kann den Webseiten-Cache mithilfe von 4 unterschiedlichen Cache-Techniken verwalten: Datenbank, APC, Memcached (nur unter Nginx) und Festplatte. Nachfolgend werden notwendige Anpassungen an Server-Systemdateien ausführlich beschrieben.

Datenbank

Keine Erweiterung der Systemdatei vonnöten.

Der gecachte Inhalt wird direkt in der WordPress Datenbank gespeichert. Dies beschleunigt dennoch die Ladevorgänge der Seite, da der Inhalt nicht dynamisch generiert werden muss, sondern das zuvor generierte HTML direkt geladen wird.

APC (Alternative PHP Cache)

Ist APC (3.1.4 oder höher) als PHP-Erweiterung auf dem Server installiert, so steht innerhalb der Plugin-Einstellungen eine entsprechende Option zur Auswahl bereit. Nach der Aktivierung legt Cachify die generierten HTML-Ansichten der aufgerufenen Blogseiten im Cache der PHP-Extension (Shared Memory) ab und benötigt beim Aufruf der Blog-Seiten keinerlei Datenbankanfragen sowie dynamische PHP-Befehle. Beim Abruf der Blogseiten aus dem APC-Cache ist die Reaktions- und Rückgabezeit des Servers überdurchschnittlich schnell.

Für den Zugriff auf den APC-Zwischenspeicher bringt Cachify eine Vermittlungsdatei – liegend unter plugins/cachify/apc/proxy.php – mit. Diese sogenannte Proxy-Datei analysiert den Cache-Vorrat auf die Existenz der aktuell aufgerufenen Webseite, liest den Inhalt im Erfolgsfall ein und sendet ihn direkt an den Browser.

Die Ausgabedateien speichert Cachify in GZIP-komprimierter Form ab, sodass keinerlei Prozesse für zusätzliche GZIP-Komprimierungen und DEFLATE-Vorgänge seitens Webserver notwendig sind. Das Caching-Plugin übernimmt die Kompression und die korrekte Ausgabe an den Server. Prozessor- und Speicherplatz-schonend.

Die Einbindung der Proxy-Datei unterscheidet sich je nach Webserver. Im Grunde handelt es sich um einen auto_prepend_file Aufruf für PHP-Dateien, welcher abhängig vom Hoster und vergebenen Privilegien in .htaccess oder php.ini eingebunden wird.

Beispiel für .htaccess (Apache)

<Files index.php>
    php_value auto_prepend_file /absoluter pfad zu/plugins/cachify/apc/proxy.php
</Files>
Code-Sprache: Apache (apache)

Beispiel für nginx-Instanzen

location ~ .php {
    include fastcgi_params;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_param PHP_VALUE auto_prepend_file=/absoluter pfad zu/plugins/cachify/apc/proxy.php;

    location ~ /wp-admin/ {
        include fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_param PHP_VALUE auto_prepend_file=;
    }
}
Code-Sprache: Nginx (nginx)

Die Dateieinbindung dieser Art umgeht die zeitraubende Ausführung des nicht ganz “leichten” WordPress-Cores und spart alle Datenbankzugriffe ein. Positiver Nebeneffekt: Der WordPress-Quelltext bleibt unberührt und bleibt somit nach wie vor Upgrade-fähig.

Memcached (nur für nginx)

In Verbindung mit dem Webserver stellt Cachify eine weitere Caching-Methode zur Verfügung: Memcached. Nach der Auswahl der Plugin-Option (soweit verfügbar) und der Anpassung der Nginx-Konfigurationsdatei glänzt die Technik mit ihrer überragenden Geschwindigkeit, da der Cache vom Plugin im Arbeitsspeicher (RAM) des Servers ablegt und vom Webserver (Nginx) direkt an den Browser ausgeliefert wird.

Geschwinder und unkomplizierter kann eine Cache-Auslieferung nicht funktionieren. Perfektes Zusammenspiel zwischen Webserver und Memcached.

Erweiterung der nginx Konfigurationsdatei

## GZIP
gzip_static on;

## CHARSET
charset utf-8;

## INDEX LOCATION
location / {
	error_page 404 405 = @nocache;
 
	if ( $query_string ) {
		return 405;
	}
	if ( $request_method = POST ) {
		return 405;
	}
	if ( $request_uri ~ "/wp-" ) {
		return 405;
	}
	if ( $http_cookie ~ (wp-postpass|wordpress_logged_in|comment_author)_ ) {
		return 405;
	}

	default_type text/html;
	add_header X-Powered-By Cachify;
	set $memcached_key $host$uri;
	memcached_pass localhost:11211;
}

## NOCACHE LOCATION
location @nocache {
	try_files $uri $uri/ /index.php?$args;
}

Code-Sprache: Nginx (nginx)

Hinweise zu Nginx-Anpassungen

  • Bei Domains mit FQDN muss die Nginx-Variable $host gegen $http_host getauscht werden.
  • Wenn Sie Fehler haben, versuchen Sie bitte memcached_pass localhost:11211; zu memcached_pass 127.0.0.1:11211; zu ändern. Dies erzwingt IPv4, da einige Server, die ipv4 und ipv6 zulassen, so konfiguriert sind, dass sie memcached nur an ipv4 binden.

Warum nur für Nginx?

  • Apache bringt keine direkte Verknüpfung zu Memcached mit – ein Umweg über eine PHP-Datei müsste erfolgen (Analog zu Cachify APC), um von dort aus auf Caching-Daten zuzugreifen und auszugeben. Manko: Der PHP-Interpreter wird gestartet und beansprucht zeitintensive Ausführungszeit.
  • Die Ausführungszeit verlangsamt sich zusätzlich, da ausgelesene Memcached-Daten vom PHP-Skript zunächst GZIP-komprimiert werden müssten, falls die Kompression auf der Serverebene abgestellt ist.
  • Memcached (nicht Memcache) ist auf kaum einem Apache-Webserver installiert. Selbst große Hoster bieten das Modul nicht an, da zuverlässige und Nutzer-separierte Speicherverwaltung nicht sichergestellt werden kann.

Nach zahlreichen Tests und Analysen steht fest, dass die Speicherung der Webseiten in Memcache in Verbindung mit einem Apache-Webserver keinen erwarteten Performance-Gewinn mit sich bringt – Cachify HDD als Caching-Art ist in diesem Fall viel effizienter.

Auf Webservern mit Nginx sieht es ganz anders aus: Nginx ist in der Lage auf den Memcached-Bestand zuzugreifen und komprimiert auszuliefern. Ohne Zwischenschritte und in erwarteter Performance. Das Nginx-Modul HttpMemcachedModule gehört stets zum Lieferumgang des Webservers (Nginx).

Warum kein Memcache?

Die Binary-Implementierung von Memcache (also nicht Memcached) ist extrem fehlerhaft, so dass Daten nicht zuverlässig aufbewahrt werden können.

Festplatte (HDD Cache)

Ist die Festplatte als Aufbewahrungsort für den Cache ausgewählt, legt Cachify die generierten HTML-Ansichten der angeforderten Blogseiten auf der HDD des Webservers ab – pro Webseite eine HTML-Datei. Der Server übernimmt dabei die Umleitung auf die zuständige Cache-Datei. Der Start des PHP-Interpreters entfällt dabei gänzlich und sorgt somit für einen zusätzlichen Performance-Schub.

Bevor die Option in den Cachify-Einstellungen ausgewählt wird, sollte im WordPress-Verzeichnis wp-content ein neuer Ordner namens cache mit 777 als Rechte angelegt werden (später auch gerne restriktiver, falls die Funktionsweise des Plugins nicht beeinträchtigt wird). Existiert dieser Pfad bereits sind nur die Berechtigungen zu kontrollieren. Das Plugin wird zwar versuchen, den Ordner selbst zu anzulegen, doch im Fehlerfall würde das Skript mit einem Hinweis aussteigen. Aus diesem Grund lieber vorsorglich selbst Hand anlegen.

Die Vermittlung zwischen dem Seitenaufruf im Browser und der existierenden Cache-Datei steuert der Webserver: Apache oder Nginx. Entsprechend gehört diese Aufgabe an den Server delegiert. Dies geschieht durch eine Erweiterung der Apache-Datei .htaccess oder der Nginx-Konfigurationsdatei. Beispiele für Implementierungen folgen weiter unten.

Zusätzlich zu einer HTML-Variante der Webseiten fertigt Cachify eine GZIP-komprimierte Version an. Der Server greift auf die komprimierte Datei zurück und verzichtet dabei auf die eigene, zeitaufwändige Kompression der Inhalte. Man spart dabei CPU-Last, da Dateien bereits (vor)komprimiert sind.

Eine Beschreibung für nur https und Websites, die sowohl unter https und http erreichbar sind folgt weiter unten.

Erweiterung der .htaccess (Apache), wenn die Website nur über http erreichbar ist

# BEGINN CACHIFY
<IfModule mod_rewrite.c>
    # ENGINE ON
    RewriteEngine On

    # GZIP FILE
    <IfModule mod_mime.c>
        RewriteCond %{REQUEST_URI} /$
        RewriteCond %{REQUEST_URI} !^/(wp-admin|wp-content/cache)/.*
        RewriteCond %{REQUEST_METHOD} !=POST
        RewriteCond %{QUERY_STRING} =""
        RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
        RewriteCond %{HTTP:Accept-Encoding} gzip
        RewriteCond %{DOCUMENT_ROOT}/pfad zu/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html.gz -f
        RewriteRule ^(.*) /pfad zu/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html.gz [L]

        AddType text/html .gz
        AddEncoding gzip .gz
    </IfModule>

    # HTML FILE
    RewriteCond %{REQUEST_URI} /$
    RewriteCond %{REQUEST_URI} !^/(wp-admin|wp-content/cache)/.*
    RewriteCond %{REQUEST_METHOD} !=POST
    RewriteCond %{QUERY_STRING} =""
    RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
    RewriteCond %{DOCUMENT_ROOT}/pfad zu/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html -f
    RewriteRule ^(.*) /pfad zu/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html [L]
</IfModule>
# END CACHIFY
Code-Sprache: Apache (apache)

.htaccess-Erweiterung für Websites, die sowohl unter http als auch https erreichbar sind: (https://gist.github.com/mcguffin/31f80070d631d56da23cefb4ef1b6649)

Hinweise zu .htaccess Anpassungen

  • Innerhalb der .htaccess besitzt die obige Erweiterung eine höhere Priorität und muss daher oberhalb der WordPress Rewrite-Regeln (markiert meist durch # BEGIN WordPress … # END WordPress) platziert werden.
  • Ist die Website nur über SSL/TLS erreichbar, so muss /wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html in /wp-content/cache/cachify/https-%{HTTP_HOST}%{REQUEST_URI}index.html abgeändert werden.
  • Einige (wenige) Hoster (domainFACTORY und 1und1 gehören dazu) stellen die Apache-Variable %{DOCUMENT_ROOT} nicht zur Verfügung. Das führt zu einem unvollständigen Datei-Pfad. In solchen Fällen bitte den Document-Pfad manuell (statt Variable) voranstellen, siehe Anleitung DOCUMENT_ROOT in .htaccess durch Serverpfad ersetzen.
  • Änderungen an der Datei .htaccess können nicht vorgenommen werden, wenn PHP als fcgi ausgeführt wird.
  • Kommt es teilweise zu fehlerhaften Weiterleitungen innerhalb des Blogs, so kann die Abschaltung des Apache Content Cache Abhilfe schaffen.
<IfModule mod_cache.c>
	CacheDisable /
</IfModule>Code-Sprache: HTML, XML (xml)
  • Ist in WordPress das WPTouch-Plugin (oder ein anderes Mobile-Plugin) installiert, müssen RewriteRules erweitert werden.

Erweiterung der Nginx-Konfigurationsdatei:

## GZIP
gzip_static on;
 
## CHARSET
charset utf-8;
 
## INDEX LOCATION
location / {
    if ( $query_string ) {
        return 405;
    }
    if ( $request_method = POST ) {
        return 405;
    }
    if ( $request_uri ~ /wp-admin/ ) {
        return 405;
    }
    if ( $http_cookie ~ (wp-postpass|wordpress_logged_in|comment_author)_ ) {
        return 405;
    }

    error_page 405 = @nocache;

    try_files /wp-content/cache/cachify/https-${host}${uri}index.html /wp-content/cache/cachify/${host}${uri}index.html @nocache;
}
 
## NOCACHE LOCATION
location @nocache {
    try_files $uri $uri/ /index.php?$args;
}
 
## PROTECT CACHE
location ~ /wp-content/cache {
    internal;
}
Code-Sprache: PHP (php)

Hinweise zu Nginx-Anpassungen

  • Bei Domains mit FQDN muss statt ${host} die Variable ${http_host} verwendet werden.

Allgemeine Hinweise zu Cachify HDD

  • Das HDD-Caching in Cachify kann nur bei aktivierten WordPress-Permalinks ausgewählt und genutzt werden. Ein Schrägstrich am Ende des Permalinks wird ebenfalls vorausgesetzt. Für Permalinks ohne Slash am Ende ist die Nutzung eines speziellen .htaccess-Snippets vonnöten. Der Snippet-Code ersetzt den oben vorgestellten .htaccess-Eintrag.
  • Befindet sich der Blog in einem Unterverzeichnis und die dazugehörige .htaccess außerhalb des Blog-Verzeichnisses, gehört der Pfad zum Cache-Ordner angepasst.
  • Aus technischen Gründen kann bei dieser Caching-Methode die Plugin-Einstellung Kein Cache-Aufbau durch angemeldete Benutzer nicht automatisch berücksichtigt werden. Soll in WordPress angemeldeten und kommentierenden Nutzern ebenfalls die Cache-Version der Blogseiten angezeigt werden, müssen die beiden Zeilen mit der Cookie-Abfrage (RewriteCond %{HTTP_COOKIE}) im obigen Code einkommentiert werden (Raute davor stellen). Die Option Kein Cache-Aufbau durch angemeldete Benutzer muss dennoch aktiviert bleiben.
  • Die eingestellte Cache-Gültigkeitsdauer kann nicht einbezogen werden. Muss der Cache-Bestand in bestimmten Zeitabständen geleert werden, so empfiehlt sich der Aufruf einer präparierten PHP-Datei per Cronjob.
  • Dadurch, dass Cachify HDD auf PHP verzichtet und die WordPress-Ausführung umgeht, können bei dieser Methode keine geplanten WordPress-Beiträge ausgeführt werden. Eine brauchbare Alternative wäre der Aufruf der WordPress-Datei wp-cron.php (zu lokalisieren im Hauptverzeichnis der WordPress-Instanz) mithilfe eines Server-Cronjobs (Hoster fragen) oder eines Dienstleisters wie z.B. cronjob.de.

Einstellungen

Einstellungsmöglichkeiten sind auf der Plugin-Optionsseite nach Wünschen und Gegebenheiten frei veränderbar. Nach dem Speichern der Optionen leert sich der Website-Cache und vorgenommene Einstellungen beginnen mit ihrer Wirkung. Nachfolgend werden einzelne Plugin-Optionen erklärt.

Cachify Einstellungs-Seite

Cache-Methode

Es sind 4 Methoden für die Zwischenspeicherung der Inhalte verfügbar. Zu beachten ist, dass bei APC, Memcached und Festplatte diverse Anpassungen an Server-Konfigurationsdateien notwendig sind (siehe dazu hier).

  • Datenbank steht immer zur Verfügung.
  • APC nur bei installiertem Alternative PHP Cache ab Version 3.1.4.
  • Memcached bei aktivem Memcached aufgesetzt auf Nginx.
  • Festplatte als Caching-Art kann ausschließlich bei aktivierten WordPress-Permalinks genutzt werden.

Cache-Gültigkeit

Aufbewahrungsdauer der Inhalte im Cache in Stunden. Funktionsweise: Erreicht die Lebensdauer einer Webseite im Cache den festgelegten Zeitraum, wird dieser Eintrag aus dem Cache entfernt und durch aktuelleren Inhalt ersetzt. Bei CMS-Seiten lohnt sich eine Zahl im Monatsbereich. Eine 0 (Null) bedeutet einen unbefristet gültigen Cache. Bei Festplatte als Caching-Art kann diese Option aus technischen Gründen nicht berücksichtigt werden.

Cache-Generierung

Kein Cache-Aufbau durch angemeldete Benutzer

In aktivierter Form sorgt die Checkbox dafür, dass alle Blogleser ausgenommen eingeloggte und bereits kommentierende Nutzer den Cache initialisieren dürfen und die zwischengespeicherte Version einer Blogseite angezeigt bekommen. Praktisch, wenn angemeldete Blog-Autoren und Administratoren beispielsweise die integrierte Admin-Bar oder Editieren-Links im Theme eingeblendet bekommen, die gewiss nicht zum Bestandteil der zwischengespeicherten Cache-Seite werden sollen.

Nicht aktivierte Option bedeutet, angemeldete und kommentierende Nutzer sehen identische Ausgabe der Webseiten wie gewöhnliche Besucher (es wird also nicht unterscheiden und alle sehen alles gleich). Andernfalls dürfen angemeldete und kommentierende Nutzer keine Cache-Variante der Seite erzeugen bzw. ausgeliefert bekommen.

Bei APC, Memcached und Festplatte als Caching-Methode muss zusätzlich zur Option eine Anpassung der Server-Systemdatei (.htaccess etc.) vorgenommen werden, siehe dazu hier.

Cache bei modifizierten Beiträgen leeren

Ist diese Schaltfläche aktiviert, wird der gesamte Website-Cache geleert, wenn ein Beitrag bearbeitet wurde. Andernfalls wird nur der bearbeitete Beitrag selbst aus dem Cache entfernt.

Diese Option kann hilfreich sein, falls Menüs aktualisiert werden müssen, automatische Verlinkungen genutzt werden oder aus anderen Gründen weitere Seiten oder Beiträge von der Änderung betroffen sind.

Diese Option wurde in Cachify 2.3 eingeführt und löst die im klassischen Editor verfügbare Einstellmöglichkeit pro Beitrag ab.

Cache bei neuen Kommentaren leeren

Die aktivierte Option setzt den kompletten Cache-Bestand bei neuen Kommentaren zurück. Kann nützlich sein, um die dynamische Ausgabe der Kommentaranzahl pro Beitrag auf Blogseiten wie die Startseite, Archivseiten, etc. aktuell zu halten.

Diese Funktion wird ausschließlich auf kleineren Projekten empfohlen, wo selten kommentiert wird, da der Cachify-Cache andernfalls zu oft neu aufgebaut werden müsste.

Cache-Ausnahmen

Beitrags-/Seiten-IDs

Eine Komma-separierte Liste von Beitrags- und/oder Seiten-IDs, die vom Cache ausgeschlossen werden sollen.

Beispiel: 1, 2, 3

Zusätzlich kann der Filter-Hook cachify_skip_cache verwendet werden, um das Verhalten weiter einzuschränken.

Browser User-Agents

Eine Komma-separierte Liste von User Agents (gerne nur der wesentliche Teil des Strings), die vom Cache ausgeschlossen werden sollen.

Beispiel: MSIE 6, Opera

Diese Option kann hilfreich sein, falls abweichende Darstellungen für bestimmte (z.B. ältere) Browser generiert werden, die nicht repräsentativ für die Mehrheit der Besucher sind.

Cache-Minimierung

Minimierung (Minification) der Browser-Ausgabe. Überflüssige Zeichen wie Zeilenumbrüche und Kommentare werden aus dem generierten HTML-Code der Webseite entfernt, bevor diese im Cache gespeichert werden.

Wird die Ausgabe der Blogseite hierdurch negativ beeinflusst (z.B. fehlen bestimmte Inhalte oder brechen mit dem Layout), sollte diese Option entweder deaktiviert oder nur auf HTML beschränkt werden.

Über den Filter-Hook cachify_minify_ignore_tags können bestimmte HTML Tags von der Minimierung ausgenommen werden.

Cache-Signatur

Falls gewünscht, kann ab Cachify 2.3 die Ausgabe der Signatur in Form eines HTML-Kommentars am Ende des gecachten Markups erweitert werden.

Standardmäßig wird nur eine kurze Information mit Zeitpunkt der Generierung erzeugt:

<!DOCTYPE html> <html lang="de-DE"> <!-- ... --> </html>

<!-- Cachify | http://cachify.de
Generated @ 02.02.2020 10:11:12 -->Code-Sprache: HTML, XML (xml)

Die erweiterten Ausgaben enthalten zusätzliche Daten zur verwendeten Methode:

<!DOCTYPE html> <html lang="de-DE"> <!-- ... --> </html>

<!-- Cachify | http://cachify.de
DB Cache @ 02.02.2020 10:11:12
Without Cachify: 19 DB queries, 0.55 seconds, 5.67 MB
With Cachify: 12 DB queries, 0.11 seconds, 3,45 MB
-->Code-Sprache: HTML, XML (xml)

Erweiterte Nutzung

Steuerung der Cache-Leerung bei Artikel-Updates

Bei der Aktualisierung von Artikeln kann die notwendige Cache-Leerung manuell beeinflusst werden. Autoren können die Entscheidung treffen, ob nach der Speicherung der Artikeländerung der komplette Cachify-Cache oder nur der Cache der betroffenen Seite entfernt werden soll – praktisch, wenn die getätigte Änderung nur die eine Seite betrifft und keinerlei (optische) Auswirkungen auf die restlichen Webseiten haben.

Cachify Publish-Status

Cachify Cache-Status beim Update der Artikel

Verfügbare Optionen in der Auswahlbox:

  • Gesamtcache löschen – leert den gesamten Cachify-Cache
  • Seitencache löschen – entfernt lediglich den Cache des Artikels

Die Auswahl ist nur bei bereits veröffentlichten Artikeln, Seiten und Post Types zugänglich. Die zuletzt selektierte Option wird Benutzerabhängig gespeichert und beim nächsten Aufruf der Artikel-Bearbeitungsseite vorausgewählt.

Wissenswertes

Einige Zusatzinformationen für die Arbeit mit dem Caching-Plugin.

Cachify-Größe auf dem Dashboard

Cachify Cache-Größe auf dem Dashboard

Nutzung des Browser-Cache

Auf Wunsch kann die HTML-Ausgabe der Blogseiten zusätzlich im Cache der Browser aufbewahrt werden – für einen frei wählbaren Zeitraum. Diese Technik eignet sich dann, wenn ein Projekt über wenig Dynamik verfügt (keine Kommentare, selten Artikel etc.). In solchen Fällen verfügt der Browser über eine lokale Kopie einer Blogseite, die nach definierter Zeit abläuft.

Für beispielsweise einen einstündigen Browser-Cache muss die .htaccess bzw. Nginx-Serverdatei wie abgebildet komplettiert werden:

Browser-Cache in .htaccess (Apache)

<IfModule mod_expires.c>
    <FilesMatch ".(html|html.gz)$">
        ExpiresActive On
        ExpiresDefault "access plus 1 hour"
    </FilesMatch>
</IfModule>Code-Sprache: Apache (apache)

Browser-Cache bei Nginx (platziert zwischen error_page und try_files)

expires 1h;Code-Sprache: Nginx (nginx)

Anpassung der robots.txt

Damit Google und andere Suchmaschinen den statischen Inhalt des Cache-Ordners nicht indexieren (führt sonst zum doppelten Content), sollte die im Hauptverzeichnis einer WordPress-Installation befindliche Datei robots.txt erweitert werden, indem der Pfad zum Ordner mit Cache-Dateien gesperrt (disallow) wird. Und so könnte eine robots.txt aussehen:

User-agent: *
Disallow: /wp-content/cache/cachify/
Allow: /Code-Sprache: Apache (apache)

Cache-Leerung aus Drittanwendungen

Für den Fall, dass der Cachify Cache aus WordPress-Drittanwendungen geleert werden soll, stehen innerhalb des Plugins (ab Cachify 2.0.3) ausführbare Aktionen zur Verfügung:

if ( has_action('cachify_flush_cache') ) {
    do_action('cachify_flush_cache');
}

if ( has_action('cachify_remove_post_cache') ) {
    do_action('cachify_remove_post_cache', 123); // postID
}Code-Sprache: PHP (php)

Hooks

Hooks erlauben es dem Nutzer, den Funktionsumfang eines WordPress-Plugins zu erweitern. Nachfolgende Hooks sind in Cachify hinterlegt und lassen sich via Code ansprechen bzw. steuern.

cachify_skip_cache

Typ: Filter (Boolean)
Implementierung: Cachify 2.1.1

Anpassung der Ausnahmeliste von Seiten, die nicht gecacht werden sollen.

Bei Rückgabewert true wird der Aufbau des Caches für den aktuellen Aufruf übersprungen. Für false wird die Generierung fortgesetzt.
Die interne Ausnahmeliste wird hierdurch nicht beeinflusst.

Code Beispiele:

Cache-Ausnahme für die Kategorie „Example“
add_filter(
    'cachify_skip_cache',
    function( $previous_result ) {
    	return (
    	    in_category('example') ? true : false
    	);
    }
);Code-Sprache: PHP (php)
Cache-Ausnahme für die Startseite
add_filter(
    'cachify_skip_cache',
    function() {
    	return is_home();
    }
);Code-Sprache: PHP (php)

cachify_minify_ignore_tags

Typ: Filter (Array)
Implementierung: Cachify 2.0.9

Passt die Liste von HTML tags an, die bei der Minifizierung der Browser-Ausgabe ignoriert werden. Standardmäßig sind vorformatierte Textblöcke <pre> und Eingabeblöcke <textarea> ausgeschlossen.

Code Beispiele:

add_filter(
    'cachify_minify_ignore_tags',
    function( $ignored_tags ) {
        /*
         * Standardwert:
         * $ignore_tags = array(
         *   'textarea',
         *   'pre',
         * );
         */
        $ignored_tags[] = 'custom-tag';
        
        return $ignored_tags;
    }
);Code-Sprache: PHP (php)

cachify_user_can_flush_cache

Typ: Filter (Boolean)
Implementierung: Cachify 1.2

Dieser Hook ermögliche die Anpassung der Benutzer, die den Cache leeren dürfen.
Standardmäßig ist dies für Administratoren mit der Benutzerrolle manage_options vorgesehen. Ein Rückgabewert true erlaubt dem aktuellen Benutzer diese Funktion auszuführen.

Code Beispiel:

add_filter( 'cachify_user_can_flush_cache', '__return_true' );Code-Sprache: PHP (php)

cachify_store_item

Typ: Filter (Boolean)
Implementierung: Cachify 2.3

Letzte Filterung, bevor die Daten gespeichert werden.

Dieser Hook erhält bis zu 5 Parameter:

  • bool $should_cache – Soll der aktuelle Aufruf gecacht werden? (Default: true)
  • string $data – Die aufbereiteten Daten für den Cache.
  • object $method – Instanz des verwendeten Caching-Backends.
  • string $cache_hash – Hash (Cache Key) des aktuellen Aufrufs.
  • int $cache_expires – Gültigkeit des Cache-Eintrags in Sekunden.

Es gibt 2 mögliche Rückgabewerte:

  • true – Der aktuelle Eintrag soll gespeichert werden (Default)
  • false – Der aktuelle Eintrag soll nicht gespeichert werden.

Code Beispiel:

add_filter(
    'cachify_minify_ignore_tags',
    function( $should_cache, $data, $method, $cache_hash, $cache_expires ) {
        // Kein Cache für Markup bis 1000 Zeichen.
        return strlen( $data ) > 1000;
    },
    5,
    10
);Code-Sprache: PHP (php)

cachify_flush_cache_hooks

Typ: Filter (Array)
Implementierung: Cachify 2.3

Anpassung der Action Hooks, die eine Leerung des gesamten Caches auslösen.

Dieser Hook erhält ein assoziatives Array aller Hooks mit dem Namen des Hooks als Schlüssel und der Priorität als Wert.

Code Beispiel:

add_filter(
    'flush_cache_hooks',
    function( $hooks ) {
        /*
         * $hooks = array(
         *   'cachify_flush_cache'        => 10,
         *   '_core_updated_successfully' => 10,
         *   'switch_theme'               => 10,
         *   'before_delete_post'         => 10,
         *   'wp_trash_post'              => 10,
         *   'create_term'                => 10,
         *   'delete_term'                => 10,
         *   'edit_terms'                 => 10,
         *   'user_register'              => 10,
         *   'edit_user_profile_update'   => 10,
         *   'delete_user'                => 10,
         * );
         */
         $hooks[] = 'my_custom_action';

         return $hooks;
    },
    5,
    10
);Code-Sprache: PHP (php)

cachify_flush_cache

Typ: Action
Implementierung: Cachify 2.0.3

Dieser Hook ermöglicht das Leeren des gesamten Caches durch eine Drittanwendung, z.B. ein anderes Plugin.

Code Beispiel:

 if ( has_action( 'cachify_flush_cache' ) ) { 
     do_action( 'cachify_flush_cache' ); 
 }Code-Sprache: PHP (php)

cachify_remove_post_cache

Typ: Action
Implementierung: Cachify 2.0.3

Dieser Hook ermöglicht das Entfernen eines einzelnen Posts aus dem Cache. Dabei wird die Post ID als Parameter übergeben.

Code Beispiele:

if ( has_action( 'cachify_remove_post_cache' ) ) {
    do_action( 'cachify_remove_post_cache', 123 );
}Code-Sprache: PHP (php)

Häufig gestellte Fragen

Hat das Online-Handbuch nicht alle Fragen beantwortet? Vielleicht helfen die nachfolgenden Antworten auf die häufig gestellten Fragen.

Keine Cache-Gültigkeitsoption bei der Verwendung des HDD-Caches?

Der Cache-Ablauf kann aus technischen Gründen nicht berücksichtigt werden. Falls der Cache-Bestand nach bestimmten Zeitintervallen geleert werden muss empfiehlt es sich eine PHP-Datei über einen Cronjob aufzurufen.

PHP Fatal error: Cannot use output buffering in output buffering display handlers in Unknown on line 0

Nach der Inbetriebnahme des Caching-Plugins kann es zu abgebildeter Fehlermeldung kommen. Der Hinweis erscheint, weil keine Cache-Festplattendateien zur Ausgabe existieren. Das liegt vermutlich daran, dass Cachify keine Files im Cache-Ordner ablegen konnte. Bitte Schreibrechte für den Cache-Ordner (zu finden im WordPress-Verzeichnis wp-content) prüfen und ggf. korrekt setzen.

Meine Website sieht nach der Aktivierung von Cachify in einigen Teilen kaputt aus!

Bitte stellen Sie sicher, dass es kein Problem durch die Cache-Minimierungsfunktion gibt. Deaktivieren Sie es oder verwenden Sie nur HTML. Falls das Problem weiterhin besteht, können Sie es in den [Support-Foren] (https://wordpress.org/support/plugin/cachify) melden. Mit dieser Funktion werden alle unnötigen Zeichen wie Umbrüche und HTML-Kommentare aus dem Quellcode entfernt.

Cachify HDD: Zeichenkodierung funktioniert nicht korrekt

Durch die Umstellung auf Cachify HDD wird kein PHP ausgeführt. Bei falsch konfigurierten Servern kann dadurch zur fehlerhaften Darstellung der Sonderzeichen auf Webseiten kommen. Der Fehler lässt sich durch eine Erweiterung der Systemdatei .htaccess beheben: AddDefaultCharset UTF-8

CDN-Unterstützung in Cachify?

Aktuell verfügt das Caching-Plugin für WordPress über keine Anbindung an einen CDN-Anbieter. Zwar wird das Buzzword CDN (Content Delivery Network) als Performance-Faktor angepriesen, für WordPress-Websites mit nationalem Publikum macht CDN wenig Sinn.

PHP OPcache als Caching-Methode?

Im Vergleich zu APC (Alternative PHP Cache) ist PHP OPcache nicht in der Lage, Inhalte mit benutzerdefinierten Schlüsseln (Keys) und Werten (Values) aufzunehmen. Aus diesem Grund kann Cachify den PHP OPcache als Caching-Methode nicht berücksichtigen.

Wann leert Cachify automatisch seinen Cache?

  • Nach Veröffentlichung neuer Beiträge
  • Nach Veröffentlichung neuer Seiten
  • Nach Veröffentlichung neuer Custom Post Types
  • Nach Veröffentlichung geplanter Beiträge (nur Cachify DB)
  • Nach WordPress-Aktualisierung
  • Beim Klick auf den Papierkorb-Button in der Adminleiste
  • Beim Speichern von Cachify-Optionen

Welche Bereiche der Website werden nicht standardmäßig gecached?

  • Passwort-geschützte Seiten
  • Feeds
  • Trackbacks
  • Robots
  • Vorschau
  • Mobile-Themes (WP-Touch, Carrington, Jetpack Mobile)
  • Suche
  • Fehlerseiten
  • Sitemaps

Der Cache-Ordner wird von Suchmaschinen indexiert!

Um sicherzustellen, dass Google und andere Suchmaschinen den statischen Inhalt des Cache-Ordners nicht indexieren (sonst könnte es doppelte Inhalte geben), sollte die im Hauptverzeichnis einer WordPress-Installation befindliche Datei robots.txt erweitert werden, indem der Pfad zum Ordner mit Cache-Dateien gesperrt (disallow) wird. Dieses Problem sollte nur auftreten, wenn eine statische robots.txt verwenden wird oder der wp-content-Pfad geändert wurde. Und so könnte eine robots.txt aussehen:

User-agent: *
Disallow: /wp-content/cache/cachify/
Allow: /Code-Sprache: Apache (apache)