Кастомные типы записей WordPress: когда нужен отдельный раздел

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

Страница, рубрика или отдельный тип

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

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

Составьте паспорт сущности

• Название объекта в единственном и множественном числе: понятно ли редактору, что он создаёт?
• Обязательные поля и допустимые пустые состояния: можно ли опубликовать проект без галереи?
• Связи: одна или несколько услуг, повторное использование изображений, порядок элементов.
• Статусы: черновик, проверка, публикация; кто отвечает за переход.
• Публичность: нужна ли отдельная страница, архив, поиск по сайту и доступ через API?
• Экспорт и удаление: что происходит со связями, если объект архивирован или удалён?

Для каждого поля укажите формат и правило проверки. Например, «год завершения — целое число; незавершённый объект не маскируется фиктивным годом». Не создавайте отдельное поле для каждой строки свободного описания: редактор получит форму, которую трудно поддерживать. И наоборот, не прячьте фильтруемые характеристики в произвольном HTML.

Что важно при регистрации

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

Настройки public, show_ui, publicly_queryable, has_archive и show_in_rest решают разные задачи. Отображение раздела в админке не означает, что ему нужна публичная одиночная страница. Для использования типа в блочном редакторе необходимо включить show_in_rest, но также проверить поддержку редактора и остальные условия установки. Не включайте все флаги автоматически: сверяйте их со спецификацией и справочником register_post_type().

Права задают отдельно. Для команды, которой разрешены проекты, но не новости, недостаточно изменить подпись меню. Разработчик проектирует capabilities и их сопоставление для операций с конкретными объектами, затем выдаёт нужные полномочия выбранной роли. Защита должна работать при прямом запросе, а не только при нажатии кнопки.

Спланируйте адреса до заполнения

Проверьте, не занят ли выбранный путь обычной страницей, таксономией или другим расширением. Определите, как выглядит архив, одиночный объект, пагинация и пустая подборка. Регистрацию и обновление правил адресации выполняют контролируемо; постоянный сброс rewrite rules на каждом запросе не нужен.

Если раздел уже существует в обычных страницах, подготовьте соответствие старых и новых записей. Сохраните изображения, авторство, ссылки и SEO-данные, если они применяются. Не меняйте массово post_type без проверки связанных полей, шаблонов и разрешений. Сначала перенесите несколько разных объектов и проверьте, как они редактируются и открываются. Сам план редиректов относится к отдельной задаче переезда; здесь важно не потерять смысл и связи объектов.

Приёмка на неудобных данных

1. Создайте проект с длинным названием, несколько проектов одной категории и объект с допустимыми незаполненными полями.
2. Проверьте сохранение, повторное открытие и публикацию под рабочими ролями. Пользователь без нужных полномочий не должен менять чужой объект прямым запросом.
3. Откройте архив и одиночную страницу без авторизации; убедитесь, что черновики не стали публичными.
4. Проверьте, как выводятся пустой список, последняя страница архива и удалённый объект.
5. Смените тему на копии: данные и экран управления должны остаться, хотя оформление может измениться.
6. Выгрузите и восстановите образцы вместе с полями и связями выбранным для проекта способом.

Как исправлять ошибки модели без потери данных

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

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