JavaScript Fehler im Backend durch schlecht programmierte Plugins beheben

Die Vielfalt an Plugins für WordPress ist enorm. Leider sind unter diesen tausenden von Plugins auch solche, die zu Problemen führen können, da sie schlecht programmiert sind. Ich bin mal ganz ehrlich: Den Fehler, den ich in diesem Post beschreibe, habe auch ich bei meinem ersten Plugin gemacht, einfach aus dem Grund, dass ich mich nicht genügend in die Materie der Hooks eingelesen habe.

Die Ursache für JavaScript Probleme im Backend

Viele Plugins benötigen JavaScript und die Dateien werden über die Funktion wp_enqueue_script() eingebunden. Was man allerdings beachten muss ist der Hook, den man verwendet, um diese Funktion auszuführen. Viele Plugins, die ich gesehen habe, nehmen hier leider den falschen Hook. So sehe ich oft diese Einbindung:

function pluginname_enqueue_script() {
	wp_enqueue_script( 'pluginname_js', plugins_url( '/script.js' , __FILE__ ) );
}
add_action( 'init', 'pluginname_enqueue_script' );

Mit dem Hook init wird die JavaScript-Datei also auf allen Seiten der WordPress Installation eingebunden und somit auch im Backend. Dies ist bei den meisten Plugins aber nicht nötig und bei einigen kann es zu Konflikten mit den JavaScript Funktionen des Backends kommen.

Mögliche Lösungswege für das Problem

Wenn man auf ein solches Problem stößt, hat man verschiedene Möglichkeiten es zu lösen. Für einige braucht man aber zumindest grundlegende Programmierkenntnisse oder muss zumindest den PHP Quellcode lesen können.

1. Den richtigen Hook selbst eintragen

Das ist wohl die einfachste Variante das Problem zu lösen, aber leider auch die am wenigsten sinnvolle. Denn für den Moment ist das Problem gelöst, aber schon mit dem nächsten Update des Plugins ist der Fehler wieder da und man muss ihn erneut beheben.

2. Den falschen Hook entfernen und den richtigen setzen – in einer eigenen Datei

Genau so einfach, wie man einen Filter setzen kann, kann man ihn auch wieder entfernen. Ein Lösungsweg ist daher, den falschen Hook einfach zu entfernen, um ihn dann direkt mit dem richtigen hinzuzufügen. Oder aber man entfernt nur die JavaScript Datei, falls die Funktion, die das JavaScript hinzufügt, auch sinnvolle Aufgaben erfüllt. Das könnte dann wie folgt aussehen:

function remove_bad_enqueued_script() {
	wp_dequeue_script( 'pluginname_js' );
}
add_action( 'init', 'remove_bad_enqueued_script', 11 );

Ich verwende hier auch wieder den init Hook mit einer Priorität von 11 (Standard ist 10), um das falsch hinzugefügte JavaScript zu entfernen. Anschließend fügen wir es dann wieder mit dem passenden richtigen Hook hinzu. Zum Beispiel wie folgt:

function correct_pluginname_enqueue_script() {
	wp_enqueue_script( 'pluginname_js', plugins_url( '/script.js' , __FILE__ ) );
}
add_action( 'wp_enqueue_scripts', 'correct_pluginname_enqueue_script' );

Das sieht jetzt auf den ersten Blick aus wie zuvor, der Trick ist hier aber, dass wie den Hook wp_enqueue_scripts verwenden und nicht die ähnlich lautende Funktion innerhalb des init Hooks. Es gibt drei solcher Hooks, die für die Bereiche Frontend, Backend und Login verwendet werden sollte. Andrew Nacin, der Lead-Developer von WordPress, erklärt die Verwendung der drei Hooks in einem Beitrag auf make.wordpress.org und wofür welcher eingesetzt wird.

Diese beiden Anpassungen kommen nun entweder in die Datei functions.php oder aber in ein Mini-Plugin (oder ein Modul für die Toolbox). Somit geht diese Anpassung bei einem Updates des Plugins auch nicht verloren.

3. Den Plugin-Entwickler auf den Fehler aufmerksam machen

Die allerbeste Lösung ist es aber immer, dem Plugin-Entwickler seinen Fehler zu schildern, und wie er ihn lösen sollte. Dann bekommen alle Nutzer des Plugins mit dem nächsten Update eine stabile Version. Bis der Entwickler das Problem gelöst hat, könnt ihr natürlich eine der ersten beiden Möglichkeiten zur schnellen Lösung des Problems anwenden, damit ihr das Plugin weiterhin verwenden könnt.

Fazit

Auch durch kleine Fehler, die durch Unkenntnis des Entwicklers entstanden sind, kann es in eurem Blog zu Problemen kommen. Wenn ihr den Fehler gefunden habt, solltet ihr am besten immer direkt dem Entwickler diesen Fehler mitteilen. Ihr werdet euch wundern, wie schnell diese oft reagieren. Wenn ihr es euch zutraut, könnt ihr den Fehler in der Zwischenzeit aber auch selbst beheben.

Veröffentlicht von

Bernhard ist fest angestellter Webentwickler, entwickelt in seiner Freizeit Plugins, schreibt in seinem Blog über WordPress und andere Themen, treibt sich gerne bei den WP Meetups in Berlin und Potsdam herum und läuft nach Feierabend den ein oder anderen Halbmarathon.

2 Kommentare » Schreibe einen Kommentar

  1. Danke für den Beitrag, spricht mir aus der Seele. Bin Entwickler von Leaflet Maps Marker (Pro) – www.mapsmarker.com – und muss gerade im Backend immer wieder mit Plugins kämpfen, welche teilweise mein Plugin unbrauchbar machen.

    Eure Anleitung geht mir aber nicht weit genug – es reicht mMn nicht, wenn nur darauf geachtet wird, ob die Skripte im Frontend und/oder im Backend geladen werden. Zusätzlich sollte diese nur geladen werden, wenn auch wirklich benötigt – fürs Backend heißt dies, dass custom scripts+css nur auf den eigenen Admin-Seiten geladen werden sollen. Ich hab dies in meinem Plugin so umgesetzt (vereinfacht):

    function lmm_admin_menu() {
        $page = add_object_page('Maps Marker', 'Maps Marker', $capabilities, 'leafletmapsmarker_markers', array(&$this, 'lmm_list_markers'), LEAFLET_PLUGIN_URL . 'inc/img/icon-menu-page.png' );
        $page2 = add_submenu_page('leafletmapsmarker_markers', 'Maps Marker - ' . __('List all markers', 'lmm'), ' ' . __('List all markers', 'lmm'), $lmm_options[ 'capabilities_edit' ], 'leafletmapsmarker_markers', array(&$this, 'lmm_list_markers') );
        ...
        add_action('admin_print_styles-'.$page, array(&$this, 'lmm_admin_enqueue_stylesheets'),17);
        add_action('admin_print_styles-'.$page2, array(&$this, 'lmm_admin_enqueue_stylesheets'),18);
        ...
    }
    function lmm_admin_enqueue_stylesheets() {
        global $wp_styles;
        $plugin_version = get_option('leafletmapsmarker_version');
        wp_register_style( 'leafletmapsmarker', LEAFLET_PLUGIN_URL . 'leaflet-dist/leaflet.css', array(), $plugin_version);
        wp_enqueue_style( 'leafletmapsmarker' );
        ...
    }
    

    lg
    Robert

    • Hallo Robert,

      für Funktionalitäten, die im Backend eingesetzt werden hast du natürlich recht. Da sollten die JavaScript und CSS Dateien nur auf den Seiten eingebunden werden, auf denen sie auch benötigt werden. Beim Frontend ist das oft schwieriger, da hier die Inhalte aus dem Plugin eventuell an vielen Stellen eingebunden werden können.

      Ich habe meinen Artikel daher bewusst sehr vereinfacht gehalten, um das prinzipielle Problem darzustellen und zu zeigen, wie man es (hauptsächlich für Frontend-Plugin, die das Backend stören) lösen kann.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert