Protokollierung und Fehlerbehebung

Diese Seite beschreibt auf hoher Ebene, wie das Plugin die Protokollierung und Fehlerbehebung (Debugging) handhabt. Die interne Logger-Klasse, der Speicherort der Protokolldatei, Rotationsgrenzwerte und Maskierungsregeln sind Implementierungsdetails und werden hier nicht veröffentlicht.

Verhalten auf hoher Ebene

• Das Plugin schreibt Laufzeitdiagnosen in ein eigenes Protokollziel, das von WordPress verwaltet wird, getrennt vom WordPress-Core-Debug-Protokoll.
• Das Protokollvolumen ist begrenzt: Alte Einträge werden automatisch rotiert und bereinigt.
• Sensible Werte (Zugangsdaten, Token, Autorisierungs-Header, Header für signierte Anfragen) werden maskiert, bevor eine Zeile geschrieben wird.
• Wenn bei einem Import oder Hintergrundjob ein Fehler auftritt, zeigt das Plugin im Admin-Bereich einen Hinweis an und schreibt einen Diagnoseeintrag, der mit dem Support geteilt werden kann.

Für Administratoren

Wenn Sie Diagnosedaten an den Support weitergeben müssen, nutzen Sie die Funktion zum Diagnose-Export in der Admin-Benutzeroberfläche des Plugins, anstatt rohe Protokolldateien zu kopieren. Das exportierte Paket enthält alle Informationen, die der Support benötigt, während vertrauliche Daten maskiert bleiben.

Für Entwickler

Verlassen Sie sich bei externem Code nicht auf bestimmte Pfade, Formate oder das Rotationsverhalten von Protokolldateien; dies sind Implementierungsdetails. Verwenden Sie bei der Entwicklung mit dem Plugin vorzugsweise den Standard-WP_DEBUG-Workflow von WordPress zusammen mit dem Diagnose-Export des Plugins.

Unterstützte öffentliche Integrationsschnittstellen

Nutzen Sie bei der Integration mit dem Plugin vorzugsweise diese stabilen Schnittstellen:

• Die Admin-Einstellungen-Benutzeroberfläche des Plugins.
• Die dokumentierten Shortcodes.
• Template-Überschreibungen auf Theme-Ebene, wie in Template-System und Überschreibungen beschrieben.
• Die allgemeine Entwickler-Übersicht zur Orientierung.

Interne Klassennamen, Option-Keys, Datenbanktabellen, REST- und AJAX-Endpunkte, Cron-Hook-Namen, Berechtigungs- und Nonce-Identifikatoren sowie die Release- und Update-Infrastruktur werden als Implementierungsdetails behandelt. Sie können sich zwischen den Versionen ohne Vorankündigung ändern und sind nicht Teil des öffentlichen Integrationsvertrags.

Stabilitäts- und Änderungsrichtlinie

Alles, was oben nicht als unterstützte öffentliche Schnittstelle aufgeführt ist, gilt als internes Implementierungsdetail. Interne APIs, das Speicherlayout und Sicherheitsimplementierungen können sich zwischen den Versionen ändern. Verlassen Sie sich in Drittanbieter-Code, Themes oder externen Systemen nicht auf diese Details. Direkte Datenbank-Schreibzugriffe werden nicht unterstützt.

Hinweis zur öffentlichen Dokumentation. Diese Seite bietet nur eine allgemeine Integrationsübersicht. Interne Implementierungsdetails, private APIs, Speicher-Interna und sicherheitsrelevante Release-Infrastrukturen werden separat gepflegt und sind nicht Teil der öffentlichen Dokumentation. Unterstützte Integrationsschnittstellen sind die dokumentierten Shortcodes, Template-Überschreibungen, die Einstellungs-Benutzeroberfläche und alle in diesem Abschnitt explizit veröffentlichten Erweiterungspunkte.