Как в CyrtoLat отключить автоподмену в REST API и внешних вызовах без поломки интеграций

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

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

Когда автоподмена мешает REST API и интеграциям

Типичный симптом — данные в браузере и данные в API отличаются. Например, запись в редакторе называется одним образом, а в ответе /wp-json/wp/v2/posts или в webhook-пейлоаде часть текста уже изменена. Для человека это может быть незаметно, а для интеграции — критично: внешний сервис сравнивает строки, ищет точное совпадение или строит URL по slug.

Чаще всего проблема всплывает в таких сценариях:

• мобильное приложение получает не тот текст, который ожидает;
• CRM или ERP не находит запись по slug после автоподмены;
• вебхук уходит с уже изменёнными полями и ломает синхронизацию;
• служебные запросы в REST API начинают возвращать «очищенные» значения, хотя для обмена нужны исходные.

Как понять, что виновата именно автоподмена CyrtoLat

Сначала сравните один и тот же объект в админке и через REST API. Если в базе и в интерфейсе значение одно, а в ответе API — другое, значит вмешивается фильтрация на уровне вывода. Это особенно заметно на полях, где есть кириллица, смешанные символы или слова, которые CyrtoLat обычно подменяет по своим правилам.

Полезная проверка — открыть конкретную запись через REST API и сравнить её с тем, что возвращает обычный шаблон сайта. Если различие появляется только в JSON, а не в базе, значит отключать нужно не контент целиком, а именно автоподмену для служебных запросов.

Что лучше отключать: весь сайт или только REST API

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

Пошагово: как отключить автоподмену для REST API

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

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

<?php
add_action('init', function () {
    if (defined('REST_REQUEST') && REST_REQUEST) {
        // Здесь не включаем дополнительную обработку текста,
        // если она у вас добавлена через тему или кастомный код.
        return;
    }

    // Обычная логика сайта продолжает работать.
});

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

Если нужно исключить только один endpoint

Иногда ломается не весь REST API, а один маршрут, например кастомный endpoint для синхронизации каталога или выгрузки материалов. Тогда лучше проверять $_SERVER['REQUEST_URI'] или текущий REST route и отключать обработку только для него. Это точнее, чем рубить весь API целиком.

<?php
add_action('init', function () {
    if (defined('REST_REQUEST') && REST_REQUEST) {
        $uri = isset($_SERVER['REQUEST_URI']) ? wp_unslash($_SERVER['REQUEST_URI']) : '';

        if (strpos($uri, '/wp-json/myplugin/v1/sync') !== false) {
            return;
        }
    }

    // Остальная логика обработки.
});

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

Диагностика: где именно меняются данные

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

• Проверьте исходное значение в базе через редактор или wp post get, если используете WP-CLI.
• Сравните ответ REST API с тем, что хранится в записи.
• Отключите на время сторонние фильтры вывода, если они есть.
• Посмотрите, не влияет ли кэш API-ответов: иногда кажется, что виноват CyrtoLat, а на деле отдаётся старый JSON.

Если значение меняется только в ответе API, а в базе остаётся прежним, значит проблема на уровне вывода. Если же меняется уже при сохранении, нужно искать не REST API, а обработчики, которые срабатывают на save_post, wp_insert_post_data или похожих хуках.

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

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

1. Откройте проблемный endpoint через браузер или curl.
2. Сравните значение поля до и после изменения настройки.
3. Проверьте один и тот же объект через интерфейс WordPress и через REST API.
4. Если используется webhook, отправьте тестовое событие и посмотрите payload на стороне принимающего сервиса.

curl -s https://example.com/wp-json/wp/v2/posts/123 | jq '.title.rendered, .slug'

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

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

Отключили не там, где нужно

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

Проверили только в админке

Админка не показывает, как данные уходят наружу. Если интеграция работает через JSON, тестировать нужно именно JSON. Иначе можно долго искать проблему в другом месте.

Не учли кэш

Если на сайте есть page cache, object cache или отдельный кэш для REST API, вы можете видеть старый ответ даже после правильной настройки. После изменений очистите кэш и повторите запрос напрямую, без промежуточных слоёв.

Смешали логику темы и плагина

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

Безопасность и производительность

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

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

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

Короткий чек-лист перед выкладкой

• Поняли, какой именно endpoint или webhook ломается.
• Сравнили данные в базе и в REST API.
• Отключили автоподмену только для служебного запроса, а не для всего сайта.
• Очистили кэш после правок.
• Проверили ответ API и тестовую интеграцию повторно.

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