Sie installieren ein Plugin, und es schleppt seine eigene Kopie von jQuery mit. Ihr Theme hat jQuery bereits über wp_enqueue_script geladen. Das Plugin lädt es zusätzlich direkt von einem CDN. Auf der Seite: zwei oder sogar drei Versionen derselben Bibliothek. Konflikte, aufgeblähte Größe, unvorhersehbares Verhalten.

Das Problem ist so alt wie WordPress selbst, und es passiert immer noch: Entwickler kopieren <script src="jquery.js"> in die header.php, „weil es schneller geht". Schneller, bis zum ersten Konflikt mit einem Plugin, das die native WP-Version erwartet.

Mit Stand 2026 liefert WordPress jQuery 3.6.0 von Haus aus und bietet einen einfachen, deterministischen Weg, es ohne Duplikate und ohne manuelle Versionsverfolgung einzubinden. Nachfolgend der einzig korrekte Ansatz, vom grundlegenden wp_enqueue_script über das sichere Ersetzen durch eine CDN-Version bis hin zum noConflict-Modus.

💡 Kurzüberblick:

• Wie WordPress jQuery bereits lädt und warum Sie das nicht manuell tun sollten
• wp_enqueue_script mit der jquery-Abhängigkeit: eine Zeile in functions.php
• Wann und wie Sie das eingebaute jQuery sicher durch eine CDN-Version ersetzen (Google / cdnjs)
• noConflict-Modus: Schutz vor Kollisionen mit anderen Bibliotheken
• Hinweise für Themes und Plugins: wann Sie das eingebaute jQuery NICHT überschreiben sollten

JQuery ist bereits im Core: was WordPress für Sie erledigt

Seit Version 3.6 registriert WordPress jQuery unter dem Handle jquery. Sie müssen jquery.min.js nicht herunterladen, in Ihrem Theme-Ordner ablegen und mit einem <script>-Tag einbinden. Der Core erledigt das automatisch, sobald Sie jquery in den Abhängigkeiten Ihres Skripts angeben.

Die aktuelle jQuery-Version im WordPress-Core ist 3.6.0. Sie wird mit jQuery Migrate ausgeliefert (für Abwärtskompatibilität mit Legacy-Code) und lädt nur, wenn ein Skript jquery als Abhängigkeit deklariert. Keine Abhängigkeiten bedeuten, dass jQuery nicht auf der Seite erscheint und die Website keine unnötigen Ressourcen lädt.

Deshalb ist ein direktes <script src="/wp-content/themes/mytime/jquery.js"> in der header.php ein Fehler, keine Abkürzung. Sie umgehen das Abhängigkeitssystem, entziehen WP die Möglichkeit, die Ladereihenfolge zu steuern, und erhalten ein Duplikat, wenn ein Plugin legitim jquery über wp_enqueue_script anfordert.

Der richtige Weg: wp_enqueue_script mit Abhängigkeit

Die grundlegende Mechanik passt in eine Zeile innerhalb des wp_enqueue_scripts-Hooks. Sie schreiben Ihr Skript, und WordPress ermittelt, wann und in welcher Reihenfolge alles geladen wird.

Erstellen (oder öffnen) Sie die functions.php Ihres Themes und fügen Sie hinzu:

1
function mytheme_enqueue_scripts() {
2
    wp_enqueue_script(
3
        'mytheme-main',
4
        get_template_directory_uri() . '/js/main.js',
5
        array( 'jquery' ),
6
        '1.0.0',
7
        array(
8
            'strategy'  => 'defer',
9
            'in_footer' => true,
10
        )
11
    );
12
}
13
add_action( 'wp_enqueue_scripts', 'mytheme_enqueue_scripts' );

Was hier passiert:

• mytheme-main ist das eindeutige Handle für Ihr Skript. Denken Sie sich ein eigenes aus, mit dem Theme-Namen als Präfix.
• get_template_directory_uri() . '/js/main.js' ist der Pfad zur Datei. Sie können auch eine externe CDN-URL verwenden.
• array( 'jquery' ) ist der entscheidende Punkt: Sie teilen WP mit „mein Skript hängt von jQuery ab". Der Core erkennt das und stellt jQuery automatisch vor Ihrem Skript in die Warteschlange. Keine <script>-Tags im Template.
• '1.0.0' ist die Version für Cache-Busting. Ändern Sie sie bei jedem Skript-Update.
• array( 'strategy' => 'defer', 'in_footer' => true ): Seit WordPress 6.3 akzeptiert der Parameter $args ein Array. defer bedeutet „führe das Skript nach dem Aufbau des DOM aus, aber vor DOMContentLoaded". in_footer platziert das Skript im Footer.

Die alte Syntax mit einem booleschen fünften Parameter (true = im Footer) funktioniert weiterhin, aber für neue Projekte nutzen Sie die Array-Syntax. Sie ist lesbarer und gibt Ihnen Kontrolle über async/defer.

Überprüfen Sie, dass Ihr Theme wp_head() vor dem schließenden </head> und wp_footer() vor </body> aufruft. Ohne diese Aufrufe funktioniert wp_enqueue_script schlicht nicht. Das ist eine häufige Falle bei der Migration von sehr alten Themes.

Wie Sie das eingebaute jQuery durch Ihre eigene Version ersetzen

Manchmal reicht die native Version nicht aus. Sie möchten jQuery 4.0.0 von einem CDN für die neuesten Fehlerbehebungen, oder Sie benötigen eine bestimmte Version für die Kompatibilität mit einem Legacy-Plugin. Sie können es ersetzen, aber mit Vorsicht.

Der Fehler: einfach wp_enqueue_script('jquery', 'https://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js') aufzurufen. WordPress überschreibt KEIN bereits registriertes Handle. Sie erhalten sowohl die native Version als auch die CDN-Version auf derselben Seite.

Die korrekte Reihenfolge: zuerst das native jquery deregistrieren, dann Ihr eigenes registrieren:

1
function mytheme_use_cdn_jquery() {
2
    // Deregister the built-in jQuery
3
    wp_deregister_script( 'jquery' );
4
 
5
    // Register your own — from CDN
6
    wp_register_script(
7
        'jquery',
8
        'https://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js',
9
        array(),
10
        '4.0.0',
11
        true
12
    );
13
 
14
    // Enqueue it
15
    wp_enqueue_script( 'jquery' );
16
}
17
add_action( 'wp_enqueue_scripts', 'mytheme_use_cdn_jquery' );

Drei oft übersehene Punkte:

Google Hosted Libraries. Googles alternatives CDN ist weiterhin aktiv und hostet jQuery 3.7.1: https://ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js. Der Vorteil: Millionen von Websites haben den Browser-Cache für diese URL bereits erwärmt. Der Nachteil: Google fügt eigene Header hinzu und aktualisiert Versionen nicht unmittelbar nach der Veröffentlichung.

cdnjs. Wenn Sie jQuery 4.0.0 benötigen, beziehen Sie es von cdn.jsdelivr.net/npm/[email protected]/. cdnjs spiegelt das npm-Paket und liefert es mit korrekten CORS-Headern aus.

Deregistrieren Sie jQuery nicht in öffentlichen Themes. Wenn Ihr Theme für das WordPress.org-Repository bestimmt ist, verwenden Sie das native jQuery aus dem Core. Der Grund ist einfach: Wenn eine Website sowohl ein Theme (mit CDN-jQuery 4.0.0) als auch ein Plugin (das jQuery 3.6.0 aus dem Core erwartet) hat, löst der Anwender den Konflikt, nicht der Entwickler. In kommerziellen Themes und individuellen Projekten können Sie es bedenkenlos ersetzen.

NoConflict-Modus: wenn mehr als eine Bibliothek auf der Seite ist

Standardmäßig belegt jQuery die globale Variable $. Das Problem: $ ist ein beliebter Name; Prototype, MooTools und einige Legacy-Frameworks verwenden ihn ebenfalls. Wenn ein Plugin oder ein anderes Skript ebenfalls $ beansprucht, gewinnt das zuletzt geladene, und die anderen gehen kaputt.

Schutz in einer Zeile am Anfang Ihres Skripts:

1
var $j = jQuery.noConflict();

Danach ist $ für andere Bibliotheken freigegeben, und Ihr Code arbeitet über $j. Vollständiges Beispiel: eine Seitenleiste mit Hover-Animation:

1
jQuery(document).ready( function( $ ) {
2
    // Here $ is jQuery, but only inside this function
3
    $( '#sidebar li a' ).hover(
4
        function() {
5
            $( this ).stop().animate( { paddingLeft: '20px' }, 400 );
6
        },
7
        function() {
8
            $( this ).stop().animate( { paddingLeft: '0' }, 400 );
9
        }
10
    );
11
} );

Hier funktioniert $ als jQuery innerhalb des jQuery(document).ready()-Closures, und außerhalb ist es für andere frei. Das ist sauberer, als $j-, $jq- und $myJQ-Variablen im gesamten Code zu verteilen.

Wann noConflict nicht nötig ist: Wenn Ihre Website vollständig auf WordPress ohne Drittanbieter-JS-Frameworks läuft und alle Plugins für wp_enqueue_script geschrieben sind, ist $ sicher. Aber noConflict in den Standard-Boilerplate Ihres Themes aufzunehmen, ist eine gute Angewohnheit, die nur eine Zeile kostet.

Was Plugin-Entwickler tun sollten

Wenn Sie ein Plugin für die öffentliche Verteilung schreiben, verwenden Sie ausschließlich wp_enqueue_script mit einer Abhängigkeit von jquery. Kein wp_deregister_script('jquery') innerhalb von Plugins: Sie wissen nicht, welche jQuery-Version andere Plugins auf derselben Website erwarten.

Das korrekte Muster für ein Plugin sieht so aus:

1
function myplugin_frontend_scripts() {
2
    wp_enqueue_script(
3
        'myplugin-frontend',
4
        plugins_url( '/js/frontend.js', __FILE__ ),
5
        array( 'jquery' ),
6
        MYPLUGIN_VERSION,
7
        true
8
    );
9
}
10
add_action( 'wp_enqueue_scripts', 'myplugin_frontend_scripts' );

MYPLUGIN_VERSION ist die Versionskonstante des Plugins. Bei jedem Plugin-Update erhält der Browser des Nutzers ein frisches Skript anstelle eines zwischengespeicherten alten.

Für Admin-Skripte (nur Admin-Panel) verwenden Sie den admin_enqueue_scripts-Hook. jQuery im Admin ist ebenfalls unter demselben Handle jquery registriert.

⁉️🤔 Häufig gestellte Fragen

Warum funktioniert mein jQuery-Code nicht, obwohl wp_enqueue_script korrekt aufgerufen wird?

Die häufigste Ursache: Das Theme ruft wp_head() und wp_footer() nicht auf. Ohne diese Funktionen kann WordPress physisch keine <script>-Tags in das HTML einfügen. Öffnen Sie header.php. Dort sollte <?php wp_head(); ?> vor </head> stehen. In footer.php sollte <?php wp_footer(); ?> vor </body> stehen. Wenn das Theme sehr alt ist und diese Aufrufe fehlen, fügen Sie sie hinzu. Das ist sicher. Alle modernen Themes und Plugins setzen auf wp_head/wp_footer. Ohne sie ist nicht nur das Laden von Skripten gestört, sondern auch SEO-Plugins, Schriftarten und strukturierte Daten.

Kann ich jQuery 4.0.0 in WordPress verwenden, wenn der Core mit 3.6.0 ausgeliefert wird?

Ja, über wp_deregister_script + wp_register_script (siehe Abschnitt oben). Aber beachten Sie: jQuery 4.0.0 hat die Unterstützung für IE 11 und mehrere veraltete Methoden eingestellt. Wenn Ihre Website oder Ihr Plugin auf jQuery Migrate angewiesen ist, bleiben Sie bei der Core-Version oder binden Sie Migrate explizit ein. WordPress bewegt sich schrittweise in Richtung natives JavaScript und React für den Block-Editor, aber jQuery wird noch lange im Core bleiben: zu viele Themes und Plugins hängen davon ab.

Ein Plugin lädt sein eigenes jQuery, obwohl ich es bereits über functions.php eingebunden habe. Was soll ich tun?

Das Plugin hat wahrscheinlich <script src="jquery..."> fest codiert und umgeht damit wp_enqueue_script. Das ist ein Fehler des Plugins. Zwei Lösungen: Finden Sie den direkten Aufruf im Plugin-Code und ersetzen Sie ihn durch wp_enqueue_script mit einer Abhängigkeit (wenn Sie bereit sind, das Plugin zu patchen), oder kontaktieren Sie den Plugin-Autor mit der Bitte, es zu beheben. Als vorübergehende Notlösung können Sie wp_dequeue_script aufrufen oder den Hook des Plugins entfernen, aber das behandelt Symptome statt der Ursache.

Was ist schneller: jQuery aus dem WordPress-Core oder von einem CDN?

Wenn der Browser des Nutzers jQuery bereits von einem CDN (Google oder cdnjs) zwischengespeichert hat, lädt die CDN-Version sofort mit einem 304-Not-Modified-Code. Falls nicht, ist der Unterschied in der Ladegeschwindigkeit zwischen Core und CDN für jQuery vernachlässigbar (etwa 85 KB gzipped). Bei stark frequentierten Projekten spart ein CDN die Bandbreite Ihres Servers; für eine typische WordPress-Website gibt es keinen Unterschied.

Sollten Sie jQuery zugunsten von nativem JS aufgeben

Kurze Antwort: Es hängt vom Projekt ab. Komprimiertes jQuery 4.0.0 wiegt etwa 85 KB. Das ist nicht null, aber auch kein Grund zur Panik. Modernes natives JS (querySelectorAll, fetch und classList) deckt 90% dessen ab, wofür man 2015 jQuery brauchte. Wenn Sie ein neues Theme von Grund auf erstellen und nicht von jQuery-Plugins abhängen, ziehen Sie Vanilla-JS in Betracht. Es ist sauberer und schneller.

Aber wenn das Projekt bereits jQuery-Abhängigkeiten hat (Slider, Galerien, Plugin-UI-Komponenten), machen Sie die Dinge nicht komplizierter als nötig. WordPress lädt jQuery ohnehin, wenn ein Plugin es anfordert. Schreiben Sie saubere wp_enqueue_script-Aufrufe mit Abhängigkeiten, greifen Sie nicht in die Ladereihenfolge-Steuerung des Core ein, und jQuery wird schnell und vorhersagbar funktionieren.

🔗 wp_enqueue_script-Dokumentation | 🔗 wp_deregister_script-Dokumentation