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

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

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

Когда проблема действительно в автоподмене CyrtoLat

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

Типичные признаки

• в комментариях меняются отдельные слова, хотя в записи они отображаются нормально;
• в Contact Form 7, WPForms, Fluent Forms или похожих формах подменяются значения в полях;
• в письмах-уведомлениях появляются латинизированные фрагменты вместо исходного текста;
• в админке комментарий сохранен корректно, но на сайте выводится уже измененный вариант;
• автоподмена затрагивает служебные поля, например имя, тему сообщения или подпись.

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

Что отключать: комментарии, формы или весь текстовый слой

У CyrtoLat обычно полезно разделять три уровня: контент записей, пользовательский ввод и служебные сообщения. Для этой статьи важен второй и третий уровни. Комментарии и формы — это не редакционный контент, а пользовательские данные. Их лучше не пропускать через автоподмену без необходимости.

Пошаговое решение: как убрать автоподмену в комментариях и формах

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

Шаг 1. Найдите, где именно срабатывает подмена

Откройте проблемную страницу, отправьте тестовый комментарий или форму с заведомо «опасным» словом, которое CyrtoLat обычно меняет. Проверьте три места:

• что сохранилось в базе или в админке;
• что показывается на фронтенде;
• что пришло в письме уведомления.

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

Шаг 2. Исключите комментарии из автоподмены через код темы или мини-плагин

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

<?php
/**
 * Plugin Name: CyrtoLat comments exclusion
 */

add_filter( 'comment_text', function( $comment_text ) {
    remove_filter( 'comment_text', 'cyrtolat_filter_text', 10 );
    return $comment_text;
}, 1 );

Имя функции cyrtolat_filter_text приведено как пример только если именно так она объявлена в вашей версии плагина. Перед внедрением проверьте реальное имя callback в коде CyrtoLat или в документации плагина. Если callback другой, подставьте фактический.

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

Шаг 3. Отключите автоподмену в формах на уровне конкретного плагина

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

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

<?php
add_filter( 'wp_mail', function( $args ) {
    if ( empty( $args['message'] ) ) {
        return $args;
    }

    // Убираем автоподмену только из письма формы.
    if ( function_exists( 'cyrtolat_disable_autoplace_in_text' ) ) {
        $args['message'] = cyrtolat_disable_autoplace_in_text( $args['message'] );
    }

    return $args;
} );

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

Шаг 4. Проверьте шаблоны писем и автозамену в уведомлениях

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

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

Как проверить результат после внедрения

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

1. Отправьте тестовый комментарий с кириллическим словом, которое раньше подменялось.
2. Отправьте тестовую форму с тем же словом в поле имени, теме и сообщении.
3. Проверьте вывод на фронтенде, запись в админке и письмо-уведомление.
4. Откройте страницу в режиме инкогнито, чтобы исключить влияние кэша браузера.
5. Если на сайте есть серверный кэш, сбросьте его и повторите тест.

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

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

Отключили не тот слой

Самая частая ошибка — убрать фильтр вывода, но оставить обработку входящих данных. В итоге в админке комментарий выглядит нормально, а в письме или на фронтенде проблема остается. Проверяйте оба направления: сохранение и отображение.

Сломали обработку всех текстов на сайте

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

Не учли плагин формы

Contact Form 7, WPForms, Fluent Forms и другие решения формируют письмо по-разному. Один и тот же код может сработать в одном плагине и не дать эффекта в другом. Если форма продолжает менять текст, ищите фильтры именно этого плагина, а не только WordPress в целом.

Тестировали без очистки кэша

Если на сайте есть page cache, object cache или кэш на стороне CDN, вы можете видеть старый результат. Это особенно заметно, когда комментарии выводятся через AJAX или когда письмо формируется отдельно от страницы.

Что делать, если нужен более тонкий контроль

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

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

Мини-чек-лист перед публикацией

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

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