Свой тип записи в WordPress: какой способ выбрать

Каталог товаров, объектов недвижимости или услуг в WordPress не обязан жить среди обычных записей. В WordPress 6.x для него можно создать собственный тип записи, но способ регистрации повлияет на переносимость сайта, структуру URL, REST API и объём ручной работы. Ниже сравниваем три практических варианта: собственный PHP-код, Custom Post Type UI и Pods — и выбираем подход по требованиям проекта, а не по привычке.

Что именно вы выбираете

Собственный тип записи — это отдельная сущность в административной панели WordPress. Например, вместо того чтобы хранить товары в обычных записях, вы получаете раздел «Товары» со своими полями, архивом и шаблонами.

Важно разделить несколько задач:

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

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

Сноска. Таксономия — механизм WordPress для классификации записей. Категории и метки — встроенные примеры таксономий, а «бренд» или «район» можно зарегистрировать как отдельную пользовательскую таксономию.

Три варианта регистрации

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

Вариант 1: зарегистрировать тип записи кодом

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

Пример ниже написан для WordPress 6.x. Он создаёт тип записи product с архивом, REST API и поддержкой заголовка, редактора и миниатюры.

<?php
add_action('init', 'catalog_register_product_post_type');

function catalog_register_product_post_type() {
    register_post_type('product', array(
        'labels' => array(
            'name' => 'Товары',
            'singular_name' => 'Товар',
            'add_new_item' => 'Добавить товар',
            'edit_item' => 'Изменить товар',
        ),
        'public' => true,
        'has_archive' => true,
        'show_in_rest' => true,
        'menu_icon' => 'dashicons-cart',
        'supports' => array('title', 'editor', 'thumbnail'),
        'rewrite' => array('slug' => 'products'),
    ));
}

Функция register_post_type() должна выполняться на хуке init. Параметр public делает тип доступным в интерфейсе и на сайте, has_archive включает архив, а show_in_rest добавляет сущность в REST API и позволяет редактору Gutenberg работать с ней.

Что проверить после регистрации

1. Активируйте плагин или добавьте код в проект. В панели должен появиться раздел «Товары».
2. Создайте запись с заголовком и изображением. Страница записи должна открываться по адресу вроде /products/example/.
3. Откройте настройки WordPress и сохраните страницу постоянных ссылок. Это обновит правила маршрутизации без ручного вызова внутренних функций.
4. Проверьте REST API по адресу /wp-json/wp/v2/product. Если включён доступ к записи и тип зарегистрирован с show_in_rest => true, endpoint должен отвечать структурой REST API.

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

Вариант 2: Custom Post Type UI

Custom Post Type UI позволяет зарегистрировать тип записи через административную форму. Это удобно, если разработчик не нужен для первого запуска, а каталог состоит из простых сущностей. В настройках плагина вы задаёте machine name, подписи, публичность, архив и поддержку REST API.

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

Когда CPT UI выигрывает

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

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

Вариант 3: Pods как слой типов и полей

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

Цена удобства — дополнительный слой, который нужно учитывать при обновлении и переносе. Поле, созданное в интерфейсе Pods, нельзя рассматривать как обычную колонку таблицы WordPress. Шаблоны, запросы и экспорт должны использовать механизм, который вы выбрали в Pods, а не предположение о внутреннем формате хранения.

Где Pods оправдан

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

Какой подход выбрать

Решение зависит от того, где должна жить схема данных и кто будет её менять.

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

Что ломается чаще всего

Тип зарегистрирован внутри темы

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

Изменили slug, но старые URL не работают

WordPress хранит правила постоянных ссылок. После изменения rewrite сохраните настройки постоянных ссылок и проверьте архив, одиночную запись и ссылки на страницах.

Отключили плагин с регистрацией

Записи физически не обязательно удаляются, но WordPress перестаёт знать их тип. URL и раздел в админке исчезают. Перед удалением плагина перенесите регистрацию в код или подготовьте миграцию.

Включили REST API без проверки доступа

show_in_rest публикует тип в REST-маршрутах, но не отменяет проверки прав. Не добавляйте пользовательские поля в публичный ответ, пока не понимаете, кто и при каких условиях их увидит.

Поставили слишком общий slug

Slug вроде shop может пересекаться со страницей или правилами другого плагина. Выберите стабильное имя заранее и не меняйте его без плана перенаправлений.

Что делать дальше

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