Datenverarbeitung

Diese Seite beschreibt ausschließlich das im aktuellen Projektcode erkennbare technische Verhalten. Sie ist keine rechtliche Bewertung.

Lokale Cache-Dateien

FG Cache WP speichert cachefähige öffentliche HTML-Antworten lokal unter:

wp-content/cache/fg-cache/pages/

Der Inhalt einer Cache-Datei entspricht der vom WordPress-Frontend erzeugten öffentlichen HTML-Antwort. Enthält eine öffentliche Seite personenbezogene Angaben im HTML, können diese damit auch Bestandteil der lokalen Cache-Datei sein.

Zu Cache-Dateien werden Metadateien gespeichert. Sie enthalten:

• Host
• Pfad
• vollständige Cache-URL einschließlich der im Cache-Key berücksichtigten Query-Parameter
• Erzeugungszeitpunkt

Die Runtime-Konfiguration liegt unter:

wp-content/cache/fg-cache/runtime-config.php

WordPress-Optionen und Transients

FG Cache WP verwendet insbesondere:

• fg_cache_settings
• fg_cache_settings_schema
• fg_cache_auto_warmup_active
• fg_cache_auto_warmup_status
• temporäre Transients mit dem Präfix fg_cache_

Manuelle Warmup-Transients können eine Liste interner Seiten-URLs und Fortschrittswerte enthalten. Automatische Warmup-Daten enthalten ebenfalls interne URLs während der Laufzeit; im dauerhaft gespeicherten Status wird die URL-Liste vor dem Speichern entfernt.

Cookies

FG Cache WP setzt im eigenen Cache-Code keine Frontend-Cookies.

Das Plugin liest vorhandene Cookie-Namen, um BYPASS-Regeln anzuwenden. Standardmäßig werden unter anderem eingeloggte WordPress-Sitzungen, Passwortschutz- und Kommentar-Cookies berücksichtigt. Bei WooCommerce können zusätzliche Warenkorb-/Session-Cookies ergänzt werden.

Cookie-Werte werden nicht in den Cache-Schlüssel geschrieben.

LocalStorage und SessionStorage

Im Projektcode gibt es keine Nutzung von localStorage oder sessionStorage.

REST und AJAX

FG Cache WP registriert keine eigene REST-API-Route.

Für den manuellen Warmup existieren authentifizierte WordPress-AJAX-Aktionen. Sie verlangen manage_options und einen Nonce.

Der automatische Warmup verwendet einen Loopback-AJAX-Worker. Dieser wird über einen zufälligen Token autorisiert; serverseitig wird für den aktiven Auftrag nur der Hash des Tokens in einer WordPress-Option gespeichert.

Warmup-Requests

Warmup-Requests werden mit WordPress-HTTP-Funktionen an URLs der eigenen home_url()- beziehungsweise site_url()-Hosts gesendet. Externe Hosts werden aus der Warmup-Liste entfernt.

Ein im aktuellen Request vorhandener Basic-Authorization-Header kann für diese Requests an die eigene Installation weitergereicht werden.

FG-Core-Statusbericht

FG Cache WP enthält FG Core 1.1.3. Der aktive FG Core startet standardmäßig einen täglichen Installations-/Statusbericht. Der erste geplante Lauf wird zufällig etwa 2 bis 15 Minuten nach der Initialisierung angesetzt, danach verwendet WordPress einen täglichen Cron-Intervall.

Standard-Endpunkt:

https://lizenz.funckgroup-server.com/wp-json/fg-lizenz/v1/status

Der JSON-Payload enthält laut aktuellem Code:

• eine zufällig erzeugte Installations-UUID,
• Domain, site_url und home_url,
• WordPress-Umgebungstyp,
• Multisite-Status sowie Network-/Blog-ID,
• WordPress-Version, Locale und Zeitzone,
• PHP-Version,
• FG-Core-Version, API-Version und Provider,
• erkannte FUNCKGROUP-Plugins mit Slug, Name, Version, Plugin-Datei, Aktivstatus, Netzwerk-Aktivstatus und eingebetteter FG-Core-Version,
• Berichtszeitpunkt.

Zusätzlich wird ein lokal erzeugter Installationstoken als HTTP-Header X-FG-Install-Token gesendet. Der Token ist nicht Teil des JSON-Payloads.

Benutzerkonten, Beiträge, Zugangsdaten oder allgemeine Datenbankinhalte werden von dieser StatusReporter-Klasse nicht in den Payload aufgenommen.

Die Server-IP-Adresse ist nicht als Payload-Feld implementiert. Wie bei jedem HTTP-Request ist die absendende Netzwerkadresse für den empfangenden Server technisch sichtbar.

Statusbericht deaktivieren

Der eingebettete FG Core unterstützt eine Konstante:

define('FG_CORE_STATUS_REPORTING', false);

Alternativ kann der Filter verwendet werden:

add_filter('fg_core_status_reporting_enabled', '__return_false');

Damit sendet der StatusReporter keine Berichte. Ein bereits in WordPress eingeplanter Cron-Eintrag wird durch diese Prüfung nicht aktiv versendet, aber durch FG Cache WP selbst auch nicht explizit aus dem Cron-Speicher entfernt.

Der Ziel-Endpunkt kann über FG_CORE_STATUS_ENDPOINT oder den Filter fg_core_status_endpoint geändert werden.

Deinstallation und gemeinsame FG-Core-Daten

uninstall.php von FG Cache WP entfernt die FG-Cache-eigenen Optionen, Transients und Cache-Dateien. Die gemeinsam von FG Core verwendeten Optionen wie Installations-ID, Installationstoken und letzter Statusbericht werden dort nicht entfernt. Das ist insbesondere bei Installationen mit mehreren FUNCKGROUP-Plugins relevant, weil jeweils die höchste eingebettete FG-Core-Version als gemeinsame Runtime gewählt wird.