DeRegisterJQueryTot

WP-Tot schlechthin: wp_deregister_script(‚jquery‘)

Genesis Mining

Widgets lassen sich nicht platzieren oder verschieben, die Zugänglichkeitshilfe muss verwendet werden. Menüeinträge können gar nicht mehr strukturiert werden. Debug-Ausgaben oder Error-Log-Einträge im Apache Error-Log gibts nicht. Was ist hier los, wer hat das Licht ausgemacht?

Auf der Suche nach einem Fehler, warum ich Widgets nicht mehr platzieren, bzw. Menüeinträge zwar hinzufügen, aber nicht mehr verschieben kann, bin ich endlich fündig geworden. Seid ca. zwei Wochen entwickle ich ein WordPress-Design für einen Kunden, das ist alles abgesichert. Sprich: Eclipse mit PHP-Aufsatz mit einem SVN-Repository im Hintergrund. Wenn sich Fehler einschleichen, kann der Zeitpunkt exakt bestimmt werden. Dies setzt vorraus, dass man die Fehlerursache (die Zeile im Quellcode bspw.) findet. Dann kann aber schnell gehandelt werden. Auch praktisch ist es, wenn gestern noch alles lief und heute nicht mehr: Schauen was geändert wurde und dann gezielt überlegen.

Hier war es jetzt etwas schwerer, ich wusste nicht warum diese Standard-Aktionen nicht mehr liefen und wusste nicht genau woran es liegen könnte. Dann habe ich angefangen zu überlegen wie die Drag ’n Drop-Funktkionalität wohl umgesetzt wurde und das JavaScript-Framework jQuery kam mir in den Sinn. Dabei machte es Klick, denn ich verwende jQuery immer über $(„#element“).irgendwastolles();. Mit dem von WordPress gelieferten jQuery ist dies nicht möglich, da muss ich jQuery(„#element“).irgendwastolles(); verwenden. Da auch ein Plugin fest auf die $-Syntax Programmiert war, musste ich also ein „richtiges“ jQuery mit dem Theme mitliefern.

Um es „richtig“ zu machen, habe ich WordPress’s jQuery-File deregistriert, über die Zeile wp_deregister_script(‚jquery‘) und mein eigenes Script über die Zeile wp_register_script(‚jquery‘, get_bloginfo(„stylesheet_directory“) .“/js/jquery.min.js“); registriert. Sobald ich nun wp_enqueue_script(‚jquery‘) aufrief, wurde mein mit dem Theme geliefertes jQuery-Script eingebunden. Die $-Syntax lief wieder und ich habe munter weitergearbeitet.

So bahnte sich allerdings der Fehler an, denn der Menü- und Widget-Bereich im Back-End von WordPress ist anscheinend fest auf das mit WordPress gelieferte jQuery-File ausgerichtet. Die Drag ’n Drop-Funktionalität war nicht mehr gegeben.

WordPress: Drag ’n Drop für Widgets und Menüs wiederherstellen

Relativ simple Sache. Ich bin also in die functions.php-Datei von meinem Theme gegangen, habe aus der Theme-Klasse die Script-Registrierungs-Funktion herausgesucht und mein eigenes jQuery-File nicht „jquery“ sondern „myjquery“ genannt. wp_deregister_script habe ich nun nirgends mehr in Verwendung.

In den zwei Templates, die jQuery verwenden sollen, habe ich natürlich wp_enqueue_script(‚jquery‘) mit wp_enqueue_script(‚myjquery‘) getauscht, damit mein jQuery-File genutzt wird.

Schon läuft alles wieder. Mieser Fehler aber zum Glück simple Lösung.

5 Gedanken zu „WP-Tot schlechthin: wp_deregister_script(‚jquery‘)

  1. Andreas

    Danke für den Tipp! Hatte eben bei der Entwicklung unseres Framework das gleiche Problem und es dadurch gelöst, alle Funktionen nun umzuschreiben. Es wäre darauf hinzuweisen, das es performanter ist, das Script nur einmal zu laden, anstatt zweimal einzubinden.

    Antworten
  2. Oliver Lippert

    Hey Andreas,
    inzwischen würde ich das original jQuery von WP nicht ersetzen.

    Ich schreibe am Anfang meiner JS-Codes „var $ = jQuery.noConflict();“ aber ich glaube, dass es noch bessere Wege gibt ^^

    Bspw: http://api.jquery.com/ready/

    jQuery(document).ready(function($) {
    // Code using $ as usual goes here.
    });

    In dem ready-Event-Handler kann man dann munter mit $ programmieren, auch wenn Außerhalb lediglich das jQuery-Objekt zur Verfügung steht.

    Antworten
    1. Andreas

      Ich bin genau deiner Meinung. Hatte mich im Post wohl etwas ungenau ausgedrückt.
      Natürlich sollte, vor allen dingen im Backend, das original JQuery nicht / niemals ersetzt werden.

      jQuery.noConflict und die anschließende Zuweisung eines Shortcuts geht natürlich auch…

      var $irgendwas = jQuery.noConflict();
      // jQuery mit variable $irgendwas(…) nutzen
      $irgendwas(document).ready(function(){
      $irgendwas(„div“).hide();
      });

      Antworten
      1. Oliver Lippert

        Hey Andreas,
        mal sehen, vielleicht finde ich Zeit und Blogge darüber noch mal seperat. noConflict würde ich auf jeden Fall nicht verwenden.

        jQuery(document).ready(function($){
        alert($(„h1“).text());
        });

        sowas ungefähr sollte nach allen Regeln der Kunst konform sein.

        Gruß,
        Oli

        Antworten

Schreibe einen Kommentar

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