Fehlerbehebung

FG Cache ist „nicht vollständig aktiv“

Mögliche Ursache

Mindestens eine der Voraussetzungen für den Runtime-Status fehlt: Page Cache deaktiviert, eigenes advanced-cache.php fehlt, WP_CACHE ist nicht aktiv oder runtime-config.php ist nicht lesbar.

Lösung

1. FG Cache → Diagnose öffnen.
2. advanced-cache.php, WP_CACHE, Runtime Config und Cache-Pfad prüfen.
3. Cache-Laufzeit reparieren ausführen.
4. Falls wp-config.php nicht beschreibbar ist, define('WP_CACHE', true); manuell ergänzen.

Prüfung

Die Übersicht sollte anschließend FG Cache ist bereit anzeigen. Ein zweiter anonymer Aufruf einer cachefähigen Seite sollte einen X-FG-Cache: HIT liefern.

Ein fremdes advanced-cache.php ist vorhanden

Mögliche Ursache

Ein anderes Cache-Plugin oder eine individuelle Installation verwaltet bereits das WordPress-Drop-in wp-content/advanced-cache.php.

Lösung

FG Cache WP überschreibt fremde Drop-ins absichtlich nicht. Prüfen, welches System die Datei verwaltet, und nur dann auf FG Cache wechseln, wenn das andere Drop-in bewusst entfernt oder ersetzt werden soll.

Prüfung

Unter Diagnose muss advanced-cache.php als FG Cache aktuell erkannt werden, bevor FG Cache als vollständiger Page Cache arbeiten kann.

WP_CACHE ist nicht aktiv

Mögliche Ursache

wp-config.php ist nicht beschreibbar oder enthält ausdrücklich:

define('WP_CACHE', false);

Lösung

Eine ausdrücklich auf false gesetzte Definition wird von FG Cache nicht überschrieben. Die Einstellung muss bewusst in wp-config.php geändert werden.

Prüfung

Unter Diagnose muss WP_CACHE als true erscheinen.

Die Seite bleibt auf MISS

Mögliche Ursache

Die erste Antwort wird nicht gespeichert. Gründe können unter anderem ein nicht-200-Status, Set-Cookie, ein restriktiver Cache-Control-Header, eine Nicht-HTML-Antwort oder ein später gesetztes DONOTCACHEPAGE sein.

Lösung

1. Response-Status und Header der Seite prüfen.
2. Nach Set-Cookie, Cache-Control: no-store, private oder no-cache suchen.
3. Prüfen, ob Theme oder Plugin DONOTCACHEPAGE setzt.
4. Bei einem projektspezifischen Sonderfall den Filter fg_cache_should_store_response gezielt verwenden.

Prüfung

Nach einem MISS muss eine passende .html-Datei unter wp-content/cache/fg-cache/pages/ entstehen. Der nächste Request sollte dann HIT sein.

Der Header zeigt BYPASS

Mögliche Ursache

FG Cache hat bewusst eine frühe Ausschlussregel angewendet.

Lösung

Den Wert hinter reason= prüfen. Häufige Gründe:

Grund	Bedeutung
method	Request ist kein GET.
host	Host gehört nicht zu home_url() oder site_url().
range	Range-Request.
ajax	XMLHttpRequest wurde erkannt.
authorization-basic	Basic Auth ist vorhanden, aber nicht freigegeben.
authorization-other	Bearer oder anderes Authorization-Schema.
path	URL-Pfad steht in einer BYPASS-Regel.
cookie	Ein passendes BYPASS-Cookie ist vorhanden.
query-bypass	Ein definierter BYPASS-Parameter ist vorhanden.
query-unknown	Ein unbekannter Query-Parameter wurde bei der Standardregel BYPASS gefunden.
donotcachepage	DONOTCACHEPAGE ist aktiv.
fg-analytics-js	FG Analytics mit aktivem Frontend-JS erzwingt globalen BYPASS.

Prüfung

Den Request nach Beseitigung der Ursache erneut ohne eingeloggte WordPress-Sitzung testen.

Eingeloggte Benutzer erhalten keinen HIT

Mögliche Ursache

Das ist das vorgesehene Verhalten. FG Cache ergänzt wordpress_logged_in_* und wordpress_sec_* automatisch als Cookie-BYPASS.

Lösung

Für den normalen Funktionstest einen privaten Browser oder einen nicht eingeloggten Request verwenden.

Prüfung

Ohne WordPress-Login-Cookie sollte ein cachefähiger zweiter Request HIT liefern.

Warmup meldet BYPASS oder „nicht gespeichert“

Mögliche Ursache

Der Warmup erzwingt keine Cache-Speicherung. Er nutzt dieselben URL-, Cookie-, Authorization- und Response-Regeln wie normale Requests.

Lösung

Den protokollierten Request und die entsprechende BYPASS- oder Response-Ursache prüfen. Bei Query-Varianten beachten, dass sie standardmäßig nicht zusätzlich gesammelt werden.

Prüfung

Nach erfolgreichem Warmup sollte für die URL eine Cache-Datei vorhanden sein oder ein nachfolgender Request bereits HIT melden.

Automatischer Warmup bleibt auf Fehler

Mögliche Ursache

Der interne Loopback-POST an admin-ajax.php konnte nicht gestartet werden oder der temporäre Auftrag ist abgelaufen.

Lösung

1. Prüfen, ob WordPress Loopback-Requests an die eigene Installation ausführen kann.
2. Server-/Firewall-Regeln für lokale HTTP-Requests prüfen.
3. Den Cache erneut invalidieren oder den manuellen Warmup verwenden.

Prüfung

Im Warmup-Tab sollte der letzte automatische Lauf von wartet beziehungsweise läuft auf abgeschlossen wechseln.

Browser-Cache-Fallback ist nicht aktiv

Mögliche Ursache

FG Performance ist zuständig, der Server ist Nginx/OpenLiteSpeed, .htaccess ist nicht beschreibbar oder ein Markerblock ist unvollständig.

Lösung

Den Status unter Diagnose prüfen. Bei FG Performance ist keine Reparatur erforderlich. Bei einem unvollständigen Marker sollte die .htaccess manuell geprüft werden, bevor erneut geschrieben wird.

Prüfung

Auf Apache/LiteSpeed ohne FG Performance sollte die Diagnose den Fallback als aktiv anzeigen und .htaccess einen vollständigen Block zwischen # BEGIN FG Cache Browser Cache und # END FG Cache Browser Cache enthalten.