Как в CyrtoLat отключить автоподмену в админке и редакторе для отдельных пользователей

На практике проблема выглядит так: редактору удобно работать с кириллицей в админке, но плагин CyrtoLat уже успел заменить часть слов в интерфейсе, заголовках, черновиках или в пользовательских полях. В итоге в редакторе появляются латинские варианты там, где они не нужны, а у контент-менеджеров начинается путаница: что уже сохранено, что еще нет, и почему один и тот же термин в разных местах ведет себя по-разному.

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

Когда это действительно нужно

Сценарий не абстрактный. Обычно он всплывает после нескольких недель работы сайта, когда выясняется, что автоподмена полезна для публикации, но мешает внутри wp-admin. Типичные случаи:

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

Диагностика проблемы: где именно срабатывает автоподмена

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

Что проверить сначала

• Откройте запись в классическом редакторе и в Gutenberg, если используете оба варианта.
• Проверьте, меняется ли текст в заголовке, содержимом и произвольных полях.
• Сравните поведение для администратора и для редактора с меньшими правами.
• Посмотрите, не срабатывает ли автоподмена только после сохранения, а не в момент ввода.

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

Как отключить автоподмену в админке для отдельных ролей

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

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

<?php
add_filter( 'cyrtolat_should_replace_text', function( $should_replace, $text, $context ) {
    if ( is_admin() ) {
        $user = wp_get_current_user();

        // Оставляем автоподмену только администраторам.
        if ( ! in_array( 'administrator', (array) $user->roles, true ) ) {
            return false;
        }
    }

    return $should_replace;
}, 10, 3 );

Если в вашей установке нет фильтра с таким названием, не подставляйте его наугад. Сначала найдите реальные точки расширения CyrtoLat: это может быть фильтр перед заменой текста, перед генерацией slug или перед обработкой контента. Суть решения остается той же — проверка роли и возврат false для исключенных пользователей.

Как отключить автоподмену только для конкретного пользователя

Иногда роль слишком грубая настройка. Например, у вас есть один SEO-редактор, которому нужна кириллица в админке, а остальным — нет. Тогда удобнее привязаться к ID пользователя или логину.

<?php
add_filter( 'cyrtolat_should_replace_text', function( $should_replace, $text, $context ) {
    if ( is_admin() ) {
        $current_user = wp_get_current_user();
        $excluded_users = array( 12, 27 ); // ID пользователей, для которых подмена выключена.

        if ( in_array( (int) $current_user->ID, $excluded_users, true ) ) {
            return false;
        }
    }

    return $should_replace;
}, 10, 3 );

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

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

Пошаговое решение без лишнего риска

1. Определите, где именно мешает автоподмена: в редакторе, в метаполях, в списке записей или в AJAX-окнах.
2. Проверьте, есть ли в CyrtoLat готовые исключения по ролям или зоне применения.
3. Если готовой настройки нет, добавьте фильтр в дочернюю тему или mu-plugin, а не в основной файл темы.
4. Сначала ограничьте отключение для одной тестовой роли или одного пользователя.
5. Проверьте поведение в Gutenberg и классическом редакторе.
6. После проверки расширьте правило на нужную группу пользователей.

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

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

• Создайте тестовую запись с кириллическим заголовком.
• Вставьте слово, которое CyrtoLat обычно подменяет.
• Сохраните черновик и откройте его повторно.
• Проверьте, что в админке текст остался без нежелательной замены.
• Откройте запись на фронтенде и убедитесь, что публичная часть сайта ведет себя так, как задумано.

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

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

Отключили автоподмену глобально вместо точечного исключения

Это самая частая ошибка. В результате ломается логика slug, старые правила перестают работать, а фронтенд начинает вести себя не так, как ожидалось. Если нужен только редакторский сценарий, ограничивайте обработку через роль, пользователя или is_admin(), а не выключайте весь механизм.

Вставили код в родительскую тему

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

Не проверили, как работает Gutenberg

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

Использовали несуществующий хук

Не стоит копировать пример кода без проверки названия фильтра в вашей версии CyrtoLat. Сначала найдите реальный хук в документации или исходниках плагина. Иначе код просто не выполнится, а проблема останется незаметной до следующего редактирования.

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

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

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

Если на сайте уже используется Clearfy Pro для технической чистки и удаления дублей, его можно рассматривать как соседний инструмент для общей гигиены сайта, но не как замену точечной логике CyrtoLat. У них разные задачи: один помогает с оптимизацией и дублями, другой — с автоподменой и сценариями работы с кириллицей.

Когда нужно быстро проверить результат на боевом сайте, не меняйте сразу всех пользователей. Сначала протестируйте на одном аккаунте с минимальными правами. Это снижает риск случайно сломать редакционный процесс у всей команды.

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