Встроенная поддержка emoji в WordPress редко нужна на обычном сайте, но её скрипты и стили всё равно могут загружаться в <head> и в админке. На небольшом проекте это не выглядит критично, но когда вы чистите фронтенд от лишнего кода, отключаете дубли и настраиваете кеш, такие мелочи начинают мешать: лишние HTTP-запросы, лишний JS на каждой странице и лишняя точка конфликта с оптимизаторами.
Задача здесь не в том, чтобы «вырубить всё подряд», а в том, чтобы убрать именно фронтенд-часть emoji там, где она не нужна, и не сломать редактор, комментарии и сторонние интеграции. Ниже — рабочие варианты, как это сделать в теме, в плагине или через готовый инструмент, и как проверить результат.
Когда emoji в WordPress действительно мешают
Проблема обычно всплывает не по одному признаку, а по набору мелких симптомов. На странице в исходном коде видны подключения wp-emoji-release.min.js и inline-скрипт, которые не используются в вашем контенте. После включения кеша или минификации иногда появляются предупреждения в консоли, если оптимизатор пытается объединить или отложить этот скрипт. На некоторых сайтах это ещё и лишний шум в отчётах по производительности.
Что именно стоит проверить перед отключением
- Есть ли на сайте реальное использование emoji в контенте, заголовках, комментариях или пользовательских сообщениях.
- Используется ли плагин оптимизации, который уже умеет убирать emoji-скрипты.
- Есть ли кастомная тема или дочерняя тема, где лучше держать такие правки отдельно от ядра.
- Не завязаны ли на старый браузерный fallback какие-то внутренние формы или виджеты.
Диагностика: где искать подключение emoji
Самый быстрый способ — открыть исходный код страницы и найти упоминания wp-emoji-release.min.js или emoji. Если вы видите подключение в <head>, значит фронтенд-часть активна. В админке это не всегда проблема: редактор и панель могут использовать свои ресурсы, и отключать их без необходимости не стоит.
Если у вас уже стоит плагин кеширования или оптимизации, сначала проверьте его настройки. Некоторые плагины умеют отключать emoji без кода. Это безопаснее, чем дублировать одну и ту же правку в нескольких местах.
| Способ | Плюсы | Минусы |
|---|---|---|
| Настройка в плагине оптимизации | Без кода, проще откатить | Зависит от конкретного плагина |
| Код в дочерней теме или mu-plugin | Контроль, не зависит от интерфейса | Нужно аккуратно обновлять и тестировать |
| Оставить как есть | Ничего не ломаете | Лишние ресурсы на фронтенде |
Пошаговое решение через код
Если вам нужен предсказуемый результат, проще всего убрать emoji-хуки через functions.php дочерней темы или через небольшой mu-plugin. Это не требует правки ядра и нормально переживает обновления WordPress.
Вариант для дочерней темы
<?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' );
} );Этот код отключает не только фронтенд-скрипт, но и часть преобразований emoji в RSS и письмах. Если вам нужно убрать только фронтенд, а остальное оставить, можно ограничиться первыми четырьмя строками. Но на практике чаще нужен именно полный набор, потому что лишние преобразования в фидах и письмах тоже не приносят пользы.
Вариант через mu-plugin
Если вы ведёте несколько правок на проекте и не хотите зависеть от активной темы, положите код в файл wp-content/mu-plugins/disable-emoji.php. Такой файл загружается автоматически и не исчезнет после смены темы.
<?php
/**
* Plugin Name: Disable Emoji
*/
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' );
} );Для большинства сайтов этого достаточно. Если после внедрения вы видите, что emoji-ресурсы всё ещё подключаются, значит их добавляет не ядро WordPress, а тема или плагин оптимизации. Тогда нужно искать источник уже там.
Если проще отключить через плагин
На проектах, где уже используется плагин для чистки сайта и SEO-оптимизации, удобнее держать такие настройки в одном месте. Например, в Clearfy Pro есть набор опций для отключения лишних функций WordPress, и emoji обычно входят в такие сценарии очистки. Это полезно, если вы уже централизуете правки: отключение дублей, лишних скриптов, мета-тегов и технического мусора.
Но здесь важен один момент: не включайте одновременно несколько инструментов, которые делают одно и то же. Если emoji отключены в плагине оптимизации, не дублируйте это кодом в теме. Иначе при отладке будет сложно понять, какой именно слой отвечает за поведение сайта.
Как проверить, что решение сработало
Проверка должна быть не «на глаз», а по конкретным признакам. Откройте главную страницу и несколько внутренних страниц в режиме инкогнито, затем посмотрите исходный код. В нём не должно быть подключения wp-emoji-release.min.js и inline-скрипта emoji в <head>. После этого проверьте консоль браузера и сетевые запросы.
- В исходном коде нет
wp-emoji-release.min.js. - В DevTools на вкладке Network нет запроса к emoji-скрипту.
- Страница открывается без новых ошибок JavaScript.
- Редактор записей и админка работают как раньше.
- RSS и письма, если они у вас используются, не потеряли текстовые символы.
Если вы используете кеш-плагин, после правки обязательно очистите кеш страницы, объектный кеш и CDN, если он подключён. Иначе вы можете смотреть на старую версию HTML и сделать ложный вывод, что код не сработал.
Частые ошибки и как их исправить
Отключили только часть хуков
Иногда убирают только print_emoji_detection_script, но оставляют стили или фильтры для фидов. В результате фронтенд выглядит чище, но часть лишней логики остаётся. Если цель — полная очистка, лучше использовать весь набор хуков, а не точечную правку.
Сломали совместимость с плагином оптимизации
Если кеш-плагин уже умеет отключать emoji, а вы добавили второй слой через код, это обычно не критично, но усложняет поддержку. При обновлении плагина или темы можно получить дублирующиеся правки и путаницу в отладке. Выберите один источник правды: либо плагин, либо код.
Правили не в дочерней теме
Если вы внесли изменения прямо в родительскую тему, они исчезнут после обновления. Для технических правок это плохая практика. Используйте дочернюю тему или mu-plugin, если хотите, чтобы отключение emoji переживало обновления.
Проверяли только главную страницу
На главной всё может выглядеть нормально, а на странице записи, в архиве или в шаблоне с другим набором скриптов emoji всё ещё будут подключаться. Проверяйте несколько типов страниц, особенно если на сайте есть разные шаблоны и плагины для контента.
Что ещё стоит сделать рядом с этой правкой
Если вы уже чистите фронтенд, имеет смысл посмотреть и на другие мелкие источники мусора: лишние эмодзи в RSS, неиспользуемые embed-скрипты, дубли мета-тегов и устаревшие подключения из темы. Но не превращайте это в бесконечную зачистку. Любую правку лучше вносить по одному сценарию и сразу проверять результат.
Для проектов, где важна системная техническая чистка, удобнее держать такие настройки в одном инструменте, а не размазывать их по нескольким файлам. Тогда проще понять, что именно отключено, и быстрее откатывать изменения, если какой-то плагин или интеграция начнёт вести себя нестабильно.
