.htaccess für WordPress Plugin Cachify konfigurieren

Veröffentlicht am:

10 Kommentare

Das WordPress Plugin Cachify (ehemals Sergej Müller, jetzt pluginkollektiv) ist immer noch eine gute Wahl, um eine WordPress Webseite zu beschleunigen.

Der Download ist über das offizielle WordPress Plugin Verzeichnis möglich. Die Entwicklung findet auf GitHub statt, wo man das Plugin ebenfalls beziehen kann.
So einfach die Handhabung auch ist, hin und wieder muss man selbst Hand anlegen. Ich zeige euch hier ein paar Tipps und Tricks, welche Angaben wo in die Konfigurationsdatei .htaccess gehören, damit Cachify eure Webseite schneller macht.

Diese Punkte sollte man dabei beachten:

In den Grundeinstellungen des Plugins legt man fest, ob der Cache über die Datenbank oder HDD (sprich Festplatte) erzeugt wird. Ich wähle immer HDD, was bedeutet, dass Cachify statische Webseiten (ja, so richtig mit .html) erzeugt und der Apache Webserver diese dann ausliefert. Allerdings funktioniert diese Option nur, wenn ihr bei den WordPress Permalink-Einstellungen im Backend die sprechenden URLs ausgewählt habt.
Den Block mit den rewrite-Anweisungen schreibt das Plugin direkt in die Apache-Konfigurationsdatei .htaccess. Nun sollte der Webserver die statischen Webdateien finden. Bei restriktiven Dateirechten oder wenn PHP generell im FastCGI Modus ausgeführt wird, muss man diese Anweisungen händisch einfügen.

Das geht sehr einfach und tut nicht weh.

Wenn ihr in den Backend-Einstellungen für Permalinks die sprechenden URLS gewählt und abgespeichert habt, müsste WordPress bereits eine .htaccess im Root-Ordner angelegt haben. Ladet die über einen FTP-Client wie Filezilla herunter und bearbeitet die in einem Texteditor wie Notepad (nein, MS Word ist kein Texteditor!).
Fügt den folgenden Codeschnipsel ganz an den Anfang der Datei. Auf jeden Fall noch vor dem WordPress Bereich, der meistens durch die Kommentare #BEGINN WORDPRESS und # END WORDPRESS gekennzeichnet ist

# BEGINN CACHIFY

    # ENGINE ON
    RewriteEngine On

    # GZIP 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 %{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}%{REQUEST_URI}index.html.gz [L]

        AddType text/html .gz
        AddEncoding gzip .gz
    

    # 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}%{REQUEST_URI}index.html [L]

# END CACHIFY

Wenn ihr Kunden bei domainfactory oder auch IONOS (ehemals 1&1) sein solltet, habt ihr noch eine kleine Hürde zu nehmen. Hier funktioniert die Variable {DOCUMENT_ROOT} nämlich nicht. Dann müsst ihr den absoluten Serverpfad zu eurer Webseite selbst herausfinden und hier eintragen. Konkret geht es um diese 2 Zeilen:

RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html.gz -f
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html -f

Im einfachsten Fall fragt ihr einfach den Support eures Webhosters.
Weenn ihr allerdings etwas abenteuerlustig seid, googled ihr im Netz nach Lösungswegen und setzt diese um.
Wenn ihr den absoluten Serverpfad herausgefunden habt, müsst ihr {DOCUMENT_ROOT} mit diesem ersetzen. Das sähe beispielhaft dann so aus:

RewriteCond /kunden/homepages/0815/d08154711/htdocs/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html.gz -f
RewriteCond /kunden/homepages/0815/d08154711/htdocs/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html -f

Speichert dann die Datei .htaccess ab. Ladet sie wieder auf den Server hoch und ersetzt bzw. überschreibt die bestehende Datei.
Selbstverständlich sichert ihr die alte .htaccess vorher. Zur Sicherheit.

Bitte beachten Sie: die Informationen in diesem Artikel wurden zum Zeitpunkt seiner Erstellung nach bestem Wissen und Gewissen zusammengetragen, aufbereit und niedergeschrieben.
Diese können heute, abhängig vom Zeitpunkt der Veröffentlichung und des behandelnden Themas, überholt und ungültig sein.
Es obliegt den Lesern, diese Inhalte mit dem aktuellen Wissensstand abzugleichen.

Artikel online seit: 8 Jahren 27 Tagen
Letzte Änderung: 27.02.2023

10 Gedanken zu „.htaccess für WordPress Plugin Cachify konfigurieren“

  1. Ich habe das jetzt probiert und auch den Code inkl. des absoluten Pfades an den Anfang der htaccess Datei gesetzt. Bekomme leider eine Internal Server Fehler

    • Das ist jetzt, ohne die genaue Situation zu kennen, schwer bis unmöglich einzuschätzen, was den 500er Fehler generiert.

      • Hi Lars, danke für Deine Antwort. Ich hatte Cachify für HDD eingestellt und den obigen Code so in die htacces eingetagen. Da ich 1&1 Kunde bin, habe ich manuell den absoluten Pfad an den betreffenden Stellen (DOCUMENT_ROOT) ersetzt. Es hat aber trotzdem nicht funktioniert und offenbar ist da ein Fehler in der htaccess, den ich nicht finde.

  2. Hallo,

    ich habe leider ein ähnliches Problem bei Strato.

    Meine htaccess sieht so aus:

    # BEGINN CACHIFY

    # ENGINE ON
    RewriteEngine On

    # GZIP 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 %{HTTP:Accept-Encoding} gzip
    RewriteCond /home/strato/www/dr/www.drschoch.de/htdocs/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

    # 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 /home/strato/www/dr/www.drschoch.de/htdocs/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]

    # END CACHIFY

    # BEGIN WordPress

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    # END WordPress

    Auf meinem Strato-Sever liegen die wp-content und andere Ordner ganz oben, d.h. es gibt keinen wordpress-Ordner.

    Kannst Du mir vielleicht helfen?

    • Hallo Martin,

      in der von Dir geposteten .htaccess sind an einigen Stellen Pfade enthalten, die mit „/pfad zu/“ beginnen. Falls das keine Absicht ist, muss stattdessen an dieser Stelle natürlich der korrekte Serverpfad stehen: /home/strato/www/dr/www.drschoch.de/htdocs/

      Wenn das auch nichts hilft, schreib mich über das Formular an, dann hängt es eventuell an ganz anderer Stelle, was aber in Rätselraten ausartet und nicht über den Kommentarbereich gelöst werden sollte.

  3. Wie ist es mit https?
    Muss man die Zeilen mit Http:accept-Encoding und andere, bei denen http auftaucht dann einfach in https ändern?

    • Hallo Armin,

      nein, falls Du diese http_ Variablen meinst, das sind Apache .htaccess Ausdrücke. Die bleiben so wie sie sind. Die Frage ob http zu https wird an anderer Stelle gelöst. Das kann aber unterschiedlich erfolgen, deshalb keine allgemeingültige Aussage hier. Es sollte nur vor den Cache Mechanismen geschehen..

  4. Hallo!
    Nimmt man so ein Cachingtool heute immer noch her? Wenn ja, optimiert man auf Festplatte oder auf Datenbank? Was sind die jeweiligen Vor- und Nachteile?
    VG Jan

    • Hallo Jan, gut dass Du fragst.

      Falls Deine Frage darauf abzielt, ob man heute generell auf Chaching setzt, dann lautet die Antwort: ja, sicher. Allerdings sind die technischen Möglichkeiten ausgereifter und vielfältiger geworden. Daher kann man nicht mehr sagen, ob man in jedem Falle immer noch ein separates „Tool“ einsetzen würde.
      Wenn man das Caching über ein Hilfsmittel wie ein extra Tool bzw. im Fall von WordPress über ein Plugin betreibt, dann ist auch heute noch Cachify eine solide Wahl.
      Datenbank oder Festplatte: da lautet die Antwort ganz klar -> Jein!
      Das ist von so vielen Faktoren abhängig, dass man da keine eindeutige Empfehlung geben kann. Insgesamt ist Chaching an sich aber immer besser als gar kein Chaching.

Kommentare sind geschlossen.