Cachify: Smartes, effizientes Caching-Plugin für WordPress

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.

Sprungmarken

• Features
• Funktionsweise
• Einstellungen
• Caching-Methoden
• Taschenbuch & eBook
• Download
• Häufige Fragen
• Versionsverlauf

Features

Warum ausgerechnet Cachify? Mehrere Gründe sprechen dafür:

• Kostenlos und werbefrei
• Unterschiedliche Caching-Arten
• Kompakt und übersichtlich
• Performance-steigernd (Performance als Rankingfaktor)
• Multisite-fähig
• Deutschsprachige Bedienoberfläche
• Lauffähig unter Apache und Nginx
• Komplett dokumentiert
• Buch in gedruckter und digitaler Form

Funktionsweise

Mit Sicherheit kann Cachify mit Monster-Plugins der Branche nicht mithalten, das Caching-Plugin erfüllt jedoch den Zweck vollkommen und äußerst zuverlässig. Und das mit sehr minimalen Mitteln und überschaubarem Code.

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.

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 stossen 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.

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- und wpSEO-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

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.

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.

Verfügbare Optionen in Cachify

– Aufbewahrungsort für Cache
Drei verfügbare Methode für die Zwischenspeicherung der Inhalte. Zu beachten ist, dass bei APC und Festplatte diverse Anpassungen an Server-Konfigurationsdateien notwendig sind (siehe weiter unten).

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

– Cache-Gültigkeit in Stunden
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.

– Minimierung der Ausgabe
Minimierung (Minification) der HTML-Ausgabe. Überflüssige Zeichen wie Umbrüche und HTML-Kommentare werden entfernt. Geht der Quelltext der Webseite stellenweise kaputt (z.B. Werbebanner sind verschwunden), so muss die Option deaktiviert werden. Bei Google AdSense-Bannern empfiehlt es sich, HTML-Kommentare aus dem Snippet zu entfernen.

– Ausnahme für (Post/Page) IDs
Erweiterung der Ausnahmeliste für einzelne Blogseiten. Eine Komma-separierte Liste an Post- und/oder Page-IDs, die vom Cache ausgeschlossen werden sollen.
Beispiel: 1, 2, 3

– Ausnahme für User Agents
Erweiterung der Ausnahmeliste für einzelne Browser. Komma-separierte Liste der User Agents (gerne nur der wesentliche Teil des Strings), die vom Cache ausgeschlossen werden sollen.
Beispiel: MSIE 6, Opera

– Kein Cache für eingeloggte bzw. kommentierende Nutzer
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 und Festplatte als Caching-Methode muss zusätzlich zur Option eine Anpassung der Server-Systemdatei (.htaccess etc.) vorgenommen werden, siehe dazu Informationen unten.

Caching-Methoden

Wie oben bereits erwähnt, kann Cachify den Webseiten-Cache mithilfe von 3 unterschiedlichen Cache-Techniken verwalten: Datenbank, APC und Festplatte. Nachfolgend werden notwendige Anpassungen in Server-Systemdateien ausführlich beschrieben.

– Datenbank
Keine Erweiterung der Systemdatei vonnöten.

– APC (Alternative PHP Cache)
Ist APC (3.1.4 empfohlen) 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 /pfad/plugins/cachify/apc/proxy.php
</Files>

Beispiel für nginx-Instanzen:

location ~ \.php {
    include fastcgi_params;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_param PHP_VALUE auto_prepend_file=/pfad/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=;
    }
}

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.

– Festplatte (HDD Cache)
Ist Festplatte als Aufbewahrungsort für 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 Cachify-Einstellungen ausgewählt ist, gehört im WordPress-Verzeichnis wp-content ein neuer Ordner namens cache mit 777 als Rechte angelegt (später gern auch kleiner, wenn 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 erzeugen, doch im Fehlerfall würde das Skript mit einem Hinweis aussteigen. Aus diesem Grund lieber vorsorgen.

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.

Erweiterung der .htaccess (Apache)

# BEGINN CACHIFY
<IfModule mod_rewrite.c>
	# ENGINE ON
	RewriteEngine On
 
	# GZIP FILE
	<IfModule mod_mime.c>
		RewriteCond %{REQUEST_URI} /$
		RewriteCond %{REQUEST_URI} !^/wp-admin/.*
		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}/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}/index.html.gz -f
		RewriteRule ^(.*) /wp-content/cache/cachify/%{HTTP_HOST}/$1/index.html.gz [L]
 
		AddType text/html .gz
		AddEncoding gzip .gz
	</IfModule>	
 
	# HTML FILE
	RewriteCond %{REQUEST_URI} /$
	RewriteCond %{REQUEST_URI} !^/wp-admin/.*
	RewriteCond %{REQUEST_METHOD} !=POST
	RewriteCond %{QUERY_STRING} =""
	RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
	RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}/index.html -f
	RewriteRule ^(.*) /wp-content/cache/cachify/%{HTTP_HOST}/$1/index.html [L]
</IfModule>
# END CACHIFY

Hinweise zu .htaccess Anpassungen

• Die obige Änderung besitzt innerhalb der .htaccess eine höhere Priorität und positioniert sich bestenfalls oberhalb der WordPress Rewrite-Regeln (markiert meist durch # BEGIN WordPress … # END WordPress).
• 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.

Erweiterung für Nginx

## 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/${host}${uri}index.html @nocache;
}
 
## NOCACHE LOCATION
location @nocache {
	try_files $uri $uri/ /index.php?$args;
}

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. Beispiel als Gist.
• Aus technischen Gründen kann bei dieser Caching-Methode die Plugin-Einstellung Kein Cache für eingeloggte bzw. kommentierende Nutzer nicht automatisch berücksichtigt werden. Sollen in WordPress angemeldete und kommentierende Nutzer ebenfalls die Cache-Version der Blogseiten angezeigt bekommen, müssen im obigen Code die beiden Zeilen mit der Cookie-Abfrage (RewriteCond %{HTTP_COOKIE}) einkommentiert werden (Raute davor stellen). Die Option Kein Cache für eingeloggte bzw. kommentierende Nutzer muss deaktiviert 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 der Server-Cronjobs (Hoster fragen oder selbst einrichten) oder eines Dienstleisters wie cronjob.de

Wissenswertes

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

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>

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

expires 1h;

- 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/
Allow: /

- Cache-Leerung aus Drittanwendungen
Für den Fall, dass der Cachify Cache aus einer WordPress-Anwendung geleert werden soll, steht innerhalb des Plugins (ab Cachify 2.0.3) eine ausführbare Aktion zur Verfügung:

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

- Weiterführende Links mit Analysen

• WordPress-Performance mit Nginx und Cachify
• Cachify DB vs. Cachify HDD
• Cachify vs. W3TC
• Vergleich der Cachify Caching-Methoden
• Ani-GIF: Cachify vs. Hyper Cache
• Reaktionszeiten mit und ohne Cachify APC

Taschenbuch & eBook

Zugegeben ist die obige Plugin-Beschreibung nicht unbedingt sofort verständlich, da doch (zu) viele Optionen und Funktionen ausführlich vorgestellt werden. Aus diesem Grund wurde für Cachify und allgemein das Thema Caching in WordPress ein Buch erarbeitet und auf Amazon als Kindle eBook und gedrucktes Taschenbuch zum Kauf gestellt.

Verfügbare Formate

• WordPress Performance Kindle eBook
• Für EUR 2,99 erwerben (Partnerlink)

• WordPress Performance Taschenbuch
• Für EUR 6,99 erweben (Partnerlink)

WordPress Performance Buch-Cover

Im Buch geht es darum zu verstehen, wie das Caching-Plugin Cachify der WordPress-Performance positiv beiträgt, welche Techniken zur Beschleunigung der Webseiten existieren und woran die Unterschiede liegen. Schritt für Schritt wird Cachify in Betrieb genommen und mit empfohlenen Optionen versehen. Auch Ratschläge zu Optimierungsmaßnahmen auf Seiten des Servers und Browsers bringt das Buch im Lieferumfang mit.

Die Zielsetzung der Buchkapitel: Einsteiger und nicht unbedingt technisch versierte Blogger nehmen Geschwindigkeitsoptimierungen am Blog selbsttätig vor, ohne Modifizierungen am WordPress-Theme vorzunehmen und ohne eine Handvoll an Caching-Plugins zu installieren. Reinblättern lohnt sich also.

Der Buchkauf unterstützt die Weiterentwicklung des Caching-Plugins. Von jedem Verkauf (unabhängig vom Format) bekommt der Autor ca. 2 € ausgezahlt.

Download

› Cachify – Caching für WordPress ↓

Flattr
Unterstützung via Flattr ist jederzeit willkommen. Danke.

Mindestanforderungen

• WordPress 3.4
• PHP 5.2.4
• APC 3.1.4 (optional)

Hinweise

• Es ist mit einem Zuwachs der Datenbank- bzw. Festplattengröße zu rechnen.
• Ist hier im Playground im produktiven Einsatz (Cachify HDD).
• Nach der Inbetriebnahme sind Blogseiten auf Fehlerfreiheit zu überprüfen.
• Alle Aktionen an Kommentaren lösen einen Neuaufbau ausschließlich der betroffenen Artikelseite im Cache aus.

Schon gewusst?
Cachify verfügt über eine eigene Produktseite: Cachify.de

Häufige Fragen

Hat das obige Online-Handbuch nicht alle Fragen beantwortet? Vielleicht helfen nachfolgende Antworten auf die oft gestellten Fragen.

- 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.

Versionsverlauf

Version 2.0.6 vom 23.03.2012

• Cache-Neuaufbau für eine Blogseite bei neuem Kommentar erst dann, wenn der Kommentar freigeschaltet ist.

Version 2.0.5 vom 23.01.2013

• Überarbeitetes Plugin-Handbuch
• Änderung an Systemvoraussetzungen
• Check für angemeldete Nutzer bei APC als Methode
• Kein Cache bei Jetpack Mobile Theme
• Cache-Leerung nach WordPress-Update

Version 2.0.4 vom 15.08.2012

• Dashboard: Trennung der Cache-Gesamtgröße vor Diskussionswerten

Version 2.0.3 vom 01.08.2012

• Support für Custom Post Types hinzugefügt
• Erweiterung der WP-internen robots.txt um Disallow: /wp-content/cache/
• Hook cachify_flush_cache zum Cache-Leeren

Version 2.0.2 vom 12.6.2012

• Unterstützung für WordPress 3.4
• Hochauflösendes Plugin-Icon für Retina-Displays
• Eliminierung des Icons aus der Admin-Sidebar
• Behandlung für ältere PHP-Versionen

Version 2.0.1 vom 12.3.2012

• Cache-Reset beim Veröffentlichen geplanter Beiträge (Cachify DB)
• Optimierung des Autoload-Prozesses
• Textliche Anpassungen

Version 2.0 vom 5.3.2012

• Offizielle Cachify-Homepage: cachify.de
• Komplett überarbeitete Oberfläche der Einstellungen
• Inline-Hilfe direkt im Plugin (ab WordPress 3.3)
• Cache-Größe auf dem Admin-Dashboard
• HDD-Cache für noch kürzere Response-Zeiten
• Modularisierung des Quelltextes
• Keine Cache-Ausgabe für Kommentatoren
• WordPress 3.1 (3.3 empfohlen) & PHP 5.1.2 als Mindestanforderung
• APC 3.0.0 (3.1.4 empfohlen) als Mindestanforderung
• Cache-Reset pro Artikel bei Kommentarstatusänderungen

Version 1.5.1 vom 6.2.2012

• APC Proxy: zlib.output_compression = Off für Apache Webserver

Version 1.5 vom 14.01.2012

• Code-Formatierung
• Veränderung des Toolbar-Buttons “Cache leeren”
• Überarbeitung des regulären Ausdrucks für die HTML-Minimierung

Version 1.4 vom 23.12.2011

• Xmas Edition

Version 1.3 vom 20.12.2011

• Unterstützung für APC-Erweiterung
• Umsiedlung der Schaltfläche innerhalb der Admin Bar

Version 1.2.1 vom 01.12.2011

• Icon für die Admin Bar

Version 1.2 vom 21.11.2011

• Cache leeren Schalter für die Adminbar
• Testbetrieb unter WordPress 3.3
• Verknüpfung mit wpSEO (Cache-Leerung bei Optionsänderungen)

Version 1.1 vom 16.08.2011

• Automatische Prüfung auf eventuelle Fehlgenerierungen
• Modifizierung der Code-Struktur
• Eliminierung der Inline-Hilfe (oben rechts)
• Verknüpfung der Online-Hilfe mit einzelnen Optionen

Version 1.0 vom 21.06.2011

• Leerung des Cache beim Aktualisieren von statischen Seiten
• Seite mit Plugin-Einstellungen
• Inline-Dokumentation innerhalb der Optionsseite
• Ausschluss von Passwort-geschützten Seiten
• WordPress 3.2 Support
• Unterstützung der WordPress Multisite Blogs
• Umstellung auf den template_redirect-Hook (Plugin-Kompatibilität)
• Interne Code-Bereinigung

Version 0.9.2 vom 17.05.2011

• HTML-Minimierung durch Entfernung unnötiger Leerräume
• Flattr-Link

Version 0.9.1 vom 27.01.2011

• Cache-Reset bei geplanten Beiträgen
• Unterstützung für das Carrington-Mobile Theme

Version 0.9 vom 14.01.2011

• Workaround für Redirects

Version 0.8 vom 11.01.2011

• Blacklist für PostIDs
• Blacklist für UserAgents
• Ausnahme für WP Touch
• Ausgabe des Zeitpunktes der Generierung
• Umbenennung der Konstanten

Version 0.7 vom 10.01.2011

• Davor, danach: Ausgabe des Speicherverbrauchs

Version 0.6 vom 09.01.2011

• Live auf wordpress.org