Konfiguration - WordPress

Wo die Konfiguration liegt

Alle Einstellungen des Plugins stehen auf einem Bildschirm: Einstellungen → DockRay. Oben sitzen zwei Status-Pillen - ob die Zugangsdaten vollständig sind und wie der letzte Verbindungstest ausgegangen ist, mit Zeitstempel. Der Status fragt DockRay nicht bei jedem Aufruf ab, das Öffnen der Einstellungen erzeugt also keinen Verkehr zum Panel.

Konfigurationsquelle

Das Plugin kann Werte vom Einstellungsbildschirm oder aus PHP-Konstanten in der wp-config.php nehmen. Der Schalter Konfigurationsquelle entscheidet, was gewinnt:

Ein von einer Konstante überschriebenes Feld wird mit dem tatsächlich wirksamen Wert und einer Begründung angezeigt. Ein gesperrtes Feld übermittelt diesen Wert beim Speichern weiterhin mit, das Speichern einer beliebigen anderen Änderung kann also einen per Konstante gesetzten Token nicht leeren.

Konstanten der wp-config.php

Umgebungen

Jede Umgebung sollte unter einem eindeutigen Namen berichten - production, staging, preview. Der Name ist eine Spalte im Panel und ein Filter in der Fehlerliste; ohne ihn sieht ein Produktionsausfall genauso aus wie ein Fehler, den jemand im Test ausgelöst hat. Lass die lokale Umgebung ohne Zugangsdaten: ohne Token und Schlüssel lädt die Integration und bleibt still - ein eigener Schalter ist nicht nötig.

Was sich zu melden lohnt

Schicke DockRay die Störungen, auf die jemand reagieren muss. Standardmäßig folgt das Plugin dem Niveau aus error_reporting(), und DOCK_RAY_ERROR_TYPES engt es ein - etwa auf fatale Fehler und Warnungen, ohne die Notices und Deprecations, die eine typische Installation mit vielen Plugins dominieren.

• Melde keine Validierung, die als normale Antwort an den Benutzer behandelt wird.
• Siebe die 404er von Scannern und nicht existierenden Adressen aus.
• Lass send_default_pii aus, solange du die Identität des angemeldeten Benutzers nicht wirklich im Ereignis brauchst.

Antwortzeiten und Browserfehler

Beides ist standardmäßig aus und wird getrennt eingeschaltet. Die Zeitmessung beginnt zu greifen, sobald die Transaktions-Stichprobenrate über null liegt. JavaScript-Fehler gehen zuerst an WordPress, nicht an das Panel: ein Browser kann sich nicht bei DockRay authentifizieren, denn dafür müsste der private Schlüssel im Seitenquelltext stehen. Der Empfänger auf WordPress-Seite prüft eine Nonce, verwirft Bodies über 16 kB, erlaubt 20 Meldungen pro IP-Adresse und Minute und antwortet 202, unabhängig davon, ob die Meldung angenommen wurde.

Melden aus eigenem Code

Ein Theme oder ein eigenes Plugin kann eine Ausnahme selbst melden. Ein in dock_ray_safe() gekapselter Aufruf tut nichts, wenn DockRay nicht aktiv ist - derselbe Code ist also auch in einer Umgebung ohne Zugangsdaten unbedenklich.

try {
    $order->finalize();
} catch ( Throwable $e ) {
    if ( function_exists( 'dock_ray_safe' ) ) {
        dock_ray_safe( fn( $hub ) => $hub->captureException( $e ) );
    }

    throw $e;
}

Den privaten Schlüssel schützen

Der private Schlüssel ist ein Projektgeheimnis, keine Kennung. Bewahre ihn in Umgebungsvariablen, in einem Secret-Manager oder in der Serverkonfiguration auf - niemals im Repository, in Logs, auf einem Screenshot oder in Code, der an den Browser geht. Ein Projekt kann mehrere Schlüssel haben, deshalb sollten Produktion und Staging je eigene bekommen: jeder lässt sich einzeln widerrufen, ohne die übrigen zu unterbrechen. Der Verdacht, dass ein Schlüssel abgeflossen ist, genügt, um ihn zu widerrufen und einen neuen zu erzeugen.

Wann Ereignisse hinausgehen

Nach der Antwort. Das Plugin sammelt Ereignisse während der Anfrage und sendet sie aus einem Shutdown-Handler, wenn PHP-FPM die Verbindung zum Browser schon geschlossen hat. Die Anfragen laufen über die WordPress-HTTP-API mit TLS-Prüfung und ohne Weiterleitungen zu folgen, ein selbst betriebener DockRay-Server muss also über HTTPS erreichbar sein.