На практике проблема обычно выглядит так: плагин CyrtoLat отлично переводит кириллические названия в латинские slug, но на части контента это уже лишнее. Например, у вас есть разделы, где URL должны оставаться стабильными из-за внешних ссылок, старой индексации или ручной структуры, а автоподмена продолжает вмешиваться при создании новых записей или терминов.
В этой статье разберём точечный сценарий: как отключить автоподмену не на всём сайте, а только для отдельных типов записей и таксономий. Это полезно, если вы уже читали про отключение автоподмены в разделах сайта, но теперь нужна более узкая настройка на уровне конкретных сущностей.
Когда это действительно нужно
Не стоит выключать автоподмену «на всякий случай». Она полезна там, где slug должны быть читаемыми и предсказуемыми. Но есть ситуации, в которых автоматическая замена начинает мешать:
- у вас есть кастомный post type с уже заданной схемой URL;
- часть таксономий используется только для внутренней навигации и не должна менять slug;
- в старом разделе уже есть проиндексированные латинские URL, а новые записи внезапно получают другую логику генерации;
- контент импортируется из внешней системы, где slug передаются заранее и должны сохраниться без изменений;
- в админке редакторы создают термины вручную, и автоподмена мешает сохранить корпоративные обозначения, аббревиатуры или транслитерацию по внутреннему стандарту.
Диагностика: где именно CyrtoLat вмешивается
Перед настройкой важно понять, на каком уровне возникает проблема. В WordPress slug могут формироваться для записей, страниц, вложений, кастомных типов записей и терминов таксономий. Если отключить автоподмену слишком широко, можно получить обратный эффект: часть сайта перестанет генерировать ожидаемые URL.
Проверьте, что именно меняется
Откройте несколько объектов в админке и сравните исходное название с итоговым slug. Если проблема только в одном post type, не трогайте общую логику. Если ломаются термины конкретной таксономии, настраивать нужно именно её.
Полезно зафиксировать перед изменениями:
- какой объект создаёт проблему: запись, термин или пользовательский тип;
- какой slug был до изменения;
- есть ли уже опубликованные URL и внешние ссылки на них;
- используется ли этот slug в хлебных крошках, фильтрах, sitemap или внутренних ссылках.
Пошаговое решение в CyrtoLat
В CyrtoLat логика отключения обычно сводится к тому, чтобы исключить нужные сущности из автоподмены. Если в интерфейсе плагина есть список исключений по типам записей или таксономиям, используйте его в первую очередь: это безопаснее, чем править код темы или лезть в фильтры без необходимости.
Шаг 1. Определите объект исключения
Сначала зафиксируйте системное имя post type или таксономии. В WordPress это не всегда то, что видно в админке. Например, у пользовательского типа записей может быть ярлык для интерфейса и отдельный технический ключ.
Если вы не уверены, посмотрите регистрацию объекта в коде темы или плагина. Обычно это что-то вроде register_post_type() или register_taxonomy().
Шаг 2. Добавьте исключение в настройках CyrtoLat
Если в настройках CyrtoLat есть поля для исключения post type или таксономий, внесите туда только нужные значения. Не добавляйте туда всё подряд: чем шире исключение, тем выше шанс получить несогласованные URL в будущем.
После сохранения настроек создайте тестовую запись или термин и проверьте, что slug больше не меняется автоматически.
Шаг 3. Если нужен код, ограничьте фильтр точечно
Иногда удобнее работать через код, особенно если исключение должно зависеть от условий. Например, автоподмена выключается только для одного post type, а для остальных остаётся активной.
<?php
add_filter( 'cyrtolat_excluded_post_types', function( $post_types ) {
$post_types[] = 'portfolio';
$post_types[] = 'docs';
return array_unique( $post_types );
} );
Если в вашей версии CyrtoLat используется другой фильтр или другой формат настроек, ориентируйтесь на документацию плагина. Смысл подхода один: не отключать обработку целиком, а добавить в исключения только конкретные сущности.
Для таксономий логика аналогична:
<?php
add_filter( 'cyrtolat_excluded_taxonomies', function( $taxonomies ) {
$taxonomies[] = 'project_category';
$taxonomies[] = 'brand';
return array_unique( $taxonomies );
} );
Что выбрать: настройка в интерфейсе, код или комбинированный вариант
| Способ | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Настройки CyrtoLat | Нужно быстро исключить один-два объекта | Безопасно и прозрачно для редакторов | Меньше гибкости |
| Код через фильтр | Исключение зависит от условий или окружения | Точная логика, можно версионировать | Нужен доступ к теме или mu-plugin |
| Комбинированный вариант | Часть исключений статическая, часть — динамическая | Удобно для крупных сайтов | Нужно следить за дублированием правил |
Проверка результата после внедрения
После изменения не ограничивайтесь визуальной проверкой в админке. Нужно убедиться, что URL действительно остались в нужном виде и не появились побочные эффекты.
- создайте новую запись в исключённом post type;
- создайте новый термин в исключённой таксономии;
- сравните slug до и после сохранения;
- проверьте, не создаются ли неожиданные редиректы;
- откройте страницу в браузере и убедитесь, что URL совпадает с ожидаемым;
- если сайт уже в индексе, проверьте, не изменились ли старые адреса в sitemap и внутренних ссылках.
Если у вас включён кэш, сбросьте его после изменения настроек. Иначе можно увидеть старую версию URL и решить, что исключение не сработало.
Быстрая техническая проверка
Для отладки удобно открыть объект в редакторе и посмотреть поле slug после сохранения. Если оно не меняется, но на фронтенде URL всё равно другой, проблема уже не в CyrtoLat, а в правилах перезаписи, кэше или другом плагине, который переписывает ссылки.
<?php
add_action( 'save_post', function( $post_id ) {
if ( wp_is_post_revision( $post_id ) ) {
return;
}
$post = get_post( $post_id );
if ( ! $post ) {
return;
}
error_log( sprintf(
'Saved post ID %d, type %s, slug %s',
$post_id,
$post->post_type,
$post->post_name
) );
} );
Частые ошибки и как их исправить
Добавили не тот ключ post type
Самая частая ошибка — указать не техническое имя, а ярлык из интерфейса. В результате исключение не срабатывает, хотя настройки выглядят корректно. Проверьте регистрацию типа записи в коде или через инструмент отладки.
Отключили автоподмену слишком широко
Если исключить сразу весь сайт или большой набор сущностей, можно получить несогласованные URL между разделами. Это особенно заметно на проектах, где часть контента уже проиндексирована. Лучше исключать по одному объекту и проверять результат после каждого изменения.
Не сбросили кэш
После изменения настроек старые URL могут продолжать отображаться из страницы кэша, object cache или CDN. Если проверяете результат сразу после правки, обязательно очистите кэш на всех уровнях.
Ожидали, что старые URL изменятся автоматически
Отключение автоподмены влияет на новые или пересохраняемые объекты. Уже опубликованные записи могут сохранить старый slug, пока вы их не обновите вручную. Это нормальное поведение, и его нужно учитывать при миграции.
Безопасность и производительность: что учесть на живом сайте
Если сайт большой, не вносите изменения прямо на продакшене без проверки. Лучше сначала повторить настройку на staging-копии. Это особенно важно, когда slug участвуют в навигации, sitemap и внешних интеграциях.
С точки зрения производительности сама точечная настройка CyrtoLat обычно не создаёт заметной нагрузки. Но проблемы начинаются, если вы добавляете сложную логику в фильтры, которая на каждом сохранении обращается к базе или внешним сервисам. Для исключений используйте простые массивы и статические условия.
Если в проекте несколько разработчиков, зафиксируйте исключения в коде, а не только в админке. Так проще отслеживать изменения через Git и не потерять настройки после обновления или переноса сайта.
Когда лучше не отключать автоподмену
Если у вас новый сайт без истории URL, отключение автоподмены для отдельных сущностей может быть лишним. В таких проектах проще выстроить единый стандарт slug сразу и не плодить исключения. Точечное выключение имеет смысл там, где уже есть технические причины сохранять старую схему адресов или где контент создаётся по разным правилам.
Если задача связана не с отдельными post type или таксономиями, а с конкретными URL внутри раздела, тогда логичнее смотреть в сторону настроек исключений по страницам или по отдельным адресам. Для этого сценария нужен другой подход, и смешивать его с исключением типов записей не стоит.