Как отключить emoji в WordPress через код и проверить, что это не сломало редактор и кэш

Автор: Виктор Орлов | Опубликовано: 16.09.2026

Если на сайте WordPress не нужны встроенные emoji, их можно убрать без плагинов и без риска сломать контент. На практике задача обычно сводится не к «отключить смайлики», а к более конкретной цели: убрать лишние запросы в <head>, не тащить отдельный скрипт wp-emoji-release.min.js, не плодить лишние подключения в админке и не конфликтовать с кэшем.

Это полезно для небольших и средних сайтов, где важна чистота фронтенда и предсказуемость сборки. Но отключать emoji стоит именно как техническую оптимизацию, а не как «ускоритель на 20%»: эффект обычно точечный, зато решение простое и обратимое.

Когда отключение emoji действительно нужно

Проблема чаще всего заметна в исходном коде страницы. WordPress по умолчанию добавляет проверку emoji на фронтенде и в админке. Если сайт работает на русском языке и вы не используете встроенную поддержку старых браузеров, этот код обычно не даёт практической пользы.

Типичные признаки

в <head> есть инлайн-скрипт с wp-emoji-settings;
подключается /wp-includes/js/wp-emoji-release.min.js;
в HTML появляются лишние теги, которые не нужны для проекта;
после включения агрессивного кэша или минификации возникают лишние различия между версиями страниц.

Если вы видите только один из этих признаков, это уже достаточный повод убрать emoji штатным способом через хуки. Не нужно править ядро или вырезать файлы из wp-includes.

Диагностика: что именно отключать

Сначала проверьте, где именно подключается emoji. На фронтенде это обычно видно в исходном коде страницы, а в админке — в консоли браузера или в списке загружаемых ресурсов. Если сайт использует редактор блоков, важно не трогать лишнее в админке без необходимости: иногда владельцы отключают всё подряд и потом получают странные эффекты в редакторе.

Проверка простая:

Откройте любую страницу сайта в браузере.
Посмотрите исходный код и найдите wp-emoji-release.min.js.
Проверьте, есть ли инлайн-скрипт с настройками emoji в <head>.
Зайдите в админку и убедитесь, что редактор и форма комментариев работают как обычно.

Если цель — убрать лишние запросы только на фронтенде, можно отключить emoji именно там. Если нужно вычистить их и в админке, делайте это отдельно и аккуратно.

Пошаговое решение через functions.php или mu-plugin

Самый безопасный вариант — добавить код в дочернюю тему или в mu-plugin. Для технических правок mu-plugin удобнее: код не пропадёт после смены темы.

Вариант 1: отключить emoji на фронтенде и в админке

<?php
add_action( 'init', function () {
    remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
    remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
    remove_action( 'wp_print_styles', 'print_emoji_styles' );
    remove_action( 'admin_print_styles', 'print_emoji_styles' );
    remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
    remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
    remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
} );

Этот вариант убирает стандартные подключения WordPress. Он подходит, если вы уверены, что emoji-поддержка не нужна ни в контенте, ни в письмах, ни в админке.

Вариант 2: отключить только на фронтенде

<?php
add_action( 'init', function () {
    remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
    remove_action( 'wp_print_styles', 'print_emoji_styles' );
    remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
    remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
    remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
} );

Такой подход оставляет админку в покое. На практике это часто лучший компромисс: фронтенд чище, а редактор и системные экраны не затрагиваются.

Сравнение подходов

Способ	Плюсы	Минусы	Когда выбирать
Код в `functions.php`	Быстро, без плагинов	Слетит при смене темы	Если правка временная или сайт на дочерней теме
`mu-plugin`	Не зависит от темы, удобно сопровождать	Нужно один раз создать файл	Если это постоянная техническая настройка
Плагин оптимизации	Можно включать через интерфейс	Лишняя зависимость, иногда много лишних функций	Если уже используете такой плагин для других задач

Если на сайте уже стоит плагин для технической чистки, например Clearfy Pro, проверьте, не дублируете ли вы одну и ту же настройку кодом и интерфейсом. Два источника правды для одной функции обычно заканчиваются путаницей при отладке.

Как проверить, что отключение сработало

После внедрения не ограничивайтесь визуальной проверкой страницы. Emoji-скрипт может быть убран частично, а в кэше ещё останется старая версия HTML.

откройте страницу в режиме инкогнито;
посмотрите исходный код и убедитесь, что нет wp-emoji-release.min.js;
проверьте, что в <head> не остался инлайн-блок с wp-emoji-settings;
очистите кэш плагина, серверный кэш и CDN, если он есть;
сравните результат в админке: редактор, комментарии, загрузка медиа должны работать как раньше.

Если используете DevTools, откройте вкладку Network и обновите страницу с отключённым кэшем браузера. Так проще увидеть, исчез ли запрос к файлу emoji.

Частые ошибки и как их исправить

Код вставили не туда

Самая частая ошибка — вставка в файл темы, который потом перезаписывается обновлением. Если правка нужна надолго, используйте дочернюю тему или mu-plugin.

Отключили слишком много

Иногда вместе с emoji убирают лишние фильтры или стили, которые не относятся к задаче. Не нужно трогать функции, если вы не понимаете, за что они отвечают. Для этой задачи достаточно стандартных хуков WordPress.

Кэш показывает старую версию

После правки код может быть уже отключён, но в браузере или на сервере остаётся старая HTML-страница. Очистите все уровни кэша и проверьте страницу в приватном окне.

Сломалась почта или RSS

Если вы убрали фильтры для wp_mail или RSS, а потом увидели странное поведение, верните соответствующие строки. Обычно проблема не в emoji как таковых, а в слишком широком отключении.

Практические советы по безопасности и производительности

Не редактируйте ядро WordPress и не удаляйте файлы из wp-includes. Это ломает обновления и усложняет диагностику. Технические изменения лучше держать в одном месте: либо в mu-plugin, либо в дочерней теме, либо в плагине для оптимизации, если он уже используется в проекте.

Если у вас несколько оптимизационных правок, ведите их списком и фиксируйте, где именно они применены. Это особенно важно, когда сайт обслуживают несколько разработчиков или когда часть настроек уже вынесена в плагин, а часть — в код.

Для сайтов, где важна чистка лишних элементов WordPress, имеет смысл смотреть на комплексные инструменты вроде Clearfy Pro: там можно централизованно управлять частью технических отключений, не размазывая логику по теме и отдельным сниппетам. Но даже в этом случае полезно понимать, какой именно хук вы отключаете и как потом проверить результат.

Если после внедрения у вас остались вопросы, ориентируйтесь не на «стало ли быстрее на глаз», а на конкретный результат: исчез ли запрос, убрался ли инлайн-код, не появилось ли новых ошибок в админке и не сломался ли кэш. Для такой задачи этого достаточно.