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

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

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

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

Отключение автоподмены в тексте для отдельных ролей полезно не во всех проектах, а в конкретных рабочих ситуациях:

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

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

Диагностика: что именно ломается

Сначала важно понять, где срабатывает автоподмена: в публичной части, в редакторе, в предпросмотре или в админке. Для этого откройте один и тот же материал под разными ролями и сравните результат. Если под администратором текст уже изменён, а под подписчиком или гостем выглядит иначе, значит фильтр применяется слишком рано или без учёта роли.

Что проверить перед изменением настроек

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

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

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

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

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

Вариант 1: настройка через интерфейс плагина

Если в админке CyrtoLat есть опция отключения автоподмены для ролей, задайте её для administrator и editor. Это предпочтительно, потому что:

• не требует ручного кода;
• легче поддерживается после обновлений;
• меньше риск сломать сайт из-за ошибки в PHP;
• проще объяснить редакции, почему поведение отличается по ролям.

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

Вариант 2: точечное отключение через код

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

<?php
/**
 * Plugin Name: CyrtoLat role-based text exclusion
 */

add_filter( 'cyrtolat_should_replace_text', function( $should_replace ) {
    if ( ! is_user_logged_in() ) {
        return $should_replace;
    }

    $user = wp_get_current_user();
    if ( array_intersect( array( 'administrator', 'editor' ), (array) $user->roles ) ) {
        return false;
    }

    return $should_replace;
} );

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

Если вы не хотите трогать тему, создайте отдельный файл в wp-content/mu-plugins/. Так код не потеряется при смене темы и не зависит от child theme.

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

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

Если на сайте несколько редакторов с разными правами, не завязывайтесь на имя пользователя. Проверка по роли надёжнее и проще в сопровождении.

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

Проверка должна быть не визуальной «на глаз», а повторяемой. Возьмите запись с текстом, где автоподмена заметна, и откройте её в трёх режимах:

• под администратором;
• под редактором;
• под обычным пользователем или в гостевом режиме.

Дальше сравните:

• исходный фрагмент в редакторе;
• предпросмотр записи;
• публичную страницу после очистки кэша.

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

Сравнение подходов

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

Проверяют не ту роль

Иногда у пользователя есть несколько ролей или кастомная роль, которая наследует поведение редактора. В этом случае проверка только на editor не сработает. Решение — посмотреть реальные роли пользователя через wp_get_current_user() и добавить нужные значения в массив.

Вносят код в functions.php активной темы

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

Не очищают кэш

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

Отключают автоподмену слишком широко

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

Практика безопасности и поддержки

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

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

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

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