Neue WordPress-Funktionen und konkrete Auswirkungen für Entwickler

Wenn Sie jemals erlebt haben, dass ein Plugin „auf Ihrem Rechner funktioniert“ und dann nicht mehr funktioniert, dann haben Sie es wahrscheinlich auch schon einmal kaputtgehen sehen. Après ein kleineres Update von WordPressSie kennen den eigentlichen Kern der Sache: stille Verhaltensänderungen, nicht sichtbare neue Funktionen.

WordPress 6.9.x (und insbesondere 6.9.4, stabil ab April 2026) setzt einen klaren Trend im Kernbereich fort: mehr API-Konsistenz, mehr Sicherheitsverbesserungen und Weiterentwicklungen im Block-Editor (Gutenberg), die sich letztendlich auf Ihre Themes, Ihre bisherigen Shortcodes und Ihre Page-Builder-Integrationen auswirken.

Was ändert sich

Die Veränderung, die für die Entwickler Version 6.9.x ist keine einzelne magische API. Es handelt sich um eine Reihe von Punkten, die zusammen die Art und Weise verändern, wie Sie Funktionen bereitstellen: bessere Standardisierung von Assets (Skripte/Stile), Absicherung der Ein-/Ausgabe (Bereinigung/Escaping) und schrittweise Angleichung klassischer Themes an die Einschränkungen der Website-Bearbeitung (FSE).

Konkret habe ich drei Bereiche beobachtet, die bei der Produktion von 6.9.x-Websites zu Problemen geführt haben: schlecht deklarierte Skripte (schlechtes Laden, fehlende Abhängigkeiten), zu permissive REST-Endpunkte (Capabilities/Nonce) und „Snippets“, die aus alten Tutorials übernommen wurden und Hooks zum falschen Zeitpunkt verwenden.

Assets (JS/CSS): Die Anforderungen an das Enqueue (Abhängigkeiten, Ladestrategie, Versionen) sind strenger geworden. Probleme, die angeblich ohne Abhängigkeiten funktionieren, treten zunehmend als sporadische Fehler auf, insbesondere im Zusammenhang mit Caching, Concat und Minifizierung.
REST-API / Sicherheit: mehr Aufmerksamkeit auf permission_callback, Nonces und Kapazitätsprüfungen. Websites mit mehreren Bearbeitern (Autoren, Mitwirkenden) sind die ersten, die davon überrascht werden.
Themen und Blöcke: Das Ökosystem tendiert zunehmend zu FSE-kompatiblen Mustern. Klassische Themes werden weiterhin unterstützt, aber „altmodische“ Integrationen (Theme-Optionen, Layout-Shortcodes) erfordern eine Planung.

Um Verhaltensänderungen nachzuverfolgen, sind die wichtigsten Entwicklerhinweise und Tickets die besten Quellen:

Methodischer Hinweis: Ich behaupte nicht, dass eine Unterversion „.4“ eine gravierende Inkompatibilität mit sich bringt. In der Praxis entstehen Inkompatibilitäten eher durch die Anhäufung von Änderungen (6.7 → 6.8 → 6.9) und durch Plugins/Themes, die auf veralteten Annahmen basieren. Ziel einer Analyse von „6.9.4“ ist es, Ihnen einen nützlichen Überblick über den aktuellen Stand der Technik zu geben. maintenant, mit PHP 8.1+.

Kurze Zusammenfassung

Ihr Code muss beim Enqueue-Mechanismus „streng“ sein. : explizite Abhängigkeiten, bedingtes Laden, keine fest in die Fußzeile eingebundenen Skripte.
REST: permission_callback + nonces sind nicht mehr „optional“, wenn Sie Aktionen offenlegen (auch interne).
Haken mit schlechtem Timing (init vs wp_loaded vs enqueue) werden zu sichtbaren Fehlern im Cache, im Block-Editor und bei einigen Buildern.
Klassische Themen: Sie bleiben zwar weiterhin praktikabel, aber Sie profitieren von der Verwendung blockkompatibler Muster (Vorlagen, Stile, Variationen).
Divi 5 / Elementor / Avada: Die meisten Probleme entstehen durch Assets und Bedingungen (die nicht überall geladen werden) und weniger durch HTML.
Sofortiges Handeln erforderlich : Schneller Überblick über Ihre Assets + REST-Endpunkte + Code-Snippets aus „alten Tutorials“.

Vorher/Nachher im Code

Nehmen wir als Beispiel einen realen Fall, den ich häufig behebe: ein Plugin (oder eine functions.php), das JS/CSS "wie bisher" einbindet, was dann zu Konflikten führt (jQuery wird nicht zum richtigen Zeitpunkt geladen, Builder-Skripte werden später geladen, die Minifizierung ordnet alles neu an).

Fall #1: Asset-Einbettung zu „locker“ (Probleme mit Cache und Buildern)

Vorher (häufiges Anti-Muster)

<?php
// Mauvais exemple : injection directe, pas de dépendances, pas de version, pas de condition.
add_action('wp_footer', function () {
    ?>
    <script>
    // Code inline difficile à déboguer, souvent cassé par la minification
    jQuery(function($){
        $('.cta').on('click', function(){ alert('ok'); });
    });
    </script>
    <?php
});

// Mauvais exemple : style chargé partout, même dans l'admin et le builder
add_action('wp_enqueue_scripts', function () {
    wp_enqueue_style('mon-style', get_stylesheet_directory_uri() . '/assets/style.css');
});

Was im Hintergrund passiert: Ihr Skript setzt jQuery voraus, obwohl Sie die Abhängigkeit nicht deklariert haben. Bei manchen Caches ändert sich die Reihenfolge. Divi/Elementor lädt seine eigenen Bundles und kann dadurch bestimmte Skripte verzögern. Die Folge: ein sporadisch auftretender Fehler, der sich nicht reproduzieren lässt.

Nach (robuster Ansatz WordPress 6.9.4+)

<?php
/**
 * Enqueue propre : dépendances, versioning, conditionnel, et inline script attaché au handle.
 * Compatible WordPress 6.9.4+ / PHP 8.1+.
 */
add_action('wp_enqueue_scripts', function () {

    // Exemple de condition : ne chargez pas sur tout le site si ce n'est utile que sur une page.
    if ( ! is_page('contact') ) {
        return;
    }

    $theme_version = wp_get_theme()->get('Version');

    // CSS versionné
    wp_enqueue_style(
        'mon-style',
        get_stylesheet_directory_uri() . '/assets/style.css',
        array(),
        $theme_version
    );

    // JS externe versionné + dépendances explicites
    wp_enqueue_script(
        'mon-cta',
        get_stylesheet_directory_uri() . '/assets/cta.js',
        array('jquery'),
        $theme_version,
        array(
            'in_footer' => true,
        )
    );

    // Inline script attaché au bon handle (évite l'injection "au hasard" dans le footer)
    $inline = <<<JS
jQuery(function($){
    $('.cta').on('click', function(){
        alert('ok');
    });
});
JS;

    wp_add_inline_script('mon-cta', $inline, 'after');
}, 20);

Wesentliche Unterschiede:

Explizite Abhängigkeiten Schluss mit „Es funktioniert, solange…“.
Versionierung Cache ordnungsgemäß ungültig gemacht nach der Installation Theme/Plugin auf dem neuesten Stand.
Conditionnel : bessere Performance + weniger Konflikte mit Builder-Bundles.
Inline an einem Griff befestigt Garantierte Ordnung und einfache Fehlersuche.

Fall #2: REST-Endpunkt zu permissiv (was letztendlich ein echtes Risiko darstellt)

Ein weiterer klassischer Fehler: ein „interner“ REST-Endpunkt, um eine Aktion auszulösen (Cache leeren, neu synchronisieren, importieren). Viele vergessene Code-Schnipsel haben keine robuste `permission_callback`-Funktion. Das ist nicht nur eine „gute Vorgehensweise“, sondern eine potenzielle Sicherheitslücke.

Vorher (gefährlich)

<?php
add_action('rest_api_init', function () {
    register_rest_route('monplugin/v1', '/purge', array(
        'methods'  => 'POST',
        'callback' => function () {
            // Dangereux : aucune permission, aucune vérification
            do_action('monplugin_purge_cache');
            return array('ok' => true);
        },
    ));
});

Nach (Berechtigungen + Nonce + standardisierte Antwort)

<?php
add_action('rest_api_init', function () {

    register_rest_route('monplugin/v1', '/purge', array(
        'methods'             => 'POST',
        'callback'            => 'monplugin_rest_purge_cache',
        'permission_callback' => function (WP_REST_Request $request) {

            // 1) Capacité : adaptez selon votre besoin (manage_options est volontairement strict).
            if ( ! current_user_can('manage_options') ) {
                return false;
            }

            // 2) Nonce REST : attendu via header X-WP-Nonce côté JS.
            $nonce = $request->get_header('X-WP-Nonce');
            if ( ! $nonce || ! wp_verify_nonce($nonce, 'wp_rest') ) {
                return false;
            }

            return true;
        },
    ));
});

/**
 * Callback REST.
 */
function monplugin_rest_purge_cache(WP_REST_Request $request): WP_REST_Response {
    do_action('monplugin_purge_cache');

    return new WP_REST_Response(
        array(
            'ok'      => true,
            'message' => 'Cache purgé.',
        ),
        200
    );
}

Wesentliche Unterschiede:

permission_callback Es ist nicht dekorativ: Es ist Ihr Schutz.
Nonce wp_rest : unbedingt erforderlich, wenn Sie den Endpunkt vom Administratorbereich (oder einem geschützten Bildschirm) aus aufrufen.
WP_REST_Response : stabiler für JS-Clients (Statuscode, Struktur).

Konkrete Auswirkungen

Für (mittelschwere) Blogger

Besonders deutlich wird es bei Ihren Erweiterungen: Ein WordPress 6.9.x-Update in Kombination mit einem Plugin, das überall Skripte lädt, kann den Editor verlangsamen, einen Button unbrauchbar machen oder Konsolenfehler nur auf bestimmten Seiten auslösen.

Typisches Symptom „Es funktioniert auf Seite A, aber nicht auf Seite B.“ Häufige Ursache: fehlende Bedingungen, nicht deklarierte Abhängigkeiten, aggressives Caching.
Ein weiteres Symptom Der Builder wird geladen, aber einige Module sind leer. Dies deutet häufig auf einen JavaScript-Konflikt hin (Ladefolge, doppelte Version einer Bibliothek).

Für Entwickler

Ihre Arbeit verlagert sich hin zu mehr Zuverlässigkeit: Deklarieren, isolieren, testen. „Schnelle“ Code-Schnipsel sind weiterhin möglich, müssen aber an der richtigen Stelle platziert und eingebunden werden, mit sauberen Abhängigkeiten. Ich habe oft gesehen, dass Fehler dadurch entstehen, dass Code in die falsche Datei kopiert wurde (z. B. in die functions.php des Eltern-Themes anstatt in die des Kind-Themes oder in ein Snippet-Plugin ohne Versionskontrolle).

Vorhandene Plugins Wer JavaScript inline einfügt oder REST-Endpunkte ohne Erlaubnis offenlegt, ist gefährdet (Fehler + Sicherheit).
Klassische Themen Wenn Sie Layout-Shortcodes, Builder und benutzerdefiniertes JS mischen, wird die Ladefolge entscheidend.
FSE-Themes (Block-Themes) Sie gewinnen an Konsistenz, wenn Sie einen Teil des Layouts auf Muster/Blöcke umstellen, aber Sie müssen lernen, „in Vorlagen zu denken“ statt in „Optionen“.

Spezifische Auswirkungen auf Divi 5, Elementor, Avada

Eines haben die drei gemeinsam: Sie laden viele Ressourcen, manchmal auch bedingt, und sie verfügen über Editor-/Vorschaumodi, die sich nicht wie das Frontend verhalten.

Divi 5 Vorsicht vor Skripten, die nur auf diesem System geladen werden ist_admin() (Schlechter Test), da Divi Hybrid-Bildschirme verwendet. Es ist besser, spezifische Aktionen zu testen (z. B. das Einreihen in die Warteschlange auf …). wp_enqueue_scripts + Kontexterkennung, falls erforderlich) und Vermeidung des JS-Injections über wp_footer ohne Griff.
Elementor Wenn Sie ein benutzerdefiniertes Widget entwickeln, laden Sie Ihre Ressourcen nur, wenn das Widget vorhanden ist (oder zumindest auf Elementor-Seiten). Konflikte entstehen häufig durch ein globales Skript, das auf der gesamten Website geladen wird.
Avada Fusion Builder verfügt über ein eigenes Skript-Ökosystem. Es gilt die gleiche Regel: explizite Abhängigkeiten + Versionsverwaltung + Vermeidung des doppelten Ladens von Bibliotheken.

Diagnosediagramm (wenn es „funktioniert und dann kaputt geht“)

Symptom	Mögliche Ursache	Überprüfung	Lösung
Auf einigen Seiten ist die JavaScript-Schaltfläche inaktiv.	Das Skript wurde vor der Abhängigkeit (jQuery/Bundle) geladen oder gar nicht geladen.	Browserkonsole + Netzwerk-Tab: Überprüfen Sie die Reihenfolge und das Vorhandensein der Dateien.	wp_enqueue_script mit Abhängigkeiten + bedingter Anweisung + wp_add_inline_script
REST-Funktion „Verboten“ nach Aktualisierung	permission_callback zu streng oder Nonce fehlt	Überprüfen Sie die Anfrage (Header X-WP-Nonce), prüfen Sie current_user_can	Nonce wp_rest + entsprechende Kapazität + Meldungen hinzufügenerreur
Elementor/Divi Editor langsam	Die globalen Vermögenswerte sind zu groß und überall verteilt.	Profiler (Registerkarte „Leistung“), deaktivieren Sie das betreffende Plugin vorübergehend.	Nur auf den notwendigen Seiten/Kontexten laden.
Code-Snippet „random“, das nach dem Update nicht mehr funktioniert	Unpassender Hook (init statt wp_loaded), Funktion zu früh aufgerufen	WP_DEBUG_LOG + Stacktrace, Ausführungsreihenfolge prüfen	Verschieben Sie den Hook, passen Sie die Priorität an und überprüfen Sie, ob die Funktion existiert.
Änderungen trotz Bereitstellung unsichtbar	Cache (Plugin/CDN/Browser) + Version der statischen Assets	Cache leeren + Abfragezeichenfolgenversion prüfen	Version über wp_get_theme()->get('Version') oder filemtime

Risiken, Kompatibilitäten und Punkte, auf die geachtet werden sollte

Was ist neu (Trend 6.7 → 6.9.4)

Reinigungsanforderungen Was die Ressourcen betrifft: WordPress und das Ökosystem (Builder, Caches, Optimierung) sind weniger tolerant gegenüber Skripten, die außerhalb der Pipeline „eingeschleust“ werden.
Implizite Härtung Was früher „zufällig“ geschah, geschieht heute seltener.
Weitere Rastplätze (Plugins, Blöcke, Benutzeroberfläche): Daher besteht ein höheres Risiko, wenn Ihre Berechtigungen unklar sind.

Was ändert sich (ohne als "bahnbrechend" angekündigt zu werden)?

Vollstreckungsbefehl Ungünstig gewählte Hooks können zu Fehlern führen. Ein klassisches Beispiel ist die zu frühe Registrierung von Skripten (init) und deren zu spätes Einreihen in die Warteschlange, oder umgekehrt.
Zwischenspeicherung und Minifizierung Bei HTTP/2/3 + Bündelungs-Plugins sind Annahmen über die Reihenfolge der Skripte fragil.
Herausgeber Der Backoffice-Bereich ist nicht länger „ein separater Ort“. Der Website-Editor und die Bausteine ähneln Apps, sodass Ihre globalen Skripte mit ihnen interagieren.

Was geht möglicherweise kaputt?

Code aus einem alten Tutorial : Code-Snippets aus den Jahren 2017–2021, die Inline-JS einfügen, approximative Hooks verwenden oder REST ohne Erlaubnis ausführen.
PHP ist zu alt Bei langsamen Hosting-Anbietern können schwerwiegende Fehler auftreten (z. B. bei typisierten Eigenschaften oder Übereinstimmungen). WordPress 6.9.4 benötigt mindestens PHP 8.1. Bitte überprüfen Sie Ihre Produktionsumgebung.
Ausschnitte aus dem übergeordneten Theme : Theme-Update = Codeverlust = „Es ist weg“. Dies ist ein sehr häufiges „Problem“.

Zeitlicher Ablauf der Abschreibung (pragmatisch)

Kerncode wird selten ohne Übergangsfrist abrupt als veraltet markiert. Das eigentliche Risiko besteht darin, dass Ihr Code auf nicht garantiertem Verhalten (Reihenfolge, implizite Abhängigkeiten) beruht und schließlich nicht mehr funktioniert. Behandeln Sie dies standardmäßig als veraltete Funktion.

Meine Empfehlung für 2026: Überlegen Sie sich jeden Code, der Assets fest codiert (echo ) comme “à migrer”, même s’il n’y a pas de notice officielle.

Wie migriert man?

Schritt 1: Schnellprüfung (30 Minuten, sehr kostengünstig)

Durchsuchen Sie Ihre Plugins/Themes: wp_footer + <script>, echo '<script', admin-ajax.php, register_rest_route ohne permission_callback.
Listen Sie die Seiten auf, auf denen Ihre Assets tatsächlich benötigt werden (oft 10–20 % der Website).
Protokollierung in einer Staging-Umgebung aktivieren: WP_DEBUG, WP_DEBUG_LOGDies sollte in der Produktion nicht ohne Aufsicht durchgeführt werden (Gefahr von Informationslecks).

<?php
// wp-config.php (staging uniquement)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false); // Évite d'afficher les erreurs aux visiteurs

Schritt 2: Assets in Handles migrieren (und die unkontrollierte Injektion stoppen)

Zwei zuverlässige Strategien für die Versionsverwaltung: Theme-/Plugin-Versionsverwaltung (einfach) oder filemtime() (zutreffend, aber Vorsicht bei verteilten Dateisystemen).

<?php
add_action('wp_enqueue_scripts', function () {

    $file = get_stylesheet_directory() . '/assets/cta.js';
    $url  = get_stylesheet_directory_uri() . '/assets/cta.js';

    // Attention : filemtime() peut être coûteux sur certains hébergements réseau.
    $ver = file_exists($file) ? (string) filemtime($file) : wp_get_theme()->get('Version');

    wp_enqueue_script(
        'mon-cta',
        $url,
        array('jquery'),
        $ver,
        array('in_footer' => true)
    );
});

Schritt 3: REST-Schnittstelle (Capabilities + Nonce) absichern und dokumentieren

Wird Ihr Endpunkt vom Frontend (von Besuchern) aufgerufen, ist die Nonce „wp_rest“ nicht immer ausreichend (und stellt keinen öffentlichen Authentifizierungsmechanismus dar). Verwenden Sie in diesem Fall Anwendungstoken oder Signaturen oder schränken Sie Aktionen streng ein. Erlauben Sie keinen anonymen Zugriff auf einen „Löschen/Importieren“-Endpunkt.

Schritt 4: Hooks und Prioritäten prüfen (Quelle für „Geisterfehler“)

Realistische Fehler, die ich sehe:

Den falschen Haken verwenden : sich in die Warteschlange einreihen init statt wp_enqueue_scripts.
Prioritätenkonflikt Ihr Code wird vor dem Builder/Cache ausgeführt und anschließend überschrieben.
Funktion wird vor dem Laden aufgerufen. Sie verwenden eine Funktion eines Plugins, während das Plugin seine Klassen noch nicht initialisiert hat.

<?php
// Exemple : si vous dépendez d'un plugin, évitez d'appeler ses classes trop tôt.
add_action('plugins_loaded', function () {

    if ( ! class_exists('MaLib\Client') ) {
        // Le plugin dépendant n'est pas chargé ou pas actif
        return;
    }

    // Initialisation sûre ici
}, 20);

Schritt 5: Kompatibilitätscheckliste (Staging)

Aktualisieren Sie WordPress auf der Staging-Umgebung auf Version 6.9.4.
Aktualisieren Sie Divi 5 / Elementor / Avada + Add-ons.
Cache leeren (Plugin-Cache, Server-Cache, CDN) und Browser-Cache (oft vergessen).
Test: Seiteneditor im Bearbeitungsmodus, Frontend, Mobilgerät, Nicht-Administratorbenutzer.
Überprüfen Sie die Permalinks (und speichern Sie sie erneut), wenn Sie die Routen/Rewrite-Einstellungen ändern.

Sollen wir jetzt handeln oder abwarten?

Handel jetzt Wenn Sie mindestens ein Kästchen ankreuzen:

Sie haben "historische" Code-Snippets (functions.php, Snippet-Plugin), die seit langer Zeit nicht mehr getestet wurden.
Sie stellen REST-Endpunkte oder „admin-ajax“-AJAX-Aktionen für sensible Aufgaben bereit.
Sie verwenden einen Builder (Divi 5/Elementor/Avada) und haben globale benutzerdefinierte Skripte.
Sie haben eine Website mit mehreren Rollen (Autoren, Mitwirkende): REST-Sicherheit/Funktionalität ist unerlässlich.

Du kannst warten (ein paar Wochen) wenn:

Ihre Website enthält keinen benutzerdefinierten Code (oder nur über seriöse Plugins).
Sie haben einen Staging- und einen monatlichen Aktualisierungsprozess.
Sie stellen keine benutzerdefinierten REST/AJAX-Schnittstellen bereit.

Meiner Erfahrung nach verursacht das „Abwarten“ ohne Staging letztendlich höhere Kosten. Der richtige Kompromiss: regelmäßige Kern-Updates, aber gezielte Audits von Risikobereichen (Assets + REST + Hooks).

Wartungstipps

1) Standardisieren Sie Ihre Methode zum Hinzufügen von Code

Vermeiden Sie es, Code-Snippets in das übergeordnete Theme einzufügen.
Für die Geschäftslogik empfiehlt sich ein Mini-„Site“-Plugin (gegebenenfalls mu-Plugin).
Wenn Sie ein Snippets-Plugin verwenden, versionieren Sie Ihre Snippets (Git-Kopie): Ich habe schon erlebt, dass Snippets nach einem PHP-Fehler deaktiviert wurden und niemand wusste, „was sich geändert hatte“.

2) Mindestanzahl an Tests, die für jedes WordPress-Update geplant werden sollten

Frontend: Wichtige Seiten, Formulare, Tracking.
Administrator: Blockeditor, Builder-Oberfläche, Medien.
Rolle: Testen mit einem Autorenkonto (nicht Administratorkonto), um Funktionsfehler zu identifizieren.
Console JS: mindestens ein schneller Durchlauf (Fehler/Warnungen).

3) Leistung: Weniger Last, aber besser

Bedingungen für Ihre Assets (Seite, Inhaltstyp, Vorhandensein eines Shortcodes/Blocks).
Entfernen Sie Bibliotheken, die doppelt geladen werden (häufig bei Builders + Marketing-Plugin).
Versionieren Sie korrekt, um „klebrige Patches“ zu vermeiden.

4) Sicherheit: REST/AJAX und Nonces

Jede Aktion, die etwas verändert, muss überprüft werden. Ressourcen + Nuntius.
Vertrauen Sie nicht auf clientseitige Parameter. Bereinigen/validieren Sie diese systematisch.

Nützliche Referenz für PHP: PHP-Passwort-Hashing (falls Sie Tokens verwenden) und, auf der WordPress-Seite, die im Handbuch aufgeführten Sicherheitsfunktionen.

Ressourcen

FAQ

1) Ich habe einen Codeausschnitt kopiert und erhalte einen 500-Fehler. Was soll ich als Erstes tun?

Deaktivieren Sie den Code-Schnipsel (oder benennen Sie die Datei um, falls Sie sie in einem Plugin platziert haben), und schauen Sie dann nach. wp-content/debug.log Beim Staging ist der häufigste Fehler nach wie vor ein fehlendes Semikolon oder eine nicht korrekt geschlossene geschweifte Klammer.

2) Wo soll der benutzerdefinierte Code in 2026 platziert werden: functions.php, plugin, mu-plugin?

Für "Business"-Code (CTA, REST, internes Tracking) empfehle ich ein kleines, dediziertes Plugin. functions.php Für kosmetische Zwecke ist dies akzeptabel, allerdings besteht die Gefahr, dass der Code beim Wechsel des Designs verloren geht.

3) Mein JavaScript funktioniert im Frontend, aber nicht in Elementor/Divi. Warum?

Weil der Editor nicht das Frontend ist. Builder laden unterschiedliche Bundles, manchmal innerhalb eines iFrames. Laden Sie Ihre Skripte über wp_enqueue_scriptDeklarieren Sie Abhängigkeiten und vermeiden Sie übermäßig globale Selektoren.

4) Muss ich jQuery weiterhin verwenden?

Wenn Ihre Website (oder Ihr Website-Builder) bereits davon abhängt, ja, aber deklarieren Sie die Abhängigkeit. Wenn Sie ein neues Modul erstellen, verwenden Sie modernes JavaScript ohne Abhängigkeiten und laden Sie es bedingt.

5) Warum gibt mein REST-Endpunkt den Fehlercode 403 zurück, obwohl ich Administrator bin?

Oft, weil der Nuntius wp_rest wird nicht gesendet (Header) X-WP-Nonce), oder weil Sie in einem nicht authentifizierten Kontext testen (privater Tab, andere Domäne, Cache). Überprüfen Sie die Anfrage im Netzwerk-Tab.

6) Welchen Cache muss ich nach der Änderung eines Skripts leeren?

Mindestens: Plugin-Cache (falls vorhanden) + Server-/CDN-Cache + Browser-Cache. Wenn sich Ihre Asset-Version nicht ändert, behält der Browser die alte Kopie bei, selbst wenn Sie den WordPress-Cache geleert haben.

7) Mein Code läuft nicht, aber ich sehe keine Fehler.

Sie hängen wahrscheinlich am falschen Haken, oder Ihr Zustand is_page() / is_admin() Dies passt nicht zum Kontext. Fügen Sie einen temporären Logeintrag (auf der Staging-Umgebung) hinzu und überprüfen Sie die Hook-Priorität.

8) Aktionen vs. Filter: Können sie eine Website wirklich lahmlegen?

Ja. Ich habe das schon bei Entwicklern gesehen. add_filter Bei einem Hook, der keinen Wert zuweist und auf einen Rückgabewert wartet, passiert nichts. Umgekehrt ist es sinnlos, bei einer Aktion einen Wert zurückzugeben. Lesen Sie die Dokumentation des entsprechenden Hooks.

9) Benötigt WordPress 6.9.4 PHP 8.1?

WordPress bleibt in Bezug auf Kompatibilität pragmatisch, aber im Jahr 2026 PHP 8.1+ ist die empfohlene Mindestversion. Für Stabilität und Sicherheit. Viele moderne Plugins setzen bereits Version 8.1 voraus.

10) Ich habe einige Routen/Permalinks geändert und erhalte nun 404-Fehler.

Speichern Sie Ihre Permalinks erneut (Einstellungen → Permalinks → Speichern) und überprüfen Sie Ihre Rewrite-Regeln. Dies wird nach einer Migration oder dem Hinzufügen von benutzerdefinierten Beitragstypen (CPTs) sehr häufig übersehen.