Как отключить emojis в WordPress без поломки редактора и темы

В WordPress emoji-скрипты обычно не мешают визуально, но на небольших и средних сайтах они часто оказываются лишними: отдельный запрос в head, дополнительные фильтры, ненужная нагрузка на фронтенде и в админке. Проблема в том, что многие советы сводятся к «удалите всё подряд из functions.php», а это уже риск сломать редактор, если тема или плагины завязаны на стандартные скрипты ядра.

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

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

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

Есть и обратная сторона: если у вас старый кастомный шаблон, нестандартный редакторский стек или плагины, которые вмешиваются в wp_head и admin_print_scripts, лучше сначала проверить, как именно они используют стандартные хуки WordPress. Полное «вырубание» без диагностики — плохая идея.

Что именно отключается

WordPress добавляет emoji-скрипты и стили через набор стандартных хуков. На практике это означает:

• убирается лишний JavaScript на фронтенде и в админке;
• не выводится inline-логика для проверки поддержки emoji;
• не грузится отдельный набор служебных стилей, если они были подключены ядром;
• контент, где уже используются emoji, продолжит отображаться нормально в современных браузерах и редакторах.

Диагностика: что проверить до изменений

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

1. Не использует ли тема собственные обёртки вокруг wp_head() и wp_footer().
2. Нет ли в плагинах кастомной оптимизации, которая уже отключает часть ядра и может конфликтовать с вашим кодом.

Если на сайте включён кэш, после изменений обязательно очищайте не только страницу, но и объектный кэш, если он есть. Иначе вы будете смотреть на старую версию HTML и решите, что код не сработал.

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

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

Вариант 1: мини-плагин

Создайте файл wp-content/mu-plugins/disable-emojis.php. Если папки mu-plugins нет, создайте её вручную.

<?php
/**
 * Plugin Name: Disable Emojis
 * Description: Отключает emoji-скрипты WordPress на фронтенде и в админке.
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

function wpskins_disable_emojis() {
    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_action( 'init', 'wpskins_disable_emojis' );

Этот вариант хорош тем, что не зависит от темы и не требует отдельной активации в админке. Для технических сайтов это обычно удобнее, чем держать такой код в functions.php.

Вариант 2: через дочернюю тему

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

<?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' );
} );

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

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

Если хотите проверить через браузерные инструменты, откройте вкладку Network и обновите страницу. В списке запросов не должно быть отдельного emoji-скрипта WordPress. Это самый быстрый способ понять, что код реально сработал, а не просто лежит в файле.

Проверка на уровне HTML

Можно сделать и более приземлённую проверку через поиск по исходнику:

• нет wp-emoji-release.min.js;
• нет inline-функции проверки emoji в head;
• нет подключённых emoji-стилей от ядра;
• в RSS и письмах не появляется статическая подмена emoji-кодов.

Сравнение подходов: плагин, код, оптимизатор

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

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

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

Самая распространённая ошибка — удалять не только emoji-хуки, но и соседние функции, не понимая, что они делают. Вторая ошибка — добавлять код в родительскую тему: после обновления всё возвращается назад, и кажется, будто WordPress «сам включил emojis обратно».

• Ошибка: код вставлен в файл, который не загружается на всех страницах.
  Что делать: используйте mu-plugin или дочернюю тему.
• Ошибка: после правки на сайте остался старый HTML из кэша.
  Что делать: очистите page cache, object cache и CDN, если он есть.
• Ошибка: сломался внешний вид админки.
  Что делать: проверьте, не удалили ли вы лишние действия из admin_print_scripts и admin_print_styles.
• Ошибка: скрипт всё ещё виден в исходнике.
  Что делать: убедитесь, что код выполняется после загрузки ядра, например на init.

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

Если вы работаете на боевом сайте, не редактируйте файлы через встроенный редактор WordPress. Для таких правок безопаснее использовать SFTP, Git или хотя бы staging-копию. Это особенно важно, если у вас уже есть кастомные хуки в теме и вы не хотите поймать синтаксическую ошибку на проде.

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

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

Что проверить после внедрения на реальном сайте

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

• страница загружается без ошибок в консоли;
• в исходнике нет emoji-скрипта;
• редактор записей открывается нормально;
• комментарии и RSS не изменили поведение;
• кэш не отдаёт старую версию страницы.

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