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 та потрібен для роботи блокового редактора. У прикладі права успадковуються від традиційних записів. Якщо проекти повинні редагувати лише окремі ролі, налаштуйте власні можливості та перевірте їх через 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, активної теми, плагінів, правил постійних посилань та серверної конфігурації.

Пройдіть наступний чек-лист:

Реєстрація: переконайтеся, що тип запису з'являється в потрібних розділах панелі керування, а його системний ідентифікатор не конфліктує з назвою сторінки, таксономії або існуючим правовим правилом.
URL: відкрийте одиночний запис та архів, якщо він увімкнений. Перевірте людинозрозумілі адреси, пагінацію та відсутність помилок 404. Після зміни rewrite-налаштувань один раз перезбережіть постійні посилання або оновіть правила під час активації плагіна. Не викликайте їхнє примусове оновлення при кожному запиті.
Canonical: перевірте, яка основна адреса вказує SEO-плагін для архіву та окремих матеріалів. Якщо ви тільки знаєте, що таке canonical url, сприймайте його як вказівку пошукової системи на кращу версію сторінки серед доступних дублів.
Права: увійдіть під ролями адміністратора, редактора та інших учасників проекту. Користувач повинен бачити, створювати, редагувати та видаляти лише дозволені йому матеріали. При обробці форм додатково перевіряйте здатність і неможливість.
Дані: протестуйте обов'язкові та необов'язкові поля ACF, порожні значення, зображення та блоки, що повторюються. Вхідні дані валідуйте та очищайте, а при виведенні застосовуйте екранування з урахуванням контексту: тексту, атрибуту, URL або HTML.
REST API: якщо використовується show_in_rest, перевірте отримання записів через API, доступність потрібних полів та заборону закритих даних для неавторизованого запиту. Сам параметр не робить поля користувача автоматично публічними.
Шаблони: відкрийте одиночну сторінку, архів, результати пошуку та пов'язані таксономії на мобільному та настільному екрані. Перевірте випадки без зображення, опису або терміну.
Інтеграція: окремо протестуйте кешування, SEO-плагін, мультимовність, пошук та конструктор сторінок, якщо вони беруть участь у проекті.

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

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

Офіційна документація: реєстрація користувачів типів записів.