Нови функции на WordPress и конкретни последици за разработчиците

Ако някога сте виждали плъгин да „работи на вашата машина“ и след това да се повреди, вероятно сте го виждали да се поврежда. après малка актуализация на WordPressЗнаете истинския проблем: тихи промени в поведението, повече от видими нови характеристики.

WordPress 6.9.x (и по-точно 6.9.4, стабилна през април 2026 г.) продължава ясна тенденция от страна на ядрото: повече съгласуваност на API, по-голямо засилване на сигурността и разработки в блоковия редактор (Gutenberg), които в крайна сметка засягат вашите теми, вашите исторически шорткодове и интеграциите ви с конструктора на страници.

Какви промени

Промяната, „която има значение“ за разработчиците В 6.9.x не е един-единствен магически API. Това е набор от точки, които, комбинирани, променят начина, по който предоставяте функции: по-добра стандартизация на ресурсите (скриптове/стилове), засилване на входа/изхода (санитизация/ескейпинг) и прогресивно привеждане в съответствие на класическите теми с ограниченията на редактирането на сайтове (FSE).

По-конкретно, видях три области, в които се наблюдава прекъсване в производството на сайтове с версия 6.9.x: лошо декларирани скриптове (лошо зареждане, липсващи зависимости), прекалено разрешителни REST крайни точки (възможности/nonce) и „фрагменти“, наследени от стари уроци, които използват hooks в неподходящ момент.

Активи (JS/CSS): Очакванията относно опашката (зависимости, стратегия за зареждане, версии) са по-строги. Проблемите „Работи без зависимости“ се превръщат в периодични грешки, особено при кеширане/concat/minification.
REST API / сигурност: повече внимание на обратно извикване_на_разрешение, еднократни стойности и проверки на капацитета. Сайтовете с множество редактори (автори, сътрудници) са първите, които биват хванати неподготвени.
Теми и блокове: Екосистемата все повече се насочва към FSE-съвместими модели. Класическите теми остават поддържани, но „старомодните“ интеграции (опции за теми, шорткодове за оформление) изискват план.

За да проследявате промените в поведението, най-добрите ви източници са основните бележки и билети за разработчици:

Методологична бележка: Няма да твърдя, че подверсия ".4" въвежда съществена промяна, която може да доведе до проблеми. На практика проблемите идват по-скоро от натрупването на промени (6.7 → 6.8 → 6.9) и от плъгин/тема, която разчита на остарели предположения. Целта на анализа на "6.9.4" е да ви даде използваем общ преглед на най-съвременните технологии. maintenant, с PHP 8.1+.

Бързо обобщение

Вашият код трябва да е „стриктно“ свързан с опашката. : изрични зависимости, условно зареждане, без скриптове, твърдо инжектирани в долната част.
REST: permission_callback + еднократни изчисления (nonces) вече не са „по избор“, ако изложите действия (дори вътрешни).
Куки с лошо време (init срещу wp_loaded срещу enqueue) стават видими грешки в кеша, блоковия редактор и някои конструктори.
Класически теми: Те остават жизнеспособни, но вие се възползвате от приемането на блоково-съвместими модели (шаблони, стилове, вариации).
Диви 5 / Елементор / Авада: Повечето от проблемите идват от активите и условните изрази (не се зареждат навсякъде), повече отколкото от HTML.
Необходими са незабавни действия бърз одит на вашите активи + REST крайни точки + фрагменти от „стари уроци“.

Преди/След в кода

Ще взема реален случай, с който често отстранявам проблеми: плъгин (или functions.php), който инжектира JS/CSS „както преди“, след което се получава конфликт (jQuery не се зарежда в правилния момент, скриптове за изграждане се зареждат след това, минификация, която пренарежда всичко).

Случай №1: Твърде „хлабаво“ опашкаване на активи (проблеми с кеша и конструкторите)

Преди (често срещан анти-модел)

<?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');
});

Какво се случва зад кулисите: вашият скрипт приема, че jQuery е наличен, но не сте декларирали зависимостта. При някои кешове редът се променя. При Divi/Elementor редакторът зарежда свои собствени пакети и може да забави определени скриптове. Резултатът: периодичен бъг, невъзможен за възпроизвеждане при поискване.

След (стабилен подход 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);

Ключови разлики:

Изрични зависимости край на „работи, стига...“.
Версиите : кешът е правилно анулиран след инсталацията темата/плъгинът са актуални.
Условно : производителност + по-малко конфликти с конструктори на пакети.
Вградено прикрепено към дръжка гарантирана поръчка и лесно отстраняване на грешки.

Случай №2: REST крайната точка е твърде разрешителна (което в крайна сметка представлява реален риск)

Друга класическа грешка: „вътрешна“ REST крайна точка за задействане на действие (изчистване на кеша, повторна синхронизация, импортиране). Много забравени фрагменти кода нямат стабилна permission_callback функция. Това не е „просто добра практика“; това е повърхност за атака.

Преди (опасно)

<?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);
        },
    ));
});

След (разрешения + еднократен номер + стандартизиран отговор)

<?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
    );
}

Ключови разлики:

обратно извикване_на_разрешение Това не е декоративно: това е вашата защита.
Еднократен номер wp_rest : задължително, ако извиквате крайната точка от администратора (или защитен екран).
WP_REST_Response : по-стабилен за JS клиенти (код на състоянието, структура).

Удар на бетона

За (средно напреднали) блогъри

Ще го усетите особено чрез разширенията си: актуализация на WordPress 6.9.x + плъгин, който зарежда скриптове навсякъде, може да забави редактора, да повреди бутон или да задейства грешки в конзолата само на определени страници.

Типичен симптом „Работи на страница А, не на страница Б“. Честа причина: липсващи условни действия, недекларирани зависимости, агресивно кеширане.
Друг симптом Конструкторът се зарежда, но някои модули са празни. Това често е JavaScript конфликт (ред на зареждане, дублирана версия на библиотека).

За разработчици

Работата ви се измества към надеждност: деклариране, изолиране, тестване. „Бързите“ фрагменти са все още възможни, но те трябва да бъдат поставени на правилното място и да се закачат, с чисти зависимости. Често съм виждал грешки, произтичащи от код, копиран в грешен файл (functions.php на родителската тема вместо на дъщерната тема или в плъгин за фрагменти без контрол на версиите).

Съществуващи плъгини Тези, които инжектират JS код или които излагат REST крайни точки без разрешение, са изложени на риск (бъгове + сигурност).
Класически теми Ако смесвате шорткодове за оформление + конструктор + персонализиран JS, редът на зареждане става критичен.
FSE теми (блокови теми) Ще постигнете последователност, ако мигрирате част от оформлението към шаблони/блокове, но трябва да се научите да „мислите за шаблони“, а не за „опции“.

Специфично въздействие върху Divi 5, Elementor, Avada

Трите имат едно общо нещо: зареждат много ресурси, понякога условно, и имат режими на редактор/преглед, които не се държат като фронт-енда.

Диви 5 Внимавайте със скриптовете, заредени само на е_админ() (лош тест), защото Divi има хибридни екрани. По-добре е да се тестват специфични действия (напр. поставяне на опашка на wp_enqueue_scripts + откриване на контекст, ако е необходимо) и избягвайте инжектирането на JS чрез wp_footer без дръжка.
Elementor Ако разработвате персонализиран уиджет, зареждайте ресурсите си само когато уиджетът е наличен (или поне на страниците на Elementor). Колизиите често идват от глобален скрипт, зареден в целия сайт.
Avada Fusion Builder има собствена екосистема от скриптове. Същото правило: явни зависимости + версиране + избягване на двойно зареждане на библиотеки.

Диагностична диаграма (когато „работи, после се поврежда“)

симптом	Вероятна причина	проверка	Решение
Неактивен JS бутон на някои страници	Скриптът е зареден преди зависимостта (jQuery/Bundle) или изобщо не е зареден	Конзола на браузъра + раздел „Мрежа“, проверете реда и наличието на файловете	wp_enqueue_script със зависимости + условно + wp_add_inline_script
REST функция „Забранена“ след актуализация	permission_callback е твърде строг или липсва nonce	Проверете заявката (заглавката X-WP-Nonce), проверете current_user_can	Добавете nonce wp_rest + подходящ капацитет + съобщенияerreur
Бавен редактор на Elementor/Divi	Глобалните активи са твърде големи и са заредени навсякъде.	Profiler (раздел „Производителност“), временно деактивирайте въпросния плъгин	Зареждай само на необходимите страници/контексти
„Случаен“ фрагмент, който се прекъсва след актуализация	Неподходяща кука (init срещу wp_loaded), функцията е извикана твърде рано	WP_DEBUG_LOG + проследяване на стека, проверка на реда на изпълнение	Преместете куката, коригирайте приоритета и проверете дали функцията съществува.
Промените са невидими въпреки внедряването	Кеш (плъгин/CDN/браузър) + версия на статичен ресурс	Изчистване на кешовете + проверка на версията на низа на заявката	Версия чрез wp_get_theme()->get('Version') или filemtime

Рискове, съвместимости и точки за бдителност

Какво е новото (тенденция 6.7 → 6.9.4)

Изискване за чистота Относно ресурсите: WordPress и екосистемата (конструктори, кешове, оптимизация) са по-малко толерантни към скриптове, „инжектирани“ извън конвейера.
Имплицитно втвърдяване : това, което преди се е случвало „случайно“, се случва по-рядко.
Още зони за почивка (плъгини, блокове, потребителски интерфейс): следователно има по-голям риск, ако разрешенията ви са неясни.

Какво се променя (без да е обявено като „неизправно“)

Заповед за изпълнение Лошо избраните куки могат да се превърнат в грешки. Класически пример е твърде ранното регистриране на скриптове (init) и твърде късното им поставяне в опашка или обратното.
Кеширане и минификация : с HTTP/2/3 + плъгини за пакетиране, предположенията за реда на скриптовете са крехки.
Редактори Бек офисът вече не е „отделно място“. Редакторът и конструкторите на сайтове приличат на приложения, така че вашите глобални скриптове ще взаимодействат с тях.

Какво потенциално се счупва

Код от стар урок : фрагменти 2017–2021, които инжектират вграден JS, използват приблизителни куки или изпълняват REST без разрешение.
PHP е твърде стар Ако вашият доставчик на хостинг услуги е бавен, ще се сблъскате с фатални грешки (типизирани свойства, съвпадение и др.). WordPress 6.9.4 работи с препоръчително PHP 8.1+. Проверете вашата производствена среда.
Фрагменти в родителската тема : актуализация на темата = загуба на код = „изчезна“. Това е много често срещан „инцидент“.

Хронология на амортизацията (прагматична)

Основният код рядко се отхвърля внезапно без гратисен период. Реалният риск е, че вашият код разчита на негарантирано поведение (ред, имплицитни зависимости) и в крайна сметка се повреди. Третирайте това като отхвърляне по подразбиране.

Моята препоръка за 2026 г.: обмислете всеки код, който твърдо кодира активи (echo ) comme “à migrer”, même s’il n’y a pas de notice officielle.

Как да мигрирате

Стъпка 1: Бърз одит (30 минути, много рентабилен)

Търсене във вашите плъгини/теми: wp_footer + <script>, echo '<script', admin-ajax.php, register_rest_route без permission_callback.
Избройте страниците, където вашите ресурси са действително необходими (често 10–20% от сайта).
Активиране на регистриране в тестова среда: WP_DEBUG, WP_DEBUG_LOGИзбягвайте да правите това в производствения процес без надзор (риск от изтичане на информация).

<?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

Стъпка 2: Мигриране на активи към дескриптори (и спиране на wild injection)

Две надеждни стратегии за версии: версии на теми/плъгини (просто) или filemtime() (точно, но внимавайте за разпределените FS).

<?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)
    );
});

Стъпка 3: Осигурете REST (възможности + nonce) и го документирайте

Ако крайната ви точка се извиква от предния край (от посетители), еднократният код „wp_rest“ не винаги е достатъчен (и не е публичен механизъм за удостоверяване). В този случай преминете към токени на приложения, подписи или строго ограничете действията. Не позволявайте анонимен достъп до крайна точка „purge/import“.

Стъпка 4: Проверете куките и приоритетите (източник на „фантомни“ грешки)

Реалистични грешки, които виждам:

Използвайте грешната кука : да се наредя на опашка init вместо wp_enqueue_scripts.
Конфликт на приоритети : вашият код се изпълнява преди конструктора/кеша, след което се презаписва.
Функция, извикана преди зареждане : използвате функция на плъгин, докато плъгинът все още не е инициализирал своите класове.

<?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);

Стъпка 5: Контролен списък за съвместимост (подготовка)

Актуализирайте WordPress до версия 6.9.4 на етапа на подготовка.
Актуализиране на Divi 5 / Elementor / Avada + добавки.
Изчистване на кешовете (кеш на плъгини, сървър, CDN) и кеш на браузъра (често забравяно).
Тест: конструктор на страници в режим на редактиране, интерфейс, мобилен, потребител без администраторски права.
Проверете постоянните връзки (запазете отново), ако докоснете маршрутите/пренапишете.

Трябва ли да действаме сега или да чакаме?

Действайте сега ако отметнете поне едно квадратче:

Имате „исторически“ фрагменти (functions.php, плъгин за фрагменти), които не са тествани от дълго време.
Вие предоставяте REST крайни точки или AJAX действия „admin-ajax“ за чувствителни задачи.
Използвате конструктор (Divi 5/Elementor/Avada) и имате глобални персонализирани скриптове.
Имате сайт с множество роли (автори, сътрудници): REST сигурността/възможностите стават неоспорими.

Можеш да почакаш (няколко седмици), ако:

Вашият сайт няма персонализиран код (или е достъпен само чрез реномирани плъгини),
Имате процес на поетапно планиране и месечно актуализиране,
Не излагате никакви персонализирани REST/AJAX повърхности.

Според моя опит, „чакането“ без подготовка за тестване в крайна сметка струва повече. Правилният компромис: редовни актуализации на ядрото, но целенасочени одити на рисковите области (активи + REST + куки).

Съвети за поддръжка

1) Стандартизирайте метода си за добавяне на код

Избягвайте да поставяте фрагменти в родителската тема.
Предпочитайте мини плъгин за „сайт“ (mu-plugin, ако е приложимо) за бизнес логиката.
Ако използвате плъгин за snippets, актуализирайте версията на вашите snippets (Git копие): Виждал съм как snippets се деактивират след PHP грешка и никой не знаеше „какво се е променило“.

2) Минимален брой тестове за планиране за всяка актуализация на WordPress

Фронтенд: ключови страници, формуляри, проследяване.
Администратор: редактор на блокове, екран за изграждане, медия.
Роли: тестване с авторски акаунт (не администраторски) за идентифициране на грешки във възможностите.
Конзолен JS: поне едно бързо преминаване (грешки/предупреждения).

3) Производителност: Натоварва по-малко, но по-добре

Определете условията на вашите ресурси (страница, тип съдържание, наличие на шорткод/блок).
Премахнете библиотеките, които се зареждат два пъти (често с конструктори + маркетингов плъгин).
Версията е правилна, за да се избегнат „лепкави петна“.

4) Сигурност: REST/AJAX и еднократни изрази (nonces)

Всяко действие, което променя нещо, трябва да се провери възможности + нунций.
Не се доверявайте на параметрите от страна на клиента. Систематично ги дезинфекцирайте/валидирайте.

Полезна справка за PHP: Хеширане на пароли в PHP (ако работите с токени) и, от страна на WordPress, функциите за сигурност, изброени в наръчника.

ресурси

ЧЗВ

1) Копирах фрагмент и получавам грешка 500. Какво да направя първо?

Деактивирайте фрагмента (или преименувайте файла, ако го поставяте в плъгин), след което вижте wp-content/debug.log при подготовката. Най-честата грешка остава липсваща точка и запетая или неправилно затворена къдрава скоба.

2) Къде да се постави персонализиран код през 2026 г.: functions.php, plugin, mu-plugin?

За „бизнес“ код (CTA, REST, вътрешно проследяване) препоръчвам малък, специализиран плъгин. functions.php е приемливо за козметични цели, но рискувате да загубите кода при смяна на теми.

3) Моят JS работи във фронтенд интерфейса, но не и в Elementor/Divi. Защо?

Защото редакторът не е интерфейсът. Конструкторите зареждат различни пакети, понякога в рамките на iframe. Заредете скриптовете си чрез wp_enqueue_scriptДекларирайте зависимости и избягвайте прекалено глобални селектори.

4) Трябва ли все още да използвам jQuery?

Ако вашият сайт (или вашият конструктор) вече зависи от него, да, но декларирайте зависимостта. Ако стартирате нов модул, използвайте модерен JavaScript без зависимости и го заредете условно.

5) Защо моята REST крайна точка връща 403, въпреки че съм администратор?

Често, защото нунцият wp_rest не се изпраща (заглавката X-WP-Nonce) или защото тествате от неудостоверен контекст (личен раздел, различен домейн, кеш). Проверете заявката в раздела „Мрежа“.

6) Кой кеш трябва да изчистя след промяна на скрипт?

Като минимум: кеш на плъгините (ако има такъв) + кеш на сървъра/CDN + кеш на браузъра. Ако версията на ресурсите ви не се промени, браузърът ще запази старото копие, дори ако сте „изчистили кеша на WordPress“.

7) Кодът ми не се изпълнява, но не виждам никакви грешки.

Вероятно сте на грешна кука или пък състоянието ви е такова. is_page() / is_admin() Това не съответства на контекста. Добавете временен лог (при подготовката) и проверете приоритета на hook-а.

8) Действия срещу филтри: наистина ли могат да навредят на уебсайта?

Да. Виждал съм разработчици да го използват преди. add_filter При кука, която не присвоява стойност и „чака връщане на стойност“, нищо не се случва. Обратно, връщането на стойност при действие е безсмислено. Проверете документацията за съответната кука.

9) WordPress 6.9.4 изисква ли PHP 8.1?

WordPress остава прагматичен по отношение на съвместимостта, но през 2026 г. PHP 8.1+ е минималната препоръчителна версия За стабилност и сигурност. Много съвременни плъгини вече приемат версия 8.1.

10) Промених някои маршрути/постоянни връзки и получавам грешки 404.

Запазете отново постоянните си връзки (Настройки → Постоянни връзки → Запазване) и проверете правилата си за пренаписване. Това е изключително често срещан пропуск след миграция или добавяне на CPT.