Планируется пересмотр процедуры проверки тем WordPress и встреча с разработчиками для обсуждения изменений

Не используйте add_theme_support( \'custom-background\' ), если фон задается через кастомайзер блоков. Этот хук устарел для современных подходов. Механизм оформления должен адаптироваться под JSON-конфигурацию. Проверяющий не обязан указывать на это. Вы обязаны это знать.

Новый шаблон блоков не требует вызова register_sidebar(). Грид-сетки и гибкая типографика позволяют полностью отказаться от виджетов. Старый подход устарел. Использовать его – все равно что верстать таблицами в 2025 году.

Почему некоторые всё еще грузят jQuery через wp_enqueue_script() вручную? Он уже включен ядром, но больше не нужен в большинстве интерфейсов. Удалите. Перепишите на нативный JavaScript. Нет оправданий.

Внимание! Любая несовместимость с theme.json теперь считается техническим долгом.

Файлы шаблонов нельзя именовать произвольно. home.php не заменит index.html в иерархии, если используется структура блоков. Документация не всегда прямо об этом говорит, но последствия – фатальные.

Вы выносите цветовую палитру в SCSS? Прекратите. Используйте settings.color.palette в конфигурации. Тогда цвета станут доступны редактору и пользователь увидит, что редактирует. Без этого дизайн не управляем.

Кто ещё подключает шрифты через @import в CSS? Это замедляет загрузку. Используйте wp_enqueue_style() с предварительным кэшированием. Или лучше – Google Fonts через локальные файлы. Время реакции системы – это UX.

Важно помнить: синхронизация стилей фронтенда и редактора – обязанность, а не дополнительная опция.

Вопрос на обсуждение с командой: зачем в каждом шаблоне подключается один и тот же блок кода футера? Вынесите повторяющиеся фрагменты в get_template_part(). Производительность – не пожелание, а требование.

Почему никто не проверяет работу темы без плагинов? Без них интерфейс должен оставаться удобным. Это не «дополнение», а база. Ваша визуальная оболочка должна быть самодостаточной. Это и есть архитектурный каркас.

Протестируйте удаление functions.php. Что останется? Если всё ломается – вы в ловушке устаревших решений. Блочная структура должна жить отдельно от PHP-логики. Зависимость от хуков – симптом прошлого.

И наконец. Не надейтесь, что вам подскажут, где ошибка. Спрашивайте себя: «Я бы это одобрил в чужом коде?» Ответ очевиден. И он начинается с отказа от компромиссов.

Как изменились критерии проверки тем WordPress после последнего обновления

Удаляйте использование глобальной переменной $content_width. Теперь она не считается допустимой даже в functions.php. Альтернатива – фильтр content_width.

Исключена поддержка устаревших хук-функций типа add_theme_support( \'automatic-feed-links\' ). Это уже встроено в ядро, повторное объявление не просто бессмысленно – оно мешает.

Важно: наличие неиспользуемых файлов типа screenshot-old.png или old-style.css приводит к отклонению. Любой мусор – под запретом.

Отныне проверяется наличие кастомного wp_body_open(). Его отсутствие расценивается как игнорирование базовой совместимости с ядром. Добавлять его в header.php – обязательное требование.

Принудительное включение jQuery больше не допускается. Если библиотека не нужна напрямую – не подключайте её. Автоматическая проверка это сразу отметит:

function my_enqueue() { wp_enqueue_script( \'jquery\' ); // Не допускается без веской причины }

CSS-файл должен включать лицензии в виде комментариев. Отсутствие лицензионного блока – моментальный отказ. Только полные и чёткие лицензии, без сокращений и домыслов.

Помните: использование нестандартизированных кастомайзер-опций, не зарегистрированных через customize_register, приводит к конфликтам и снижению совместимости.

Теперь оценивается не только наличие функций локализации, но и корректность их использования. Пример недопустимого кода:

_e( \"Привет мир!\" ); // Ошибка – отсутствует текстовый домен

Допускается только так:

_e( \"Привет мир!\", \"mytheme\" );

Если используется блок-редактор, то должен быть добавлен файл theme.json. Без него тема считается несовместимой с текущей архитектурой. Даже при частичной поддержке Gutenberg.

Категорически запрещена модификация глобальных переменных ядра. Пример нарушения:

global $wp_query; $wp_query->query_vars[\'post_type\'] = \'page\'; // Ошибка

Фавиконки? Забудьте о встроенных решениях. Только через Site Icon API. Старая практика вставки иконок в header.php больше не пропускается.

Удалите все следы inline CSS в header.php и footer.php. Это теперь воспринимается как грубое нарушение. Используйте wp_add_inline_style() только в крайних случаях.

Резюме? Не будет. Правила меняются быстро, ошибки – фатальны. Вчерашние стандарты – повод для отклонения сегодня. Всё просто: соответствуешь – проходишь. Нет – доработай.

Что обсуждалось на последней встрече команды Theme Review и как это повлияет на разработчиков

Удалите все jQuery-зависимости, если они не обоснованы. Это теперь не рекомендация – требование. Фреймворк признан источником избыточности и замедлений. Заменяйте на нативный JavaScript. Кто проигнорирует – не пройдет модерацию. Пример адаптации:

document.querySelector(\'.toggle\').addEventListener(\'click\', function() { document.querySelector(\'.menu\').classList.toggle(\'open\'); });

Темы, использующие add_theme_support( \'custom-header\' ) и custom-background, подвергнутся прицельной проверке. Эти функции морально устарели. Команда призывает внедрять поддержку через theme.json. Будет проверяться наличие деклараций по типу:

\"settings\": { \"custom\": { \"background\": \"#ffffff\" } }

Важно: использование theme.json больше не просто тренд – это механизм, на который опирается ядро.

Удаление шаблонных комментариев в style.css станет обязательным. Все дублирующие поля (например, Author URI и Theme URI с одинаковыми значениями) будут расцениваться как спам. Оставляйте только один, с обоснованием. Минимум шума, максимум пользы.

Файлы шаблонов должны иметь точное соответствие структуре сайта. Нет поддержки шаблонов блоков? Ошибка. Отсутствует index.html в block-templates? Отклонение. Слоты должны быть определены. Точка. Пример базового шаблона:

Содержание статьи

• 1 Как изменились критерии проверки тем WordPress после последнего обновления
• 2 Что обсуждалось на последней встрече команды Theme Review и как это повлияет на разработчиков
• 3 Какие шаги нужно предпринять разработчику для соответствия новым требованиям проверки тем

Не используйте add_theme_support( \'custom-background\' ), если фон задается через кастомайзер блоков. Этот хук устарел для современных подходов. Механизм оформления должен адаптироваться под JSON-конфигурацию. Проверяющий не обязан указывать на это. Вы обязаны это знать.

Новый шаблон блоков не требует вызова register_sidebar(). Грид-сетки и гибкая типографика позволяют полностью отказаться от виджетов. Старый подход устарел. Использовать его – все равно что верстать таблицами в 2025 году.

Почему некоторые всё еще грузят jQuery через wp_enqueue_script() вручную? Он уже включен ядром, но больше не нужен в большинстве интерфейсов. Удалите. Перепишите на нативный JavaScript. Нет оправданий.

Внимание! Любая несовместимость с theme.json теперь считается техническим долгом.

Файлы шаблонов нельзя именовать произвольно. home.php не заменит index.html в иерархии, если используется структура блоков. Документация не всегда прямо об этом говорит, но последствия – фатальные.

Вы выносите цветовую палитру в SCSS? Прекратите. Используйте settings.color.palette в конфигурации. Тогда цвета станут доступны редактору и пользователь увидит, что редактирует. Без этого дизайн не управляем.

Кто ещё подключает шрифты через @import в CSS? Это замедляет загрузку. Используйте wp_enqueue_style() с предварительным кэшированием. Или лучше – Google Fonts через локальные файлы. Время реакции системы – это UX.

Важно помнить: синхронизация стилей фронтенда и редактора – обязанность, а не дополнительная опция.

Вопрос на обсуждение с командой: зачем в каждом шаблоне подключается один и тот же блок кода футера? Вынесите повторяющиеся фрагменты в get_template_part(). Производительность – не пожелание, а требование.

Почему никто не проверяет работу темы без плагинов? Без них интерфейс должен оставаться удобным. Это не «дополнение», а база. Ваша визуальная оболочка должна быть самодостаточной. Это и есть архитектурный каркас.

Читайте также:  JavaScript продолжает удерживать лидерство в рейтинге самых популярных языков программирования по версии RedMonk

Протестируйте удаление functions.php. Что останется? Если всё ломается – вы в ловушке устаревших решений. Блочная структура должна жить отдельно от PHP-логики. Зависимость от хуков – симптом прошлого.

И наконец. Не надейтесь, что вам подскажут, где ошибка. Спрашивайте себя: «Я бы это одобрил в чужом коде?» Ответ очевиден. И он начинается с отказа от компромиссов.

Как изменились критерии проверки тем WordPress после последнего обновления

Удаляйте использование глобальной переменной $content_width. Теперь она не считается допустимой даже в functions.php. Альтернатива – фильтр content_width.

Исключена поддержка устаревших хук-функций типа add_theme_support( \'automatic-feed-links\' ). Это уже встроено в ядро, повторное объявление не просто бессмысленно – оно мешает.

Важно: наличие неиспользуемых файлов типа screenshot-old.png или old-style.css приводит к отклонению. Любой мусор – под запретом.

Отныне проверяется наличие кастомного wp_body_open(). Его отсутствие расценивается как игнорирование базовой совместимости с ядром. Добавлять его в header.php – обязательное требование.

Принудительное включение jQuery больше не допускается. Если библиотека не нужна напрямую – не подключайте её. Автоматическая проверка это сразу отметит:

function my_enqueue() { wp_enqueue_script( \'jquery\' ); // Не допускается без веской причины }

CSS-файл должен включать лицензии в виде комментариев. Отсутствие лицензионного блока – моментальный отказ. Только полные и чёткие лицензии, без сокращений и домыслов.

Помните: использование нестандартизированных кастомайзер-опций, не зарегистрированных через customize_register, приводит к конфликтам и снижению совместимости.

Теперь оценивается не только наличие функций локализации, но и корректность их использования. Пример недопустимого кода:

_e( \"Привет мир!\" ); // Ошибка – отсутствует текстовый домен

Допускается только так:

_e( \"Привет мир!\", \"mytheme\" );

Если используется блок-редактор, то должен быть добавлен файл theme.json. Без него тема считается несовместимой с текущей архитектурой. Даже при частичной поддержке Gutenberg.

Категорически запрещена модификация глобальных переменных ядра. Пример нарушения:

global $wp_query; $wp_query->query_vars[\'post_type\'] = \'page\'; // Ошибка

Фавиконки? Забудьте о встроенных решениях. Только через Site Icon API. Старая практика вставки иконок в header.php больше не пропускается.

Читайте также:  Как отобразить пользовательские поля вне цикла в WordPress

Удалите все следы inline CSS в header.php и footer.php. Это теперь воспринимается как грубое нарушение. Используйте wp_add_inline_style() только в крайних случаях.

Резюме? Не будет. Правила меняются быстро, ошибки – фатальны. Вчерашние стандарты – повод для отклонения сегодня. Всё просто: соответствуешь – проходишь. Нет – доработай.

Что обсуждалось на последней встрече команды Theme Review и как это повлияет на разработчиков

Удалите все jQuery-зависимости, если они не обоснованы. Это теперь не рекомендация – требование. Фреймворк признан источником избыточности и замедлений. Заменяйте на нативный JavaScript. Кто проигнорирует – не пройдет модерацию. Пример адаптации:

document.querySelector(\'.toggle\').addEventListener(\'click\', function() { document.querySelector(\'.menu\').classList.toggle(\'open\'); });

Темы, использующие add_theme_support( \'custom-header\' ) и custom-background, подвергнутся прицельной проверке. Эти функции морально устарели. Команда призывает внедрять поддержку через theme.json. Будет проверяться наличие деклараций по типу:

\"settings\": { \"custom\": { \"background\": \"#ffffff\" } }

Важно: использование theme.json больше не просто тренд – это механизм, на который опирается ядро.

Удаление шаблонных комментариев в style.css станет обязательным. Все дублирующие поля (например, Author URI и Theme URI с одинаковыми значениями) будут расцениваться как спам. Оставляйте только один, с обоснованием. Минимум шума, максимум пользы.

Файлы шаблонов должны иметь точное соответствие структуре сайта. Нет поддержки шаблонов блоков? Ошибка. Отсутствует index.html в block-templates? Отклонение. Слоты должны быть определены. Точка. Пример базового шаблона:

Проект, основанный только на PHP-шаблонах, автоматически помечается как устаревший. Команда однозначна: переход на FSE обязателен. Гибридные решения временно допустимы, но под контролем.

Внимание! Не используйте get_template_part() без проверки на существование. Любая ошибка – повод для отклонения.

Обсуждалось также внедрение автоматической валидации theme.json. Разработчикам следует ожидать строгой типизации, отсутствия лишних свойств и следования спецификации. Любые пользовательские поля вне схемы – риск.

Итог? Жестче. Быстрее. Конкретнее. Стандарты изменились. Кто не подстроится – выпадет. У вас есть выбор. И он технический.

Читайте также:  Лучшие практики именования медиа-файлов в WordPress для SEO и удобства управления контентом

Какие шаги нужно предпринять разработчику для соответствия новым требованиям проверки тем

Удалите устаревшие хуки. Если используется add_theme_page() без проверки прав доступа, это баг. Минимум – обернуть в current_user_can().

Уберите прямые вызовы file_get_contents() и fopen() для внешних URL. Используйте wp_remote_get(), иначе получите отказ при публикации.

Никаких inline-стилей через style= в шаблонах. Стиль – в style.css или через wp_add_inline_style(), но только после регистрации через wp_register_style().

Важно! Любой зарегистрированный кастомайзер должен иметь описание. Пропущенное поле description в WP_Customize_Control – причина отклонения.

Обратите внимание на функции перевода. Если до сих пор используется __() без textdomain, пример: __(\'Пример\'), замените на __(\'Пример\', \'название-темы\'). Не подлежит обсуждению.

Автоматическая активация через switch_theme()? Удаляйте. Пользователь должен выбрать вручную. Подмена решений UI – нарушение.

Избегайте include/require вне функций или классов. Пример плохой практики: require_once \'inc/custom-header.php\'; в корне functions.php. Оберните в хук after_setup_theme.

Визуальные иконки – только через wp_enqueue_style() или wp_enqueue_script(). Если SVG – внедрение строго через inline-svg с фильтрацией. Ни один необработанный SVG не пройдет сканер.

Помните: использование get_template_directory() вместо get_template_directory_uri() в ссылках на изображения ломает front-end. Это частая ошибка.

Замените использование create_function() или анонимных функций в хук-системе. PHP 8+ не прощает безымянных конструкций без контекста. Пример плохого кода: add_filter(\'excerpt_length\', function() { return 20; });.

Декларируйте поддержку фич через add_theme_support(), а не просто добавляйте элементы в шаблоны. add_theme_support(\'custom-logo\') обязателен, если в шапке присутствует логотип.

Не прячьте кастомные шаблоны в подпапках без регистрации в page-templates. Если файл templates/about.php, добавьте в начале: /* Template Name: О нас */.

И наконец: избегайте глобальных переменных в шаблонах. Если переменная создается в functions.php, она должна передаваться через wp_localize_script() или set_query_var().

Жестко? Да. Но иначе – отклонение и повторный цикл. Времени на раскачку больше нет.

Проект, основанный только на PHP-шаблонах, автоматически помечается как устаревший. Команда однозначна: переход на FSE обязателен. Гибридные решения временно допустимы, но под контролем.

Внимание! Не используйте get_template_part() без проверки на существование. Любая ошибка – повод для отклонения.

Обсуждалось также внедрение автоматической валидации theme.json. Разработчикам следует ожидать строгой типизации, отсутствия лишних свойств и следования спецификации. Любые пользовательские поля вне схемы – риск.

Итог? Жестче. Быстрее. Конкретнее. Стандарты изменились. Кто не подстроится – выпадет. У вас есть выбор. И он технический.

Какие шаги нужно предпринять разработчику для соответствия новым требованиям проверки тем

Удалите устаревшие хуки. Если используется add_theme_page() без проверки прав доступа, это баг. Минимум – обернуть в current_user_can().

Уберите прямые вызовы file_get_contents() и fopen() для внешних URL. Используйте wp_remote_get(), иначе получите отказ при публикации.

Никаких inline-стилей через style= в шаблонах. Стиль – в style.css или через wp_add_inline_style(), но только после регистрации через wp_register_style().

Важно! Любой зарегистрированный кастомайзер должен иметь описание. Пропущенное поле description в WP_Customize_Control – причина отклонения.

Обратите внимание на функции перевода. Если до сих пор используется __() без textdomain, пример: __(\'Пример\'), замените на __(\'Пример\', \'название-темы\'). Не подлежит обсуждению.

Автоматическая активация через switch_theme()? Удаляйте. Пользователь должен выбрать вручную. Подмена решений UI – нарушение.

Избегайте include/require вне функций или классов. Пример плохой практики: require_once \'inc/custom-header.php\'; в корне functions.php. Оберните в хук after_setup_theme.

Визуальные иконки – только через wp_enqueue_style() или wp_enqueue_script(). Если SVG – внедрение строго через inline-svg с фильтрацией. Ни один необработанный SVG не пройдет сканер.

Помните: использование get_template_directory() вместо get_template_directory_uri() в ссылках на изображения ломает front-end. Это частая ошибка.

Замените использование create_function() или анонимных функций в хук-системе. PHP 8+ не прощает безымянных конструкций без контекста. Пример плохого кода: add_filter(\'excerpt_length\', function() { return 20; });.

Декларируйте поддержку фич через add_theme_support(), а не просто добавляйте элементы в шаблоны. add_theme_support(\'custom-logo\') обязателен, если в шапке присутствует логотип.

Не прячьте кастомные шаблоны в подпапках без регистрации в page-templates. Если файл templates/about.php, добавьте в начале: /* Template Name: О нас */.

И наконец: избегайте глобальных переменных в шаблонах. Если переменная создается в functions.php, она должна передаваться через wp_localize_script() или set_query_var().

Жестко? Да. Но иначе – отклонение и повторный цикл. Времени на раскачку больше нет.