Viele Plugins erweitern WordPress wenn man will um zusätzliche Funktionen. Einige davon haben allerdings ein eher kurzes Leben. Es gibt eine Hauptversion, und vielleicht noch eine mit ein paar Bugfixes. Ende der Geschichte. Immer wieder neue Enthusiasten entdecken Freude daran, Plugins für WordPress zu entwickeln, und manchmal landen diese im Pluginverzeichnis, wo sie dann still vor sich hin veralten.

Gelegentlich kommt es vor, dass sich mir nach dem Aktivieren von so manchen Plugins die Frage stellt, ob der / die Entwickler überhaupt irgendwelche Debuggingwerkzeuge verwenden, denn sonst hätten zumindest die offensichtlichen Fehler auffallen müssen. Wenn man sich jeden Fehler (auch Notices) anzeigen lässt, um seine eigenen Entwicklungen zu prüfen, ist ein aktiviertes Dritt-Plugin das Fehler erzeugt, untragbar.

Schon ohne die Unterstützung von Debuggingtools ist es ein utopisches Ansinnen, fehlerfrei zu programmieren. Man kann nie alle Wechselwirkungen berücksichtigen, denen Komponenten später in den verschiedensten Umgebungen ausgesetzt sein werden. Es sind auch nicht immer nur die eigenen Fehler die es zu vermeiden gilt, sondern mithin auch Anwendungsfehler oder Störeinflüsse die von weniger durchdacht entwickelten Komponenten ausgehen können.

Nachfolgende Maßnahmen sind nur für WordPress-Entwicklungsumgebungen oder -Testbetrieb geeignet.

Debuggingmodus von WordPress in wp-config.php

define( 'WP_DEBUG', true );

aktiviert den Debugmodus von WordPress

define( 'WP_DEBUG_LOG', true );

WP_Debug muss aktiviert sein, dann findet man die über die PHP-Funktion error_log() aufgezeichneten Fehler in der WordPress-Installation unter wp-content (oder ggf. umbenanntem Verzeichnis).

define( 'WP_DEBUG_DISPLAY', false );

False unterdrückt die direkte Anzeige von Fehlern, so dass man sie nur im Logfile zu sehen bekommt.

define( 'SCRIPT_DEBUG', true );

Diese Funktionalität veranlasst WordPress, die nicht minifyten Versionen von Skripten und CSS-Dateien zu laden (Core-Dateien).
Damit dabei auch eigene Skripte berücksichtigt werden, müssen diese in beiden Varianten vorliegen. Und so wird das Debugging für eigene Skripte verfügbar gemacht:

function pptf_enqueue_my_script() {
    $suffix = SCRIPT_DEBUG ? '' : '.min';
    wp_enqueue_script( 'ppt-myscript', $urlpath . '/my-script'.$suffix.'.js', array($dependencies), $version , true);
}
add_action( 'wp_enqueue_scripts', 'pptf_enqueue_my_script' );

define( 'SAVEQUERIES', true );

Wenn diese Konstante aktiviert ist, speichert WordPress Datenbankabfragen in einem Array. Damit kann ermittelt werden, welche Funktion diese aufgerufen hat, und wie lange die Ausführung dauerte.

Plugin Query Monitor

Download
Dokumentation
db.php Symlink manuell anlegen
Dieses Plugin ist hilfreich für jeden, der WordPress-Komponenten entwickelt und fördert Informationen zutage, die man mit anderen Tools nicht sieht. So weiß man immer, was in WordPress an welcher Stelle passiert.

Testen

Selbst wenn man ein Theme oder Plugin so weit entwickelt hat, dass alle Fehlermeldungen verschwunden sind, bedeutet das nicht, dass es keine Fehler mehr gibt. Der nächste Schritt ist, die Komponenten auf einer anderen Installation auf der sie bisher nicht eingesetzt wurde, zu aktivieren um zu ermitteln wie sich verhält, wenn ein Benutzer sie zum ersten Mal verwendet. Manche Fehler sind nur sichtbar, wenn es zum Beispiel noch keine Optionen gibt, was in der Entwicklungsumgebung nicht mehr der Fall war.

Wenn man unterschiedliche Umgebungen zum Testen zur Verfügung hat, umso besser, zum Beispiel teste ich immer unter Linux / Apache und dem IIS von Windows. Plugins die nicht in beiden Umgebungen funktionieren, setze ich nicht ein.

Guidlines

Plugin Developer Guidlines
Theme Handbook

Hardcodieren von Pfaden und / oder Verzeichnisnamen, oder des Tabellenpräfixes unbedingt vermeiden. WordPress-APIs und WordPress-Funktionen nutzen, wenn es sie gibt. Sanitizing und Escaping für Ein- und Ausgabe verwenden. Auf Konsistenz achten, Konventionen einhalten (vor allem bei Groß- und Kleinschreibung, hat teilweise – zum Beispiel bei Dateinamen – keine Auswirkungen unter Windows, aber unter Linux sehr wohl).

Für die Untersuchung von Javascript-Problemen können die implementierten Entwicklungstools der Browser sehr nützlich sein, wie beispielsweise die von Google Chrome.