В WordPress emoji поддерживаются не только на уровне контента, но и через отдельные скрипты и фильтры, которые подгружаются на фронтенде и в админке. На небольших сайтах это часто лишняя нагрузка: дополнительные запросы, лишний JavaScript и еще один источник конфликтов при агрессивной оптимизации. Если задача — убрать именно штатную emoji-поддержку WordPress, а не «сломать» редактор или комментарии, делать это нужно точечно.
Ниже — рабочая схема: сначала быстро диагностируем, откуда именно идет подключение, затем отключаем его безопасным способом, а после проверяем результат в браузере и по исходному HTML.
Когда отключение emoji действительно имеет смысл
Отключать emoji стоит не «ради чистоты», а когда есть конкретная причина. Например, вы уже используете собственный набор иконок/эмодзи, сайт работает на минималистичной теме, а фронтенд оптимизируется под строгий бюджет по запросам. В таких случаях штатный emoji-скрипт WordPress чаще всего не нужен.
Если же сайт активно использует комментарии, визуальный редактор, блоки с пользовательским контентом или вы не уверены, что именно отключаете, лучше сначала проверить, не завязаны ли на emoji сторонние плагины или кастомные стили.
Диагностика: где WordPress подключает emoji
По умолчанию WordPress добавляет emoji-скрипт через wp_head, admin_print_scripts, wp_print_styles и несколько связанных фильтров. Это удобно для совместимости, но именно поэтому простое удаление одного скрипта не всегда дает полный эффект.
Как быстро убедиться, что emoji реально грузятся
Откройте исходный код страницы и найдите подключение wp-emoji-release.min.js. Если оно есть, значит штатная поддержка emoji активна на фронтенде. В админке проверьте консоль браузера и список загружаемых скриптов на страницах редактора: иногда emoji-поддержка остается только там, и это нормально.
Еще один практичный способ — временно открыть страницу с отключенным кэшем браузера и посмотреть, есть ли в HTML такие фрагменты:
<script src="https://s.w.org/images/core/emoji/15.0.3/wp-emoji-release.min.js" defer></script>Если вы видите подобный URL, значит отключение еще не сработало или его переопределяет плагин/тема.
Пошаговое решение: отключаем emoji через functions.php или мини-плагин
Самый безопасный путь — добавить код в дочернюю тему или в небольшой mu-plugin. Так вы не потеряете правки при обновлении темы и сможете быстро откатить изменения.
Ниже рабочий вариант, который убирает штатные emoji-скрипты и стили из фронтенда и админки, а также отключает преобразование 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');
add_filter('emoji_svg_url', '__return_false');
});Если у вас есть доступ к mu-plugins, это даже удобнее: код будет загружаться всегда и не зависит от активной темы. Для небольших правок такой вариант часто надежнее, чем править functions.php.
Если нужно отключить emoji только на фронтенде
Иногда в админке emoji лучше оставить, чтобы не рисковать совместимостью редактора и почтовых уведомлений. Тогда убирайте только фронтенд-часть:
<?php
add_action('wp_enqueue_scripts', function () {
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');
});Этот вариант полезен, если цель — уменьшить лишние запросы на публичной части сайта, но не трогать внутренние экраны WordPress.
Сравнение подходов: плагин, код, оптимизация через кэш
| Подход | Что дает | Минус | Когда выбирать |
|---|---|---|---|
| Код в теме или mu-plugin | Точный контроль, без лишних зависимостей | Нужно аккуратно поддерживать | Если есть доступ к коду и нужен предсказуемый результат |
| Плагин оптимизации | Можно отключить emoji вместе с другими мелкими оптимизациями | Лишняя прослойка и риск конфликтов настроек | Если уже используете плагин для чистки фронтенда |
| Только кэш/минификация | Может скрыть эффект за счет сборки ресурсов | Не убирает сам источник подключения | Если задача не в отключении emoji, а в общей оптимизации |
Если на сайте уже стоит плагин для технической чистки, например Clearfy Pro, проверьте, не отключена ли emoji-поддержка там. Дублировать одно и то же действие в плагине и в коде не нужно: потом сложнее понять, что именно сломало отображение.
Проверка результата после внедрения
После правки не ограничивайтесь визуальным просмотром главной страницы. Проверьте три вещи: исходный HTML, загрузку скриптов и поведение редактора.
- Откройте исходный код страницы и убедитесь, что
wp-emoji-release.min.jsбольше не присутствует. - Проверьте вкладку Network в DevTools: запрос к emoji-скрипту должен исчезнуть.
- Зайдите в админку, откройте запись в редакторе и убедитесь, что нет ошибок JavaScript.
- Посмотрите письма, если сайт отправляет уведомления через WordPress: эмодзи в тексте не должны ломать форматирование.
Если у вас включен серверный или плагинный кэш, очистите его после правки. Иначе можно увидеть старую версию страницы и решить, что код не сработал.
Частые ошибки и как их исправить
Удалили только один хук и оставили половину логики
Самая частая ошибка — убрать только print_emoji_detection_script, но оставить стили или фильтры для RSS и почты. В результате на фронтенде все выглядит нормально, а в письмах или фидах emoji продолжают преобразовываться. Если отключаете поддержку полностью, убирайте весь набор хуков.
Добавили код слишком поздно
Если вы пытаетесь снять действия на слишком позднем этапе, часть скриптов уже могла быть зарегистрирована или выведена. Для надежности используйте init или ранний хук, а не произвольный участок шаблона.
Конфликт с плагином оптимизации
Некоторые плагины сами отключают emoji или, наоборот, заново подключают нужные им скрипты. Если после внедрения код не дает эффекта, временно отключите оптимизатор и проверьте сайт на чистом ядре WordPress. Так быстрее понять, кто именно переопределяет поведение.
Правка в родительской теме
Если код добавлен в родительскую тему, он исчезнет после обновления. Для такой задачи это особенно неприятно: кажется, что все работает, а через неделю сайт снова грузит лишний скрипт. Используйте дочернюю тему или mu-plugin.
Практические советы по безопасности и производительности
Отключение emoji — мелкая оптимизация, но она должна быть частью общей дисциплины. Не смешивайте отключение штатных функций WordPress с агрессивной «чисткой» без проверки. Если сайт уже использует кэш, минификацию и объединение файлов, меняйте по одному параметру и фиксируйте результат.
Для продакшена полезно держать такие правки в отдельном маленьком плагине или mu-plugin с понятным названием. Тогда вы не забудете, почему emoji отключены, и не потеряете настройку при смене темы. Если нужно управлять несколькими подобными отключениями — например, убрать emoji, embeds и лишние мета-теги — удобнее собрать это в одном техническом слое, чем размазывать по шаблонам.
Если вы не хотите писать код вручную, а задача шире, чем просто emoji, можно посмотреть в сторону инструментов для технической чистки WordPress. Но даже в этом случае проверка через исходный код и DevTools остается обязательной: только она покажет, что именно изменилось на странице.