Protokollierung und Fehlerbehebung

Diese Seite beschreibt auf hoher Ebene, wie das Plugin die Protokollierung und Fehlerbehebung 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, von WordPress verwaltetes Protokollziel, getrennt vom WordPress-Core-Debug-Log.
• Das Protokollvolumen ist begrenzt: Alte Einträge werden automatisch rotiert und gelöscht.
• 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 mit dem Support teilen müssen, verwenden Sie die Funktion für den Diagnose-Export, die in der Admin-Benutzeroberfläche des Plugins verfügbar ist, anstatt rohe Protokolldateien zu kopieren. Das exportierte Paket enthält alle Informationen, die der Support benötigt, während Geheimnisse maskiert bleiben.

Für Entwickler

Verlassen Sie sich bei externem Code nicht auf bestimmte Protokolldateipfade, Formate oder das Rotationsverhalten; dies sind Implementierungsdetails. Wenn Sie für das Plugin entwickeln, bevorzugen Sie den standardmässigen WP_DEBUG-Workflow von WordPress zusammen mit dem Diagnose-Export des Plugins.

Unterstützte öffentliche Integrationsschnittstellen

Wenn Sie das Plugin integrieren, bevorzugen Sie 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, Capability- 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. Direkte Datenbankzugriffe werden nicht unterstützt.

Hinweis zur öffentlichen Dokumentation. Diese Seite bietet nur eine allgemeine Integrationsübersicht. Interne Implementierungsdetails, private APIs, Speicherinterna 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.