Как отключить эмодзи в WordPress без поломки редактора и фронтенда

В WordPress поддержка эмодзи включена по умолчанию уже много лет. На небольшом сайте это не критично, но на проектах с жесткими требованиями к чистоте фронтенда и количеству лишних запросов этот функционал часто просто не нужен. Проблема в том, что отключать его надо аккуратно: не только убрать подключение скрипта на сайте, но и не задеть редактор, REST API и поведение в админке.

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

Когда отключение эмодзи действительно имеет смысл

Обычно это нужно в трех сценариях: вы оптимизируете фронтенд и хотите убрать лишний JavaScript; у вас строгая политика по внешним запросам и вы не хотите, чтобы WordPress подгружал emoji-ресурсы; вы поддерживаете старый проект, где функциональность эмодзи не используется вообще, а код все равно остается активным.

Важно понимать: речь не о визуальном запрете смайлов в контенте. WordPress все равно сохранит символы Unicode, если браузер их поддерживает. Мы отключаем именно служебную проверку и подмену, которую ядро добавляет для старых браузеров.

Диагностика: что именно грузится и где

Перед изменениями проверьте, что у вас реально подключается. На фронтенде откройте исходный код страницы и найдите wp-emoji-release.min.js. Если он есть, значит ядро добавляет emoji-скрипт. В DevTools можно также посмотреть список запросов и убедиться, что загружается файл из /wp-includes/js/wp-emoji-release.min.js.

Если вы используете кэш-плагин или CDN, сначала очистите кэш и проверьте страницу в режиме инкогнито. Иначе можно ошибочно решить, что отключение не сработало, хотя вы видите старую версию HTML.

Что проверить до правки

• Есть ли скрипт wp-emoji-release.min.js в исходнике страницы.
• Не завязан ли на emoji какой-то кастомный фронтенд-код в теме.
• Есть ли отдельные оптимизаторы, которые уже удаляют этот скрипт.
• Используется ли кэш страницы, который надо сбросить после изменений.

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

Самый безопасный вариант — добавить небольшой код в functions.php дочерней темы или в mu-plugin. Для постоянного проекта mu-plugin удобнее: он не зависит от смены темы и проще контролируется.

Ниже код, который убирает 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. Он не трогает контент, уже сохраненный в базе, и не ломает обычный текст с Unicode-символами.

Если нужен вариант для mu-plugin

Создайте файл, например wp-content/mu-plugins/disable-emojis.php, и поместите туда тот же код. Для mu-plugin не нужен отдельный запуск через админку: WordPress подхватит его автоматически.

<?php
/**
 * Plugin Name: Disable Emojis
 */
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' );
} );

Альтернативы: плагин или код

Если у вас уже стоит оптимизатор, проверьте, не делает ли он это сам. Иногда проще включить одну галочку в существующем плагине, чем хранить еще один кусок кода. Но если вам нужна предсказуемость и минимум зависимостей, код в mu-plugin обычно надежнее.

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

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

После внедрения откройте главную страницу и любую внутреннюю страницу в режиме инкогнито. В исходном коде не должно быть wp-emoji-release.min.js и связанных emoji-стилей. Затем проверьте админку: редактор записей должен открываться без ошибок JavaScript, а в консоли браузера не должно появиться новых предупреждений после сохранения записи.

Дополнительно проверьте RSS-ленты и письма, если на сайте они используются. В них не должно быть странных замен символов или поломки текста. Это особенно важно для сайтов, где контент автоматически уходит в рассылку или внешние сервисы.

Быстрый чек-лист проверки

• Очистить кэш страницы и CDN.
• Открыть страницу в инкогнито.
• Проверить исходник на wp-emoji-release.min.js.
• Открыть редактор записей и сохранить тестовый пост.
• Проверить RSS, если он используется.

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

Ошибка 1: код добавили в тему, а потом сменили шаблон. В этом случае отключение пропадает. Если сайт живет долго и темы меняются, переносите код в mu-plugin.

Ошибка 2: проверяют только админку. Emoji-скрипт может быть убран в одной зоне и остаться на фронтенде из-за кэша или другого плагина. Проверяйте и публичную часть сайта, и исходный код.

Ошибка 3: не очистили кэш. После правки WordPress и CDN могут отдавать старую версию HTML. Сначала сбросьте кэш, потом делайте выводы.

Ошибка 4: отключили не тот функционал. Иногда пытаются удалить вообще все, что связано с Unicode или редактором, и получают побочные эффекты. Нужны только стандартные emoji-action и emoji-filter, а не агрессивная чистка всего подряд.

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

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

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

Для проектов с регламентом изменений лучше хранить этот фрагмент в репозитории рядом с другими правками темы или mu-plugin. Тогда при аудите сразу видно, что именно отключено и зачем.