Свой тип записи в WordPress для каталога: что работает

Если каталог в WordPress начинается с десятка карточек, обычные записи быстро превращаются в компромисс: новости смешиваются с товарами, фильтры завязаны на хаки, а редактор получает поля, которые нельзя нормально проверить. Рабочая схема для WordPress 6.x — отдельный Custom Post Type, таксономии для группировки и понятный способ хранения характеристик. Но регистрировать всё подряд отдельными полями тоже не стоит: это усложнит шаблоны, импорт и поиск.

Сначала определите, что именно вы строите

Слово «каталог» описывает не одну задачу. Каталог услуг, витрина товаров без корзины и полноценный интернет-магазин требуют разных моделей данных.

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

Главная ошибка каталога — не отсутствие фильтра. Это неверно выбранная модель данных: когда цену, адрес и статус прячут в тексте, любой следующий шаг становится ручной работой.

¹ Custom Post Type — пользовательский тип записи WordPress. Это отдельная сущность в админке, но не отдельная таблица базы данных: записи такого типа хранятся в стандартной таблице записей WordPress.

Регистрируйте тип записи в плагине, а не в теме

Тип записи должен существовать независимо от оформления. Если положить регистрацию в functions.php темы, после смены темы каталог исчезнет из админки или перестанет корректно обрабатываться. Для WordPress 6.x вынесите код в небольшой собственный плагин или в функциональный плагин сайта.

Базовая регистрация CPT и рубрик каталога

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

<?php

add_action('init', 'my_catalog_register_content');

function my_catalog_register_content() {
    register_post_type('catalog_item', [
        'labels' => [
            'name' => 'Каталог',
            'singular_name' => 'Карточка каталога',
            'add_new_item' => 'Добавить карточку',
            'edit_item' => 'Редактировать карточку',
        ],
        'public' => true,
        'show_in_rest' => true,
        'menu_icon' => 'dashicons-archive',
        'supports' => ['title', 'editor', 'thumbnail', 'excerpt'],
        'has_archive' => true,
        'rewrite' => ['slug' => 'catalog'],
    ]);

    register_taxonomy('catalog_category', ['catalog_item'], [
        'labels' => [
            'name' => 'Категории каталога',
            'singular_name' => 'Категория каталога',
        ],
        'public' => true,
        'show_in_rest' => true,
        'hierarchical' => true,
        'rewrite' => ['slug' => 'catalog-category'],
        'show_admin_column' => true,
    ]);
}

Проверка после установки: в админке появляется меню «Каталог», а новая запись открывается по адресу вроде /catalog/example/. Если вместо страницы видите 404, откройте «Настройки» → «Постоянные ссылки» и один раз сохраните настройки. Это обновляет правила маршрутизации; вызывать обновление при каждом запросе нельзя.

Почему важны show_in_rest и supports

show_in_rest => true добавляет тип записи в REST API и делает его совместимым с редактором блоков. Без этого карточка может открываться в старом редакторе, а интеграции и headless-сценарии не увидят её ожидаемым способом.

Массив supports не описывает бизнес-поля. Он включает стандартные возможности WordPress: заголовок, основной текст, миниатюру и краткое описание. Поля вроде «Цена», «Площадь» или «Срок оказания» нужно проектировать отдельно.

Разделяйте характеристики, рубрики и свободный текст

У карточки обычно есть три разных слоя данных:

• контент — описание, условия, изображения;
• таксономии — категория, город, тип услуги, бренд;
• метаполя — цена, артикул, площадь, срок, координаты.

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

Нативные поля или плагин

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

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

Шаблоны: архив и карточка должны решать разные задачи

Для зарегистрированного типа записи WordPress ищет шаблоны по его имени. Обычно это:

• single-catalog_item.php — отдельная карточка;
• archive-catalog_item.php — список карточек;
• taxonomy-catalog_category.php — архив категории каталога.

На архиве показывайте только данные, необходимые для выбора: изображение, название, короткую характеристику, цену или призыв открыть карточку. Полное описание и все поля оставляйте для single-catalog_item.php. Так страница списка не превращается в длинную ленту одинаковых текстов.

Не зашивайте в шаблон условие вроде «если заголовок равен такому-то». Для структуры используйте таксономии и метаполя. Тогда редактор сможет добавить новую категорию без изменения PHP.

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

Тип записи зарегистрирован, но URL отдаёт 404

Чаще всего не обновились правила постоянных ссылок. Сохраните их один раз в админке после изменения аргумента rewrite. Если ошибка остаётся, проверьте конфликт slug: одинаковый путь не должны одновременно использовать страница, таксономия и архив CPT.

После смены темы каталог исчез

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

Фильтр работает медленно или выдаёт странные результаты

Проверьте, где лежат значения. Таксономия подходит для категорий и иерархии, а числовые характеристики должны иметь единый формат. Запись «от 10 000», «10000 ₽» и «10 тыс.» в одном поле нельзя надёжно отсортировать без предварительной нормализации.

Карточка есть в админке, но её нет в REST API

Проверьте show_in_rest у типа записи и таксономии. Также убедитесь, что запрос обращается к правильному имени типа — в примере это catalog_item, а не подпись «Каталог» из интерфейса.

Когда какой вариант выбирать

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

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

Что проверить следующим шагом

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

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