Custom Post Type нужен, когда контент имеет отдельную структуру, жизненный цикл, таксономии и шаблоны вывода. Например, проекты портфолио или услуги удобнее хранить не как обычные записи и страницы, а как самостоятельные сущности с собственными URL, полями и правилами редактирования.

Содержание

В этой статье вы разберёте, как проходит WordPress-разработка Custom Post Type: от проектирования данных до регистрации через register_post_type, настройки rewrite, поддержки REST API с помощью show_in_rest и подключения полей ACF. Перед внедрением проверяйте решение на staging-копии сайта с резервной копией, учитывая версию WordPress, активную тему, плагины и права доступа.

Когда нужен CPT и как он связан с темой, блоками и API, показано в обзоре кастомной разработки WordPress. Здесь сосредоточимся на модели данных.

Что такое Custom Post Type

Чем Custom Post Type отличается от страниц и записей

Custom Post Type, или CPT, — это пользовательский тип записей в WordPress для контента со своей структурой и назначением. Он нужен, когда материалы логически отличаются от публикаций блога и обычных страниц: например, проекты, услуги, объекты недвижимости, специалисты или вакансии.

По умолчанию CPT использует стандартную систему хранения WordPress и определяется отдельным значением post_type. Это не обязательно новая таблица базы данных. WordPress-разработка Custom Post Type позволяет отделить сущности в админ-панели, назначить им собственные шаблоны, рубрики и правила отображения.

Когда стандартных записей мало

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

Критерий	Обычная запись	Страница	CPT
Основное назначение	Новости и статьи	Постоянные разделы сайта	Однотипные бизнес-сущности
Организация	Рубрики, метки, дата	Иерархия страниц	Собственные таксономии и поля
Шаблоны	Общий шаблон публикаций	Шаблон страницы	Отдельные шаблоны списка и объекта
Редактируемость	Подходит для редакционного потока	Удобна для единичного контента	Настраивается под конкретную сущность

CPT оправдан, если вам нужны специальные таксономии, повторяемая структура карточки и отдельное представление в админ-панели. Дополнительные характеристики можно хранить как метаданные; для удобного интерфейса редактора часто применяют поля ACF WordPress. При этом набор полей следует определять по задачам контента, а не добавлять «на будущее».

Если различается только внешний вид одной страницы, новый тип записей может быть избыточен. Иногда достаточно шаблона страницы, блока или существующей таксономии. Заранее продумайте будущие URL: при изменении уже проиндексированной структуры может потребоваться перенаправление.

Примеры: кейсы и услуги

Для портфолио проектов отдельный WordPress Custom Post Type помогает хранить название кейса, отрасль, выполненные работы и связанные изображения. Таксономия может группировать проекты по направлению или сфере клиента. Вы сможете выводить общий архив портфолио и отдельную карточку каждого проекта, не смешивая их со статьями.

Для каталога услуг CPT подходит, когда каждая услуга имеет одинаковую базовую структуру: описание, преимущества, этапы, связанные специалисты или проекты. Отдельные таксономии полезны для группировки по направлению либо типу клиента.

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

Спроектируйте структуру

Проектирование полей, таксономий и связей типа записи

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

Тип записи и таксономии

Создавайте отдельный тип записи, если контент имеет собственный жизненный цикл, набор шаблонов и правила классификации. Например, проекты портфолио регулярно добавляются, фильтруются по отрасли и технологии, но не участвуют в новостной ленте. Для них подходит CPT «Проекты», а «Отрасли» и «Технологии» можно оформить как таксономии.

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

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

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

Поля и права доступа

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

Также определите роли пользователей: кто может создавать, редактировать, публиковать и удалять записи. Не полагайтесь только на скрытие элементов в административном интерфейсе — ограничения должны проверяться через права доступа WordPress. Если данные планируется передавать в REST API, заранее разделите публичные и служебные поля.

Чек-лист структуры данных:

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

Перед внедрением сопоставьте схему с используемой темой, плагинами и версией WordPress: совместимость нельзя гарантировать без такой проверки. Изменения сначала проверяйте на staging-копии сайта и сохраняйте резервную копию рабочей базы данных.

Зарегистрируйте тип записи

Регистрация Custom Post Type и доступ в панели управления

Плагин или собственный код

WordPress Custom Post Type можно зарегистрировать через плагин-конструктор или собственный код. Плагин удобен, если вам нужен интерфейс для базовой настройки и команда не планирует поддерживать PHP-код. Однако перед выбором проверьте совместимость решения с текущей версией WordPress, темой и другими плагинами.

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

Функцию register_post_type() обычно вызывают на событии init. Системное имя типа должно быть уникальным, содержать не более 20 символов и использовать строчные латинские буквы, цифры, дефисы или подчёркивания. Добавьте собственный префикс, чтобы снизить риск конфликта.

function ua_site_register_project_cpt() {
    $labels = array(
        'name'          => 'Проекты',
        'singular_name' => 'Проект',
        'add_new_item'  => 'Добавить проект',
        'edit_item'     => 'Редактировать проект',
    );

    register_post_type(
        'ua_project',
        array(
            'labels'             => $labels,
            'public'             => true,
            'publicly_queryable' => true,
            'show_ui'            => true,
            'show_in_rest'       => true,
            'has_archive'        => true,
            'rewrite'            => array(
                'slug'       => 'projects',
                'with_front' => false,
            ),
            'supports'           => array(
                'title',
                'editor',
                'thumbnail',
                'excerpt',
            ),
            'capability_type'    => 'post',
            'map_meta_cap'       => true,
        )
    );
}
add_action( 'init', 'ua_site_register_project_cpt' );

show_in_rest открывает тип записи для REST API и требуется для работы блочного редактора. В примере права наследуются от обычных записей. Если проекты должны редактировать только отдельные роли, настройте собственные capabilities и проверьте их через current_user_can(). Данные из пользовательских полей необходимо валидировать при сохранении и экранировать при выводе.

Слаги и постоянные ссылки

Параметр rewrite определяет URL. Для типа ua_project выбран публичный слаг projects, поэтому архив может находиться по адресу /projects/, а отдельная запись — /projects/nazvanie-proekta/. Системное имя и URL-слаг не обязаны совпадать.

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

После первой регистрации или изменения rewrite обновите правила постоянных ссылок: сохраните соответствующую страницу настроек либо вызовите flush_rewrite_rules() однократно при активации плагина. Не вызывайте эту функцию при каждом запросе — операция создаёт лишнюю нагрузку.

Доступность URL не определяет его индексацию. Директиву noindex, canonical и карту сайта проверяйте отдельно в SEO-настройках. Перед запуском откройте архив и отдельную запись без авторизации, убедитесь в отсутствии ошибки 404 и повторно проверьте маршруты после обновления темы или плагинов.

Настройте редактор и вывод

Путь данных CPT от редактора до страницы и архива

Поддержка REST API

Чтобы пользовательский тип записей работал с блочным редактором и был доступен через WordPress REST API, при регистрации укажите 'show_in_rest' => true. После этого WordPress создаст стандартные REST-маршруты для чтения и управления объектами с учётом прав текущего пользователя.

Набор инструментов редактора определяется параметром supports. Для портфолио могут понадобиться заголовок, основной текст, миниатюра, краткое описание и ревизии:

'supports' => array( 'title', 'editor', 'thumbnail', 'excerpt', 'revisions' )

Для каталога услуг оставляйте только действительно используемые элементы. Например, если описание, цена и длительность вынесены в структурированные поля ACF, дублировать их в основном редакторе не следует. Это упрощает ввод данных и снижает риск противоречий.

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

Шаблон архива и одиночной записи

Для типа с идентификатором project создайте в теме файлы single-project.php для отдельного проекта и archive-project.php для списка проектов. Если специальных файлов нет, WordPress продолжит поиск по иерархии шаблонов и может использовать общие single.php, archive.php или index.php.

Архив будет доступен только при соответствующей настройке has_archive. Его URL также зависит от параметров rewrite. Перед изменением структуры адресов сделайте резервную копию и проверьте результат на staging: смена slug способна создать старые неработающие URL, для которых потребуются перенаправления.

В портфолио выводите обложку, название, отрасль или другую таксономию и ссылку на подробную страницу.
В каталоге услуг предусмотрите понятный архив, фильтрацию по таксономиям и единообразный шаблон карточки.
Экранируйте обычный текст через esc_html(), URL — через esc_url(), а разрешённый HTML — через wp_kses_post().
После дополнительных циклов восстанавливайте глобальные данные записи с помощью wp_reset_postdata().

Изменение шаблона само по себе не гарантирует повторного обхода страницы поисковой системой. Если поменялись URL, канонические адреса или доступность контента, проверьте карту сайта, перенаправления, HTTP-статусы и правила индексации. Совместимость шаблонов, REST API и ACF проверяйте для используемых версий WordPress, темы и плагинов.

Проверка перед публикацией

Перед переносом Custom Post Type на рабочий сайт проверьте его на staging-копии и создайте резервную копию файлов и базы данных. Нельзя заранее обещать совместимость: результат зависит от версии WordPress, активной темы, плагинов, правил постоянных ссылок и серверной конфигурации.

Пройдите следующий чек-лист:

Регистрация: убедитесь, что тип записи появляется в нужных разделах панели управления, а его системный идентификатор не конфликтует с названием страницы, таксономии или существующим rewrite-правилом.
URL: откройте одиночную запись и архив, если он включён. Проверьте человекопонятные адреса, пагинацию и отсутствие ошибок 404. После изменения rewrite-настроек один раз пересохраните постоянные ссылки либо обновите правила при активации плагина. Не вызывайте их принудительное обновление при каждом запросе.
Canonical: проверьте, какой основной адрес указывает SEO-плагин для архива и отдельных материалов. Если вы только разбираетесь, что такое canonical url, воспринимайте его как указание поисковой системе на предпочтительную версию страницы среди доступных дублей.
Права: войдите под ролями администратора, редактора и других участников проекта. Пользователь должен видеть, создавать, редактировать и удалять только разрешённые ему материалы. При обработке форм дополнительно проверяйте capability и nonce.
Данные: протестируйте обязательные и необязательные поля ACF, пустые значения, изображения и повторяющиеся блоки. Входные данные валидируйте и очищайте, а при выводе применяйте экранирование с учётом контекста: текста, атрибута, URL или HTML.
REST API: если используется show_in_rest, проверьте получение записей через API, доступность нужных полей и запрет закрытых данных для неавторизованного запроса. Сам параметр не делает пользовательские поля автоматически публичными.
Шаблоны: откройте одиночную страницу, архив, результаты поиска и связанные таксономии на мобильном и настольном экране. Проверьте случаи без изображения, описания или назначенного термина.
Интеграции: отдельно протестируйте кеширование, SEO-плагин, мультиязычность, поиск и конструктор страниц, если они участвуют в проекте.

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

Зафиксируйте идентификатор CPT, slug, таксономии, набор полей и правила доступа в документации проекта. Это упростит сопровождение и снизит риск того, что последующая wordpress разработка custom post type нарушит существующие адреса или структуру данных.

Официальная документация: регистрация пользовательских типов записей.