Datenverarbeitung

FG Multilang WP speichert seine Sprach- und Übersetzungsdaten überwiegend lokal in der WordPress-Datenbank. Zusätzlich enthält das ausgelieferte Paket FG Core 1.1.3, dessen StatusReporter standardmäßig einen täglichen technischen Installationsstatus an einen FUNCKGROUP-Endpunkt sendet.

Diese Seite beschreibt ausschließlich das im analysierten Code erkennbare Verhalten. Sie ist keine rechtliche Bewertung.

Lokal gespeicherte Daten

Eigene Tabellen

FG Multilang WP legt zwei Tabellen mit dem jeweiligen WordPress-Tabellenpräfix an:

fgml_languages: Sprachkonfiguration.
fgml_translations: Übersetzungsgruppen, Objektzuordnungen und Status.

WordPress-Optionen

Zu den zentralen FGML-Optionen gehören:

fgml_options,
fgml_db_version,
fgml_needs_rewrite_flush.

ACF-Sprachwerte für Options Pages werden über ACF in WordPress-Optionen mit sprachspezifischen Post-IDs beziehungsweise Referenzschlüsseln gespeichert.

Post- und Term-Meta

Je nach Funktion werden unter anderem folgende Meta-Schlüssel verwendet:

_fgml_lang
_fgml_group
_fgml_source
_fgml_status
_fgml_media_{sprache}_{feld}

Diese Daten enthalten Sprachzuordnungen, interne Objektbeziehungen, Status und sprachabhängige Medien-Metadaten.

Personenbezogene Inhalte

Der Plugin-Code erzeugt keine eigene Benutzer-, Kontakt- oder Tracking-Datenbank. Übersetzte WordPress-Inhalte können selbstverständlich personenbezogene Inhalte enthalten, wenn solche Inhalte redaktionell in WordPress gespeichert werden; FG Multilang WP bewertet oder klassifiziert diese Inhalte nicht.

Cookies und Browser-Speicher

Im analysierten Projektcode werden keine Cookies gesetzt.

Es gibt außerdem keine Verwendung von:

localStorage,
sessionStorage,
IndexedDB.

Das Frontend des Plugins benötigt für seine Sprachumschaltung kein eigenes JavaScript.

REST API und AJAX

FG Multilang WP registriert keine eigenen WordPress-REST-Endpunkte und keine eigenen wp_ajax_*-Handler.

Die optionale String-Ersetzung wird bei wp_doing_ajax() und bei von WordPress als JSON erkannten Requests ausdrücklich nicht gestartet.

Externe Requests durch FG Core

Das Plugin-Paket enthält FG Core 1.1.3. Dessen StatusReporter wird beim Start des aktiven FG Core gebootet.

Standard-Endpunkt

Ohne Überschreibung lautet der Ziel-Endpunkt:

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

Zeitplan

Wenn Statusmeldungen aktiviert sind und noch kein Termin existiert, plant FG Core:

den ersten Lauf zufällig etwa 120 bis 900 Sekunden später,
danach einen täglichen WordPress-Cronlauf.

Der Cron-Hook lautet:

fg_core_send_installation_status

Übertragene Nutzdaten

Der JSON-Payload enthält laut aktuellem Code:

Schema-Version,
eine generierte Installations-UUID,
Domain,
site_url und home_url,
WordPress-Environment-Typ,
Multisite-Status sowie gegebenenfalls Network- und Blog-ID,
WordPress-Version, Locale und Zeitzone,
PHP-Version,
aktive FG-Core-Version, API-Version und ausgewählten Provider,
erkannte FUNCKGROUP-Plugins mit Name, Slug, Version, Plugin-Datei, Aktivstatus, Network-Aktivstatus, Core-Registrierung und eingebetteter Core-Version,
UTC-Zeitpunkt der Meldung.

Der Code kommentiert ausdrücklich, dass keine Benutzer, Posts, Zugangsdaten oder Datenbankinhalte in diesen Payload aufgenommen werden.

Eine IP-Adresse wird nicht als eigenes Payload-Feld erzeugt.

Installations-Token und Header

FG Core erzeugt zusätzlich ein Installations-Token und sendet unter anderem folgende Request-Header:

X-FG-Install-ID
X-FG-Install-Token
X-FG-Core-Version

Der User-Agent enthält die FG-Core-Version und home_url('/').

Lokal gespeicherte Statusdaten

FG Core verwendet unter anderem folgende WordPress-Optionen:

fg_core_installation_id
fg_core_installation_token
fg_core_installation_home_url
fg_core_status_last_report
fg_core_status_last_error
fg_core_status_last_http_code

Wird eine kopierte Datenbank unter einer anderen home_url erkannt, erzeugt der Code eine neue Installations-ID und verwirft das bisherige Installations-Token.

Statusmeldung deaktivieren

Die Statusmeldung lässt sich über eine Konstante deaktivieren, sofern diese vor dem Laden der Plugins definiert wird:

define('FG_CORE_STATUS_REPORTING', false);

Alternativ steht der Filter zur Verfügung:

add_filter('fg_core_status_reporting_enabled', '__return_false');

Der Ziel-Endpunkt kann über FG_CORE_STATUS_ENDPOINT oder fg_core_status_endpoint überschrieben werden. Weitere Hooks sind unter Entwicklerschnittstellen beschrieben.

Logging und Telemetrie

FG Multilang WP schreibt im analysierten Code keine eigenen Logdateien.

FG Core speichert für den Status-Request den letzten erfolgreichen Report, die letzte Fehlermeldung und den letzten HTTP-Statuscode als WordPress-Optionen. Der externe Status-Request ist die im Projekt erkennbare Telemetrie-/Statusübertragung.

Dateiübertragung

FG Multilang WP überträgt keine Medien- oder Inhaltsdateien an externe Dienste.

Im Adminbereich können JSON-Dateien für Einstellungen und Übersetzungszuordnungen hochgeladen werden. Diese Uploads werden serverseitig gelesen und als JSON ausgewertet; der Plugin-Code legt daraus keine eigene persistente Upload-Datei an.

Exports werden als JSON-Download an den administrierenden Browser ausgegeben.

Deinstallation und verbleibende Daten

Auch bei aktivierter FGML-Löschoption entfernt die Deinstallationsroutine nur die beiden eigenen Tabellen und zentrale FGML-Optionen.

Nicht entfernt werden unter anderem:

_fgml_* Post-/Term-Meta,
_fgml_media_* Attachment-Meta,
sprachabhängige ACF-Optionswerte,
die oben genannten gemeinsam genutzten FG-Core-Optionen,
ein gegebenenfalls von FG Core geplanter Status-Crontermin.

Die beabsichtigte Ownership dieser gemeinsamen FG-Core-Daten beim Entfernen des letzten FUNCKGROUP-Plugins ist aus dem Projekt allein nicht eindeutig bestimmbar.