Cache-Invalidierung
FG Cache WP unterscheidet zwischen gezielter URL-Invalidierung und vollständigem Purge. Ziel ist, bei normalen Inhaltsänderungen nur betroffene Seiten zu entfernen und bei global wirkenden Änderungen konservativ den gesamten Page Cache zu leeren.
Gezielte Invalidierung bei Inhaltsänderungen
Section titled “Gezielte Invalidierung bei Inhaltsänderungen”Für öffentliche beziehungsweise von WordPress als sichtbar eingestufte Inhaltstypen werden bei einem Speichervorgang unter anderem folgende Ziele gesammelt:
- die Singular-URL des Inhalts,
- die Startseite,
- bei Beiträgen die Beitragsübersicht,
- Autorenarchive,
- Jahres-, Monats- und Tagesarchive,
- ein vorhandenes Post-Type-Archiv,
- öffentliche Taxonomiearchive der zugeordneten Terms.
Bei Updates werden vorherige und neue Ziele zusammengeführt. Dadurch können beispielsweise alte und neue Slugs oder Datumsarchive berücksichtigt werden.
Wenn Taxonomiezuordnungen separat geändert werden, werden alte und neue öffentliche Term-Archive erneut berücksichtigt.
Archiv-Paginierung
Section titled “Archiv-Paginierung”Die Metadaten jeder Cache-Datei enthalten den normalisierten Pfad. Bei einem betroffenen Archiv löscht FG Cache WP nicht nur die Haupt-URL, sondern auch vorhandene Pagination-Pfade unter der WordPress-Pagination-Basis.
Wenn der Hook acf/save_post eine numerische Post-ID liefert, verwendet FG Cache WP die normale gezielte Inhaltsinvalidierung.
Bei globalen ACF-Kontexten wie Options-, User- oder Term-Daten wird der vollständige Page Cache geleert, weil sich die betroffenen Frontend-Seiten nicht zuverlässig auf einzelne URLs begrenzen lassen.
Vollständiger Purge
Section titled “Vollständiger Purge”Ein vollständiger Purge wird unter anderem durch folgende Ereignisse ausgelöst:
- Erstellen, Bearbeiten oder Löschen von Terms
- Änderungen an WordPress-Menüs
- Speichern im Customizer
- Theme-Wechsel
- abgeschlossene Plugin-/Theme-Updates über den Upgrader
- Aktivierung oder Deaktivierung von Plugins
- Kommentaränderungen einschließlich Statuswechsel
- bestimmte Änderungen an integrierten FUNCKGROUP-Plugins
- WooCommerce-Produkt- oder Bestandsänderungen, wenn WooCommerce erkannt wird
Bei einem vollständigen Purge werden alle .html-Cache-Dateien im FG-Cache-Verzeichnis entfernt; zugehörige Metadateien und Unterverzeichnisse werden ebenfalls aufgeräumt.
Elementor
Section titled “Elementor”Wenn Elementor aktiv ist, reagiert FG Cache WP auf elementor/document/after_save. Kann eine Post-ID aus dem Elementor-Dokument ermittelt werden, wird gezielt invalidiert; andernfalls erfolgt ein vollständiger Purge.
Diese Integration ist im Code vorhanden, laut Projekt-Changelog jedoch noch nicht praktisch getestet. Sie wird deshalb nicht als vollständig getestete Elementor-Kompatibilität ausgewiesen.
WooCommerce
Section titled “WooCommerce”Wenn WooCommerce aktiv ist, registriert FG Cache WP Hooks für Produkt-, Variations- und Bestandsänderungen. Diese Ereignisse verwenden derzeit bewusst einen vollständigen Purge.
Die WooCommerce-Integration ist im Code vorhanden, laut Projekt-Changelog jedoch noch nicht praktisch getestet.
Manuelle Invalidierung
Section titled “Manuelle Invalidierung”Administratoren können den gesamten Cache über die FG-Cache-Übersicht oder die WordPress-Admin-Bar leeren.
Entwickler können zusätzlich die Funktionen fg_cache_purge_all() und fg_cache_purge_url() verwenden.
Automatischer Warmup nach Invalidierung
Section titled “Automatischer Warmup nach Invalidierung”Ist der automatische Warmup aktiviert, merkt sich FG Cache WP die tatsächlich entfernten URLs. Nach einer gezielten Invalidierung werden nur diese URLs erneut aufgerufen. Nach einem vollständigen Purge wird die gesamte Warmup-Liste vorbereitet.
Details stehen unter Cache-Warmup.