Как отключить emoji в WordPress в админке и на сайте без лишнего кода

Если на сайте WordPress не используются встроенные emoji, их можно убрать без риска для контента. На практике это решает две задачи: сокращает лишние запросы в <head> и убирает небольшой, но постоянный технический шум в фронтенде и админке. Важно делать это аккуратно: не просто вырезать случайный скрипт, а отключить штатные подключения WordPress через правильные хуки.

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

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

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

Диагностика: что именно подключает WordPress

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

Если у вас есть доступ к инструментам разработчика, проверьте вкладку Network: лишний файл будет виден как отдельный запрос. На небольшом сайте это не критично, но если вы последовательно вычищаете технический мусор, такие детали лучше убирать системно.

Что проверить до изменений

• Использует ли сайт кастомный редакторский плагин, который может рассчитывать на стандартные скрипты WordPress.
• Есть ли в теме собственные правки functions.php, которые уже отключают emoji.
• Не подключает ли оптимизатор скриптов похожую оптимизацию автоматически.

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

Самый надежный способ — добавить код в дочернюю тему или в небольшой mu-plugin. Так вы не потеряете правку при обновлении темы. Для отключения emoji WordPress достаточно снять штатные действия с нужных хуков.

<?php
// Отключаем emoji на фронтенде и в админке.
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' );

// Дополнительно убираем фильтры, которые WordPress использует для преобразования emoji.
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' );
remove_filter( 'the_content', 'wp_staticize_emoji' );
remove_filter( 'comment_text', 'wp_staticize_emoji' );

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

Вариант для мини-плагина

Такой подход удобен, если вы ведете несколько сайтов и хотите одинаковое поведение без привязки к теме.

<?php
/**
 * Plugin Name: Disable Emoji Support
 */

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' );
    remove_filter( 'the_content', 'wp_staticize_emoji' );
    remove_filter( 'comment_text', 'wp_staticize_emoji' );
} );

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

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

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

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

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

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

Мини-чек-лист проверки

• В исходном коде страницы нет wp-emoji-release.min.js.
• В <head> отсутствуют emoji-стили WordPress.
• Админка открывается без ошибок JavaScript.
• Редактор записей работает, комментарии сохраняются, письма уходят как обычно.

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

Код добавили, но emoji-скрипт остался

Чаще всего это значит, что код вставили слишком поздно или не в тот файл. Если вы добавили его в шаблон, который не загружается на всех страницах, эффект будет неполным. Перенесите код в functions.php дочерней темы или в mu-plugin.

Отключили emoji, а в админке появились предупреждения

Такое бывает, если вместе с emoji вы случайно удалили не те хуки или использовали сторонний сниппет с ошибкой. Проверьте, что вы убираете только стандартные функции WordPress: print_emoji_detection_script, print_emoji_styles и фильтры wp_staticize_emoji.

Оптимизатор уже делает это сам

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

Что учесть для безопасности и производительности

Сама по себе эта оптимизация не дает драматического ускорения, но она полезна как часть системной чистки сайта. Чем меньше лишних подключений в head, тем проще поддерживать предсказуемый фронтенд и отлаживать реальные проблемы. Главное — не превращать техническую чистку в набор случайных сниппетов без учета зависимостей темы и плагинов.

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