Datenverarbeitung

Diese Seite beschreibt ausschließlich die im Projektcode von FG Media Audit 0.9.1 und dem eingebetteten FG Core 1.1.3 erkennbare Datenverarbeitung. Sie ist keine rechtliche Bewertung.

Lokale Speicherung durch FG Media Audit

Verwendungsindex

{prefix}fg_media_audit_usage speichert erkannte Bildverwendungen mit Daten wie:

Scan-ID
Attachment-ID
Objekt-/Beitrags-ID
Post Type
Verwendungstyp
Feldschlüssel
Anzahl der Verwendungen
Scan-Zeitpunkt

Attachment-Metadaten werden in dieser Tabelle nicht vollständig dupliziert.

Änderungs- und Rollback-Historie

{prefix}fg_media_audit_imports speichert Änderungs- und Rollback-Daten. Dazu gehören WordPress-Benutzer-IDs sowie JSON-Backups mit alten und neuen Werten der tatsächlich geplanten Änderungen.

Je nach bearbeitetem Feld können in diesen Backups deshalb auch redaktionelle Inhalte aus Titel, Alt-Text, Beschriftung oder Beschreibung enthalten sein.

Optionen und Transients

FG Media Audit verwendet:

fg_media_audit_db_version
fg_media_audit_usage_scan_state
benutzergebundene Import-Vorschau-Transients mit 30 Minuten Lebensdauer

Die hochgeladene CSV-/JSON-Datei wird vom Plugin nur aus dem temporären HTTP-Upload gelesen. Der aktuelle Code kopiert sie nicht dauerhaft in ein Plugin- oder Upload-Verzeichnis.

Cookies und Browser-Speicher

Im Projektcode werden keine eigenen Cookies, kein localStorage und kein sessionStorage verwendet.

AJAX-Kommunikation

Der Verwendungsscan und die Inline-Direktbearbeitung verwenden admin-ajax.php mit Same-Origin-Anfragen aus dem WordPress-Backend. Die Endpunkte sind an eingeloggte Administratoren gebunden und verwenden Nonces sowie manage_options.

Es gibt keine öffentlichen nopriv-AJAX-Endpunkte.

REST API

FG Media Audit registriert keine eigenen WordPress-REST-Routen.

Externe Requests durch FG Media Audit

Die Media-Audit-Klassen selbst enthalten keine externen HTTP-Requests.

Externe FG-Core-Statusmeldung

Die mit dem Projekt ausgelieferte FG-Core-Implementierung 1.1.3 aktiviert standardmäßig eine tägliche Installations-Statusmeldung über WP-Cron. Bei mehreren aktiven FUNCKGROUP-Plugins kann eine andere, gemeinsam ausgewählte FG-Core-Version die Laufzeit bereitstellen. Der in diesem Projekt enthaltene Standard-Endpunkt lautet:

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

Der erste geplante Lauf wird zufällig etwa 2 bis 15 Minuten nach der Einrichtung des Zeitplans angesetzt; anschließend verwendet WordPress das Intervall daily.

Inhalt des Status-Payloads

Der Code übermittelt unter anderem:

zufällig erzeugte Installations-ID
Domain
Site-URL und Home-URL
WordPress-Environment-Type
Multisite-Status, Network-ID und Blog-ID
WordPress-Version
Locale und Zeitzone
PHP-Version
aktive FG-Core-Version und Provider
erkannte FUNCKGROUP-Plugins mit Name, Version, Plugin-Datei, Aktivstatus, Netzwerk-Aktivstatus und eingebetteter Core-Version
Report-Zeitpunkt

Zusätzlich wird ein lokal erzeugtes Installationstoken im HTTP-Header X-FG-Install-Token gesendet.

Der Reporter-Kommentar und der Payload-Code enthalten keine Benutzerkonten, Beiträge, Zugangsdaten oder Datenbankinhalte als Statusfelder.

IP-Adressen

FG Media Audit enthält keine Logik, die Besucher-IP-Adressen aus WordPress-Anfragen ausliest oder lokal speichert. Bei der ausgehenden HTTP-Verbindung zur FG-Core-Statusstelle kann die Gegenstelle technisch die Verbindungs-IP des Servers sehen. Ob und wie diese serverseitig gespeichert wird, ist aus diesem Plugin-Repository nicht bestimmbar.

Deaktivieren

Die Statusmeldung kann über FG_CORE_STATUS_REPORTING oder den Filter fg_core_status_reporting_enabled deaktiviert werden. Siehe Konfiguration.

Telemetrie und Logging

Die FG-Core-Statusmeldung ist die im Projektcode erkennbare externe Installations-Statuskommunikation. FG Core speichert lokal außerdem Informationen zum letzten erfolgreichen Report, letzten Fehler und HTTP-Statuscode.

FG Media Audit selbst enthält keine eigene Besuchertelemetrie und keine Aufrufe von error_log().