Kompatibilität

Diese Seite unterscheidet zwischen im Code ausdrücklich berücksichtigter Integration und praktisch bestätigter Kompatibilität. Wo das Projekt selbst keine Tests belegt, wird keine weitergehende Aussage getroffen.

Plattform

Bereich	Stand
WordPress	mindestens 6.0 laut Plugin-Header und readme.txt
PHP	mindestens 8.1 laut Plugin-Header und composer.json
Apache	Full-Page-Cache nutzbar; Browser-Cache-Fallback wird automatisch unterstützt
LiteSpeed	Full-Page-Cache nutzbar; Browser-Cache-Fallback wird automatisch unterstützt
Nginx	Full-Page-Cache ist nicht an .htaccess gebunden; Browser-Cache-Fallback wird nicht automatisch geschrieben
OpenLiteSpeed	Browser-Cache-Fallback wird vom Code nicht automatisch verwaltet
REST API	/wp-json/* ist standardmäßig vom Page Cache ausgeschlossen; FG Cache registriert keine eigene REST-Route
WP-CLI	keine eigenen WP-CLI-Kommandos im Projekt vorhanden
WordPress Multisite	keine explizite FG-Cache-Multisite-Unterstützung oder Testaussage im Projekt belegt

FG Performance WP

Technisch berücksichtigt: ja.

Wenn FG Performance WP aktiv ist, behandelt FG Cache WP den Browser-Cache-Fallback als delegiert und entfernt seinen eigenen .htaccess-Marker. Der Full-Page-HTML-Cache bleibt Aufgabe von FG Cache WP.

Änderungen an fg_performance_settings lösen einen vollständigen Purge, eine neue Runtime-Konfiguration und eine Synchronisierung der Server-Konfiguration aus.

FG Multilang WP

Technisch berücksichtigt: ja.

FG Cache erkennt FG Multilang über FGML_VERSION beziehungsweise den aktiven Plugin-Slug. Sprachpfade werden aufgrund ihrer unterschiedlichen URLs getrennt gecacht.

Beim vollständigen Warmup setzt FG Cache bei erkannten FG-Multilang-Installationen das Abfrageargument fgml_skip_language_filter, damit die interne Sammlung nicht auf die gerade aktive Sprache beschränkt wird.

Änderungen an fgml_options lösen einen vollständigen Cache-Purge aus.

FG Weiterleitung

Technisch berücksichtigt: ja.

Wenn FG_WEITERLEITUNG_PLUGIN_DB definiert ist, liest FG Cache die in der zugehörigen Tabelle gespeicherten Kurz-URLs und ergänzt diese als BYPASS-Pfade. Dynamische Kurz-URLs und Redirect-Endpunkte sollen dadurch nicht als statische HTML-Seiten gecacht werden.

FG DocCheck WP

Technisch berücksichtigt: ja.

Bei erkanntem FG DocCheck WP:

• werden konfigurierte Login-/Redirect-Pfade als BYPASS ergänzt,
• werden als geschützt markierte Inhalte (_fg_doccheck_restricted = 1) als BYPASS-Pfade erfasst,
• werden Parameter wie secure, code, state, redirect und redirect_to als BYPASS ergänzt,
• wird PHPSESSID nicht pauschal als Cookie-BYPASS ergänzt,
• existiert eine eng begrenzte Response-Ausnahme für eine technisch leere DocCheck-PHP-Session.

Änderungen an fg_doccheck_wp_options führen zu Purge und neuer Runtime-Konfiguration.

FG Cookie WP

Technisch erkannt: ja.

Der Kompatibilitätsstatus bezeichnet FG Cookie WP als kompatibel und weist darauf hin, dass Consent-Cookies den Cache-Key nicht verändern. Es existiert jedoch keine separate Cookie-Namensliste speziell für FG Cookie WP im Cache-Code. Allgemeine Set-Cookie-Antworten können die Speicherung einer Response verhindern.

FG Analytics WP

Technisch berücksichtigt: ja.

Wenn FG Analytics WP aktiv ist und die Option fg_analytics_load_frontend_js aktiv ist, setzt FG Cache einen globalen BYPASS-Grund fg-analytics-js. Der Page Cache wird dann nicht verwendet.

Ist das Frontend-JavaScript dieser Integration deaktiviert, setzt FG Cache keinen globalen Analytics-BYPASS. Der Kompatibilitätstext im Code weist darauf hin, dass Cache-HITs dann aktuell nicht als serverseitige Pageviews gezählt werden.

WooCommerce

Technisch berücksichtigt: ja. Praktisch getestet: laut README/Changelog nein.

Der Code berücksichtigt insbesondere:

• Warenkorb-, Checkout- und Mein-Konto-Seiten als BYPASS-Pfade,
• wc-ajax und add-to-cart als BYPASS-Parameter,
• WooCommerce-Warenkorb- und Session-Cookies als BYPASS,
• Produkt-, Variations- und Bestandsänderungen mit einem vollständigen Cache-Purge.

Da das Projekt ausdrücklich festhält, dass diese Integration noch nicht praktisch getestet wurde, wird WooCommerce nicht als vollständig getestet ausgewiesen.

Elementor

Technisch berücksichtigt: ja. Praktisch getestet: laut README/Changelog nein.

Der Code ergänzt elementor-preview als BYPASS-Parameter und reagiert auf elementor/document/after_save. Wenn eine Post-ID ermittelt werden kann, erfolgt eine gezielte Invalidierung; andernfalls ein vollständiger Purge.

HTTP Basic Auth

Basic Authorization ist standardmäßig BYPASS. Die Einstellung kann das Caching für Basic Auth ausdrücklich erlauben. Bearer- und andere Authorization-Schemata bleiben immer BYPASS.

Da Authorization-Daten nicht Teil des Cache-Schlüssels sind, sollte die Freigabe nur erfolgen, wenn alle berechtigten Zugriffe dieselbe HTML-Ausgabe erhalten dürfen.