Използвайте „Какво е новото за разработчиците“ в WordPress

Ако вече сте актуализирали WordPress И ако впоследствие откриете, че дадена кука е променила поведението си, че вашият плъгин задейства предупреждение на PHP 8.1 или че JS компонент на блоковия редактор е остарял, знаете истинската цена на „Ще го разгледам по-късно“. Разделът „Какво е новото за разработчиците?“ (бележките разработчиците от всяка версия) е точно противоотровата... стига да се консумира правилно, а не като обикновена публикация в блога.

Проблемът / Нуждата

Необходимостта е проста: искате да предвидите техническите промени в WordPress (ядро), които влияят на вашите теми, плъгини, фрагменти и интеграции (Divi, Elementor, Avada), без да губите часове в четене на Trac тикети или GitHub PRs.

Според моя опит, повечето „мистериозни“ инциденти след инсталацията Актуалната информация идва от три неща:

• Игнорирани остарели версии (PHP, JS, WP API) до деня, в който се превърнат в грешки.
• Неоткрити промени в поведението (възможности, REST, редактор на блокове, заявка).
• Разлики в средата (кеш, минификация, PHP версии), които маскират предупрежденията.

В крайна сметка ще знаете:

• Четете ефективно „Какво е новото за разработчиците?“ за WordPress 6.9.x (април 2026 г.) и за извличане на използваем контролен списък.
• Автоматизирайте част от работата: идентифицирайте амортизация, регистрирайте и задействайте администраторски известия.
• Тествайте щателно промените, преди да ги пуснете в производство.

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

• Ще трансформираме нотите „Какво е новото за разработчиците?“ en процес целенасочено четене + извличане + тестване.
• Ще напишем мини плъгин „помощник за издаване“, който ще:
  • показва списък като администратор,
  • активира дневник за амортизация (PHP) от страната на WP_DEBUG_LOG,
  • добави режим на наблюдение (известие от администратора) след актуализация.
• Ще използваме стабилни API: администраторски куки, опции, възможности, екраниране и малко опционален JS.
• Съвместимост с целеви обекти: WordPress 6.9.4, PHP 8.1 +.
• Ще завършим с възпроизводим метод за тестване (стадиране + WP-CLI + лог файлове).

Кога да използвате това решение

• Поддържате сайт (или няколко) с „исторически“ фрагменти в дъщерна тема или плъгин за фрагменти.
• Разработвате тема/плъгин и искате да намалите регресиите с всяка версия на WordPress.
• Управлявате сайтове с конструктор на страници (Divi 5, Elementor, Avada) и искате бързо да идентифицирате конфликти (скриптове, стилове, куки).
• Вече сте преживели инцидент след актуализация (бял екран, REST грешки, счупени блокове) и искате предпазна мрежа.

Кога НЕ трябва да използвате това решение

• Не можете да активирате WP_DEBUG И ако нямате достъп до сървърни лог файлове, ще бъдете слепи за остарелите версии на PHP. В този случай, дайте приоритет на наблюдаемостта чрез доставчика на хостинг услуги (лог файлове на приложенията) или APM.
• Вашият сайт е „без код“ и никога не го докосвате functions.php / плъгини: по-добре е просто да следвате бележките към изданието и да поверите валидирането на вашия доставчик.
• Ако търсите цялостен анализ на основните промени, най-добрият източник остават заявките/PR-тата. Бележките „Какво е новото за разработчиците?“ са продължи, не е пълна истина.

Предварителни изисквания / преди започване

Преди всичко:

• Работете върху постановка (копие на сайта) със същата PHP версия и същия кеш/CDN стек, ако е възможно.
• Уверете се, че сте вътре WordPress 6.9.4 et PHP 8.1 +Предупрежденията зависят силно от PHP.
• Направете резервно копие (файлове + база данни) и си запишете текущата версия + списък с плъгини.

Полезни инструменти:

• Блог за разработчици (WordPress.org) : тук се появяват публикациите „Какво е новото за разработчиците?“.
• Справочник на функциите на WordPress (за да проверите API, без да се стига до стар урок).
• WordPress Core Trac (когато в бележката се споменава промяна, се връщате към билета).
• wordpress-development в GitHub (за да прочетете разликата и да разберете „защо“).
• php.net — грешка в конфигурацията (полезно, ако трябва да коригирате регистрирането).

Сигурност: ще добавим администраторска страница и опции за магазина. Ще проверим възможностите (manage_options), ще използваме еднократни стойности (nonces) за действия и ще екранираме целия HTML изход.

Наивният подход (и защо да го избягваме)

Това, което често виждам: някой преглежда набързо „Какво е новото за разработчиците?“, забелязва два реда и бързо добавя откъс в... functions.php...и забравете всичко останало.

Типичен пример (анти-шаблон): активиране на постоянен „режим на отстраняване на грешки“ в продукцията или писане на администраторско известие без разрешения.

<?php
// ❌ Exemple à éviter : pas de permission, pas de nonce, et debug permanent.
add_action('admin_notices', function () {
    echo '<div class="notice notice-warning"><p>Vérifiez les nouveautés dev de la dernière version.</p></div>';
});

// ❌ Exemple à éviter : forcer l'affichage des erreurs (risque sécurité + UX).
@ini_set('display_errors', '1');
error_reporting(E_ALL);

Защо това е проблем:

• Сигурност Показването на PHP грешки може да разкрие пътища, тайни и версии на сървъра.
• Поддръжка Няма запис за това какво е проверено, нито за това какво остава да се направи.
• Изпълнение : ненужни администраторски известия навсякъде, а понякога и лог файлове, които растат без ротация.
• Качество : не тествате реални сценарии (редактор, REST, cron, front-end, конструктор на страници).

Правилният подход — стъпка по стъпка урок

Идеята: използвате „Какво е новото за разработчиците?“ като поток на запаситеНе се опитваш да запомниш всичко, а се опитваш да екстракт което влияе на вашия код, след това към prouver че всичко работи чрез тестове и лог файлове.

Стъпка 1 — Определете вашата „област на въздействие“

Преди дори да отворите бележките, направете списък:

• Вашите входни точки: дъщерна тема, mu-плъгини, персонализиран плъгин, фрагменти, REST интеграции, блокове, шорткодове.
• Рискови области: плащане в WooCommerce, формуляри, търсене, конструктор на страници, REST крайни точки, cron.

Често съм виждал актуализации, които нарушават само редактора (Gutenberg) или само REST API. Ако тествате само предния край, пропускате проблема.

Стъпка 2 — Прочетете „Какво е новото за разработчиците?“ като контролен списък

Когато отворите публикацията за версията (напр. 6.9), винаги търсете:

• Амортизация (PHP/JS) и „остарял“: това са вашите технически дългове.
• Важни промени или промени в поведението: това са вашите непосредствени рискове.
• Изпълнение Понякога промяна в кеша/заявката променя реда на изпълнение или времената.
• REST API : разрешения, схеми, полета, удостоверяване.
• Блоков редактор скриптове, пакети, промени в поддръжката на блокове.

Стъпка 3 — Инсталирайте мини плъгин „release assistant“

Ще създадете плъгин (препоръчително), вместо да поставяте код в functions.phpТова предотвратява загубата на данни по време на промяна на тема и улеснява деактивирането.

Създайте папка:

wp-content/plugins/wp-release-dev-assistant/

След това файл:

wp-content/plugins/wp-release-dev-assistant/wp-release-dev-assistant.php

Този плъгин ще:

• Добавете страница „Помощник за разработка на версии“ ​​под „Инструменти“.
• Запазете опция „най-новата валидирана версия на WP“.
• Показване на известие, ако инсталираната версия е по-нова от валидираната версия.
• Активирайте регистрирането на амортизациите (без показването им на екрана).

Стъпка 4 — Активирайте правилното регистриране (първо подгответе)

На екрана за подготовка активирайте:

• WP_DEBUG
• WP_DEBUG_LOG
• WP_DEBUG_DISPLAY à false

Справка: Отстраняване на грешки в WordPress.

Стъпка 5 — Тествайте сценариите и „маркирайте“ версията като валидирана

След като завършите тестовете си, щракнете върху „Маркирай тази версия като валидирана“. Инструкциите изчезват и вие запазвате запис.

Пълен код

Копирайте и поставете този файл такъв, какъвто е, в wp-content/plugins/wp-release-dev-assistant/wp-release-dev-assistant.phpСлед това активирайте плъгина в администраторския панел.

<?php
/**
 * Plugin Name: WP Release Dev Assistant
 * Description: Aide à exploiter "What's new for developers?" en transformant une mise à jour WordPress en checklist + validations + logging de dépréciations.
 * Version: 1.0.0
 * Requires at least: 6.9
 * Requires PHP: 8.1
 * Author: Votre Nom
 * License: GPLv2 or later
 */

if (!defined('ABSPATH')) {
    exit;
}

final class WP_RDA_Plugin {

    private const OPTION_VALIDATED_VERSION = 'wp_rda_validated_wp_version';
    private const OPTION_ENABLE_DEPRECATION_LOG = 'wp_rda_enable_deprecation_log';

    public static function init(): void {
        add_action('admin_menu', [__CLASS__, 'register_admin_page']);
        add_action('admin_init', [__CLASS__, 'register_settings']);

        // Notice uniquement en admin, et uniquement pour les admins.
        add_action('admin_notices', [__CLASS__, 'maybe_show_update_notice']);

        // Logging des dépréciations : on branche tôt, mais après le chargement WP.
        add_action('plugins_loaded', [__CLASS__, 'maybe_hook_deprecation_logging'], 1);

        // Action sécurisée pour "valider" la version.
        add_action('admin_post_wp_rda_validate_version', [__CLASS__, 'handle_validate_version']);
    }

    public static function register_admin_page(): void {
        add_management_page(
            'Release Dev Assistant',
            'Release Dev Assistant',
            'manage_options',
            'wp-release-dev-assistant',
            [__CLASS__, 'render_admin_page']
        );
    }

    public static function register_settings(): void {
        register_setting(
            'wp_rda_settings',
            self::OPTION_ENABLE_DEPRECATION_LOG,
            [
                'type'              => 'boolean',
                'sanitize_callback' => static function ($value) {
                    return (bool) $value;
                },
                'default'           => true,
            ]
        );
    }

    public static function maybe_show_update_notice(): void {
        if (!current_user_can('manage_options')) {
            return;
        }

        $validated = get_option(self::OPTION_VALIDATED_VERSION, '');
        $current   = get_bloginfo('version');

        // Si aucune validation n'a été faite, on affiche une notice "soft".
        if ($validated === '') {
            echo self::render_notice(
                'info',
                'Aucune version WordPress n’a été marquée comme validée sur ce site. Après vos tests, marquez la version actuelle comme validée dans Outils → Release Dev Assistant.'
            );
            return;
        }

        // Si la version actuelle est plus récente que la version validée, on alerte.
        if (version_compare($current, $validated, '>')) {
            $message = sprintf(
                'WordPress est en %1$s, mais la dernière version validée est %2$s. Lisez “What’s new for developers?” pour la/les version(s) intermédiaire(s), testez, puis validez.',
                esc_html($current),
                esc_html($validated)
            );
            echo self::render_notice('warning', $message);
        }
    }

    private static function render_notice(string $type, string $message): string {
        $allowed_types = ['info', 'warning', 'error', 'success'];
        if (!in_array($type, $allowed_types, true)) {
            $type = 'info';
        }

        return sprintf(
            '<div class="notice notice-%1$s"><p>%2$s</p></div>',
            esc_attr($type),
            wp_kses_post($message)
        );
    }

    public static function render_admin_page(): void {
        if (!current_user_can('manage_options')) {
            wp_die(esc_html__('Accès refusé.', 'wp-rda'));
        }

        $current   = get_bloginfo('version');
        $validated = get_option(self::OPTION_VALIDATED_VERSION, '');
        $enabled   = (bool) get_option(self::OPTION_ENABLE_DEPRECATION_LOG, true);

        $validate_url = wp_nonce_url(
            admin_url('admin-post.php?action=wp_rda_validate_version'),
            'wp_rda_validate_version'
        );
        ?>
        <div class="wrap">
            <h2>Release Dev Assistant</h2>

            <p>
                Version WordPress actuelle : <strong><?php echo esc_html($current); ?></strong><br>
                Dernière version marquée comme validée : <strong><?php echo esc_html($validated !== '' ? $validated : 'Aucune'); ?></strong>
            </p>

            <hr>

            <h3>Checklist pratique (basée sur “What’s new for developers?”)</h3>
            <ol>
                <li>Lire les sections <em>Dépréciations</em> (PHP/JS) et noter ce qui touche votre code.</li>
                <li>Vérifier les changements REST API (permissions, schémas, champs).</li>
                <li>Tester l’éditeur : création/édition, patterns, blocs réutilisables, widgets blocs.</li>
                <li>Tester le front : formulaires, recherche, pages builder, performance (cache).</li>
                <li>Relire <code>wp-content/debug.log</code> et corriger les warnings/dépréciations.</li>
            </ol>

            <hr>

            <h3>Options</h3>
            <form method="post" action="options.php">
                <?php
                settings_fields('wp_rda_settings');
                ?>

                <p>
                    <label>
                        <input type="checkbox" name="<?php echo esc_attr(self::OPTION_ENABLE_DEPRECATION_LOG); ?>" value="1" <?php checked($enabled); ?>>
                        Activer le logging des dépréciations PHP dans <code>debug.log</code> (recommandé sur staging)
                    </label>
                </p>

                <p>
                    <button class="button button-primary" type="submit">Enregistrer</button>
                </p>
            </form>

            <hr>

            <h3>Valider la version</h3>
            <p>
                Quand vous avez terminé vos tests pour WordPress <strong><?php echo esc_html($current); ?></strong>, marquez-la comme validée.
            </p>
            <p>
                <a class="button button-secondary" href="<?php echo esc_url($validate_url); ?>">Marquer cette version comme validée</a>
            </p>

            <hr>

            <h3>Raccourcis utiles</h3>
            <ul>
                <li>Docs Debug : <a href="https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/" target="_blank" rel="noopener">developer.wordpress.org</a></li>
                <li>Developer Blog : <a href="https://developer.wordpress.org/news/" target="_blank" rel="noopener">developer.wordpress.org/news</a></li>
                <li>Trac : <a href="https://core.trac.wordpress.org/" target="_blank" rel="noopener">core.trac.wordpress.org</a></li>
            </ul>

        </div>
        <?php
    }

    public static function handle_validate_version(): void {
        if (!current_user_can('manage_options')) {
            wp_die(esc_html__('Accès refusé.', 'wp-rda'));
        }

        check_admin_referer('wp_rda_validate_version');

        $current = get_bloginfo('version');

        // On stocke la version courante comme "validée".
        update_option(self::OPTION_VALIDATED_VERSION, $current, true);

        wp_safe_redirect(
            add_query_arg(
                [
                    'page'    => 'wp-release-dev-assistant',
                    'updated' => '1',
                ],
                admin_url('tools.php')
            )
        );
        exit;
    }

    public static function maybe_hook_deprecation_logging(): void {
        $enabled = (bool) get_option(self::OPTION_ENABLE_DEPRECATION_LOG, true);
        if (!$enabled) {
            return;
        }

        // Si WP_DEBUG_LOG n'est pas actif, on ne force rien : on évite les surprises en prod.
        if (!defined('WP_DEBUG_LOG') || !WP_DEBUG_LOG) {
            return;
        }

        /**
         * WordPress déclenche des hooks spécifiques lors de l’utilisation de fonctions dépréciées.
         * - deprecated_function_run
         * - deprecated_argument_run
         * - deprecated_hook_run
         *
         * Référence : hooks visibles dans wp-includes/functions.php (wordpress-develop).
         */
        add_action('deprecated_function_run', [__CLASS__, 'log_deprecated_function'], 10, 3);
        add_action('deprecated_argument_run', [__CLASS__, 'log_deprecated_argument'], 10, 3);
        add_action('deprecated_hook_run', [__CLASS__, 'log_deprecated_hook'], 10, 4);
    }

    public static function log_deprecated_function(string $function, string $replacement, string $version): void {
        self::write_log_line(sprintf(
            'DEPRECATION (function) %1$s deprecated since %2$s. Replacement: %3$s',
            $function,
            $version,
            $replacement !== '' ? $replacement : 'n/a'
        ));
    }

    public static function log_deprecated_argument(string $function, string $message, string $version): void {
        self::write_log_line(sprintf(
            'DEPRECATION (argument) %1$s deprecated since %2$s. Message: %3$s',
            $function,
            $version,
            $message !== '' ? $message : 'n/a'
        ));
    }

    public static function log_deprecated_hook(string $hook, string $replacement, string $version, string $message): void {
        self::write_log_line(sprintf(
            'DEPRECATION (hook) %1$s deprecated since %2$s. Replacement: %3$s. Message: %4$s',
            $hook,
            $version,
            $replacement !== '' ? $replacement : 'n/a',
            $message !== '' ? $message : 'n/a'
        ));
    }

    private static function write_log_line(string $line): void {
        // On évite d’exploser les logs avec des multi-lignes.
        $line = str_replace(["r", "n"], ' ', $line);

        // error_log écrit dans debug.log si WP_DEBUG_LOG est activé.
        error_log('[WP_RDA] ' . $line);
    }
}

WP_RDA_Plugin::init();

Обяснение на кода

Общ преглед (опростен)

Плъгинът прави три неща:

• Показва се известие, ако WordPress е актуализиран, но не е „валидиран“ (това налага спазване на правилата за тестване).
• Предоставя администраторска страница с контролен списък и бутон за валидиране.
• Регистрира отхвърлянията на WordPress в debug.log чрез специални куки.

Технически подробности (куки, безопасност, качество)

• admin_menu : добавя страница под „Инструменти“. Предимство: минимално натрапчиво, без персонализирано меню на първо ниво.
• register_setting : регистрира типизирана опция (bool). Дезинфекцираме изрично.
• admin_notices : показва известие само ако current_user_can('manage_options')Това избягва безпокойството за издателите/авторите.
• admin_post_* : крайна точка на администратора за обработка на действието „валидиране на версията“. Защитаваме с nonce (check_admin_referer) и разрешение.
• Отчитане на амортизацията WordPress задейства действия, когато се използва остаряла функция/аргумент/hook. Ние ги слушаме и след това записваме в тях. debug.log от error_log() (който уважава) WP_DEBUG_LOG).
• Бягството : esc_html за текста, esc_url за URL адреси, wp_kses_post за съобщението с известие (ако искате да добавите връзки към него по-късно).

Защо не го насилвам WP_DEBUG В рамките на плъгина: това е настройка на средата. Принудителното отстраняване на грешки от плъгин е неприятна изненада в производствената среда и може да се превърне в инцидент със сигурността.

Варианти и случаи на употреба

Вариант 1 — Добавяне на диагностична таблица „след актуализация“

Ако управлявате множество сайтове, често ще ви е необходима таблица „симптом → проверка → решение“ директно в администраторския панел. Можете да обогатите тази страница със статична (или генерирана) таблица въз основа на вашите повтарящи се проблеми.

симптом	Вероятна причина	проверка	Решение
Бял екран след актуализация	Фатална грешка в PHP (несъвместимост с PHP 8.1+, плъгин)	Lit debug.log и сървърни логове	Деактивирайте дефектния плъгин, поправете го, актуализирайте
Блокове, които вече не се зареждат в администраторски режим	Конфликт на JavaScript / минификация / остарял пакет	Конзола на браузъра + деактивиране на оптимизацията	Изключване на скриптове, актуализиране на конструктора, коригиране на поставяне в опашката
REST API връща 401/403	Промяна на разрешение/ограничение, крехка персонализирана крайна точка	Тестова крайна точка с токен/бисквитка	Виж отново permission_callback, капацитети, монахини
Неработещи стилове в конструктора на страници	Кеш/CDN, CSS поръчка, комбиниран актив	Изчистване на кешовете, сравняване на HTML/CSS	Изчистване на кеша, коригиране на приоритетите на опашката

Вариант 2 — Регистрирайте и PHP грешки (с повишено внимание)

Можете да добавите PHP обработчик на грешки, но аз рядко го правя на „нормален“ сайт: това може да удвои лог файловете и да усложни отстраняването на проблеми. Ако го направите, ограничете го до тестови среди и никога не го показвайте на предния край.

Полезна справка за PHP: set_error_handler().

Вариант 3 — Свържете валидирането с „тестов набор“

На по-професионални сайтове замествам бутона „валидиране“ с условна валидация: версията се валидира само ако е посетен набор от страници (smoke test) и ако логът не съдържа нови версии на отхвърлени версии. Това изисква повече код (и място за съхранение), но предотвратява грешката „Кликнах без да тествам“.

Съвместимост с Divi 5 / Elementor / Avada

„Какво е новото за разработчиците?“ често засяга блоковия редактор, скриптовете и API-тата. Конструкторите на страници не са пряко засегнати... докато промяна в ресурси, JS зависимости или администраторски куки не причини конфликт.

Диви 5

• Divi зарежда много ресурси в администраторския панел и предния панел. Ако видите грешки в конзолата след актуализиране на WordPress, опитайте временно да деактивирате минифицирането/комбинирането (Divi + плъгин за кеширане).
• Вашият плъгин не инжектира никакви скриптове, така че рискът е нисък. Съобщението за администратора може да се появи в администраторския панел на Divi: това е умишлено, но е ограничено до администратори.

Elementor

• След актуализация на WordPress, тествайте редактора на Elementor (режим на редактиране) и предварителния преглед. Там често се откриват конфликти (конзола, XHR заявки).
• Ако Elementor активира своя „Безопасен режим“, вашите регистрационни файлове за остаряване остават полезни за разграничаване на „ядро“ от „добавка“.

Авада (Fusion Builder)

• Avada има собствен CSS/JS конвейер. След актуализацията изчистих кеша на Avada, използвах плъгин за кеширане и се свързах с CDN. Видях някои „регресии“, които бяха просто стари обслужвани ресурси.
• Вашият плъгин добавя страница под „Инструменти“, а не в менютата на Avada: няма колизия в потребителския интерфейс.

Проверки след инсталацията

1. Активирайте плъгина, след което отидете на Инструменти → Асистент за разработка на версии.
2. Проверете дали се появява администраторското съобщение (ако не е валидирана версия).
3. При подготовката, активирайте WP_DEBUG + WP_DEBUG_LOGСлед това умишлено предизвикайте депрециране (например чрез активиране на стар плъгин в режим на подготовка) и проверете това wp-content/debug.log съдържа редове [WP_RDA] DEPRECATION ....
4. Кликнете върху „Маркирай тази версия като валидирана“, след което проверете дали:
   • Опцията е запазена.
   • Инструкциите изчезват (ако са идентични).
5. Актуализирайте WordPress (на етап на подготовка) до по-висока версия: съобщението би трябвало да се появи отново.

Ако това не проработи

1. Плъгинът не се показва : проверете пътя и името на файла. Често срещана грешка е създаването на файла на грешното място (напр. wp-content/plugin вместо wp-content/plugins).
2. Фатална грешка при активиране Вижте точното съобщение. Често:
   • un ; липсващ,
   • странно кодиран файл,
   • остаряла версия на PHP (плъгинът изисква 8.1+).
3. Няма дневници за амортизация :
   • уверете се, че WP_DEBUG_LOG добро е true,
   • проверете това wp-content/debug.log е записваем,
   • потвърдете, че амортизацията действително е задействана (на чист сайт може да няма нищо).
4. Инструкциите остават валидни дори след валидиране. :
   • Изчистете кеша на администратора (кеш на плъгини, обект на постоянен кеш),
   • проверете дали опцията wp_rda_validated_wp_version е правилно актуализиран (чрез плъгин тип „Проверка на състоянието“ или чрез базата данни).
5. Нищо не се случва, когато щракнете върху „валидиране“. :
   • Моля, потвърдете, че сте администратор.
   • Проверете дали еднократният номер (nonce) не е блокиран от агресивен кеш.
   • Тествайте, като временно деактивирате плъгина за сигурност, който филтрира admin-post.php.

Често срещани капани и грешки

Грешка	Причина	Решение
Кодът е поставен в functions.php и изгубен след смяна на темата	Лошо местоположение	Използвайте специален плъгин (като този) или mu-плъгин
Parse error: syntax error	Липсва скоба / точка и запетая	Копирайте и поставете целия файл, проверете редактора и активирайте показването на грешки на екрана за подготовка.
Известие, видимо за всички потребители	Забравяне current_user_can()	Ограничете до администратори (напр. manage_options)
Инструкциите никога не се появяват	Неподходяща закачка или приоритет	употреба admin_notices (подходящи wp_footer) и да не излизам твърде рано
Няма логове, въпреки че WP_DEBUG_LOG е активиран	Незаписваем файл / различен път / блокиран хост error_log	Проверка на разрешенията, сървърни логове, PHP конфигурация, тест error_log('test')
„Добре“ тестове, но грешка в продукцията	Различен кеш/CDN/минификация	Възпроизвеждане на стека в етап на подготовка, почистване на кешове, сравняване на заглавки
Амортизацията е игнорирана, защото „все още работи“	Технически дълг	Третирайте остарелите версии като заявки за поправка преди следващото издание
Конфликт с плъгина за фрагменти	Фрагментът е зареден два пъти / ред на зареждане	Деактивирайте дубликатите, използвайте един плъгин, проверете plugins_loaded
Неработещи постоянни връзки след актуализация (404)	Негенерирани правила за пренаписване	Отидете в Настройки → Постоянни връзки → Запазване

Съвети за безопасност, производителност и поддръжка

• Не влизайте в производствената система по подразбиране. пазя WP_DEBUG_LOG за подготвителна работа или да го активирате временно в производствен режим в случай на инцидент (и след това да го деактивирате).
• Въртене на трупите : debug.log Може да расте бързо. На сайтове с висок трафик съм виждал файлове с размер от няколко гигабайта. Приложете ротация на файлове от страна на сървъра.
• Третирайте остарелите версии като грешки Обезценяването днес често се превръща в обезценяване утре. Точно това ви позволява да предвидите в статията „Какво е новото за разработчиците?“.
• Бъдеща съвместимост Съхраняването на валидираната версия като опростен вариант е стабилно. Избягвайте автоматичното анализиране на външно съдържание (RSS/HTML) в администраторския панел: това е крехко и може да доведе до рискове (временни ограничения, инжектирано съдържание и др.).
• Администратор на производителността Инструкциите са кратки. Записването е пасивно и се активира само ако WP_DEBUG_LOG е вярно.

ресурси

• Блог за разработчици на WordPress (къде да намерите „Какво е новото за разработчиците?“)
• Отстраняване на грешки в WordPress (WP_DEBUG, WP_DEBUG_LOG, най-добри практики)
• Препратка: add_action()
• WordPress Core Trac (промяна на билети)
• GitHub хранилище wordpress-develop (разлики и история)
• php.net: конфигуриране и регистриране на грешки

Често задавани въпроси

„Какво е новото за разработчиците?“ съществува ли за всяка второстепенна версия?

Най-често публикациите „Какво е новото за разработчиците?“ се фокусират върху основни версии (напр. 6.9). Минорните версии (6.9.1, 6.9.2…) обикновено са издания за поддръжка/сигурност, с по-кратки бележки за изданието. За минорно издание все още проверявам Trac/GitHub, за да видя дали дадена корекция засяга чувствителна област (REST, редактор, мултисайт).

Защо да съхраняваме „валидирана версия“?

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

Този плъгин замества ли четенето на бележките за изданието?

Не. Това ви принуждава да свършите работата в точното време и ви дава място за централизиране на контролен списък. Източникът остава блогът на разработчиците и, ако е необходимо, Trac/GitHub.

Защо не се извлича автоматично съдържанието „Какво е новото за разработчиците?“ в администраторския панел?

Защото е крехко (HTML се променя) и носи рискове (времена на изчакване, външно съдържание). Предпочитам линк към официалния източник и стабилен контролен списък, който да адаптирате към контекста си.

Не виждам обезценяване в debug.logТова нормално ли е?

Да. Един чист и актуален сайт може да не генерира никакви резултати. Отхвърлянията се появяват главно при стари плъгини, остарял персонализиран код или JS интеграции.

Съвместим ли е с множество сайтове?

Да, но опцията се съхранява на ниво сайт (не на ниво мрежа). Ако искате валидиране на ниво мрежа, трябва да използвате мрежови опции (get_site_option/update_site_option) и добавете страницата към мрежовата администрация.

Използвам PHP 8.0, работи ли това?

Плъгинът изисква PHP минимум 8.1. Технически, някои части биха могли да работят на 8.0, но ще пропуснете предупрежденията и ограниченията, специфични за 8.1+. За процес на актуализация на WordPress през 2026 г. препоръчвам привеждане в съответствие с 8.1+.

Къде точно е „Какво е новото за разработчиците?“?

На Блог за разработчициПотърсете публикацията за изданието (напр. „WordPress 6.9 Field Guide“ или „What's new for developers in 6.9“). В зависимост от изданието, форматът може да варира, но целта остава същата: обобщение, ориентирано към разработчиците.

Може ли това да доведе до фалшиви положителни резултати (показване на известие, въпреки че всичко е наред)?

Да, и това е умишлено: инструкциите не казват „не работи“, а казват „не е валидирано“. В среди, където WordPress се актуализира автоматично, това всъщност е добро напомняне.

Мога ли да го използвам с плъгин за фрагменти, вместо със специален плъгин?

Възможно е, но аз го избягвам. Плъгините за фрагменти са удобни, но съм виждал фрагменти, повредени поради случайно неправилно обработване или заредени в неочакван ред. За инструмент за обработка (валидиране + регистриране), специален плъгин е по-стабилен.