Skip to content

FAQ

FG Cache WP speichert geeignete öffentliche WordPress-HTML-Seiten als Dateien und kann sie über advanced-cache.php als Cache-HIT ausliefern, bevor WordPress den normalen Request vollständig verarbeitet.

Optimiert FG Cache WP auch CSS, JavaScript oder Bilder?

Section titled “Optimiert FG Cache WP auch CSS, JavaScript oder Bilder?”

Nein. Der dokumentierte Funktionsumfang konzentriert sich auf Full-Page-/HTML-Caching sowie einen optionalen einfachen Browser-Cache-Fallback für statische Assets. CSS-/JavaScript-Optimierung, Bildkonvertierung, Object Cache und Datenbankoptimierung sind nicht Bestandteil des Plugins.

Werden eingeloggte WordPress-Benutzer gecacht?

Section titled “Werden eingeloggte WordPress-Benutzer gecacht?”

Nein. Cookie-Regeln wie wordpress_logged_in_* und wordpress_sec_* werden automatisch als BYPASS ergänzt.

Nein. Das frühe Drop-in akzeptiert ausschließlich GET für den Page Cache. Andere HTTP-Methoden erhalten einen BYPASS.

Parameter können als VARY, ignoriert oder BYPASS konfiguriert werden. Unbekannte Parameter führen standardmäßig zu einem BYPASS. Dadurch wird nicht automatisch jede beliebige Query-Variante gecacht.

Ja. Ist DONOTCACHEPAGE wahr, wird der Request früh als BYPASS behandelt. Die Konstante wird außerdem vor dem finalen Speichern nochmals geprüft, falls sie erst später im WordPress-Request gesetzt wurde.

Kann FG Cache WP zusammen mit einem anderen advanced-cache.php verwendet werden?

Section titled “Kann FG Cache WP zusammen mit einem anderen advanced-cache.php verwendet werden?”

Nicht gleichzeitig über dasselbe Drop-in. Liegt bereits ein fremdes wp-content/advanced-cache.php vor, überschreibt FG Cache WP diese Datei nicht und kann seinen eigenen frühen Page Cache deshalb nicht vollständig aktivieren.

WooCommerce ist im Code defensiv berücksichtigt: dynamische Shop-Seiten, Parameter und Cookies werden als BYPASS behandelt, und Produkt-/Bestandsänderungen lösen einen vollständigen Purge aus. Laut README und Changelog wurde diese Integration in Version 1.0.0 jedoch noch nicht praktisch getestet.

Elementor ist im Code berücksichtigt: elementor-preview wird als BYPASS ergänzt und elementor/document/after_save invalidiert betroffene Cache-Einträge beziehungsweise den vollständigen Cache. Laut README und Changelog wurde die Integration noch nicht praktisch getestet.

Der Warmup sammelt öffentliche WordPress-URLs und ruft sie regulär per HTTP auf. Er respektiert die normalen Cache- und BYPASS-Regeln und erzwingt keine Speicherung. Der manuelle Warmup arbeitet in AJAX-Batches; der automatische Warmup verwendet einen token-geschützten Loopback-Worker.

Der eigene FG-Cache-Code setzt keine Frontend-Cookies. Vorhandene Cookie-Namen werden jedoch ausgewertet, um dynamische oder eingeloggte Requests vom Page Cache auszuschließen.

Der eingebettete FG Core 1.1.3 enthält standardmäßig einen täglichen Installations-/Statusbericht an einen konfigurierbaren FUNCKGROUP-Endpunkt. Der Payload enthält technische Installations-, WordPress-, PHP- und FUNCKGROUP-Plugin-Metadaten, aber laut Code keine Benutzer, Beiträge oder Zugangsdaten. Details und Abschaltmöglichkeiten stehen unter Datenverarbeitung.

FG Cache entfernt sein eigenes Drop-in, eine selbst markierte WP_CACHE-Zeile unter den dafür vorgesehenen Bedingungen, den eigenen Browser-Cache-Marker, die Runtime-Konfiguration und die Page-Cache-Dateien. Einstellungen bleiben bis zur Deinstallation gespeichert.

Die FG-Cache-eigenen Optionen, Transients, Cache-Dateien, Runtime-Dateien und eigenen Marker werden entfernt. Ein fremdes advanced-cache.php bleibt unangetastet. Gemeinsame FG-Core-Statusoptionen werden durch uninstall.php von FG Cache WP nicht gelöscht.