Створюйте власні типи публікацій і спеціальні таксономії в WordPress за допомогою коду
Це навчальний посібник із створення спеціального типу публікації та спеціальної таксономії в WordPress за допомогою коду. Ми розглянемо типові підводні камені та розглянемо, які аргументи використовувати для мінімального, але достатнього створення. Повний приклад включено в кінці.
Куди додати код
Створення користувацьких типів публікацій (CPT) і користувальницьких таксономій у WordPress можна виконати у functions.php
файлі теми або в плагіні. Майте на увазі, що спеціальний тип публікації та спеціальна таксономія зникнуть, якщо ви зміните тему або деактивуєте плагін. Тож можна безпечно тимчасово видалити реєстрацію CPT із теми та перемістити її до плагіна, доки ви збережете той самий власний тип публікації чи ідентифікатор таксономії slug/ID.
Для створення (і модифікації) CPT або таксономії завжди використовуйте хук init
. Розміщення його в корені functions.php
(поза гачком) або будь-якого іншого гачка спричинить проблеми.
Створення власного типу публікації
Для створення спеціального типу публікації ви використовуєте register_post_type
функцію. Він приймає два параметри; спочатку ідентифікатор типу повідомлення, а потім масив з усіма аргументами.
Ідентифікатор типу публікації – це ім’я версії слаг-версії вашого типу публікації. Наприклад, вбудовані типи публікацій WordPress і сторінки позначаються як «post
» і «page
». Ідентифікатор має бути унікальним, відповідати набору правил (маленький регістр, без пробілів тощо) і не бути одним із зарезервованих слагів WordPress.
Це те, що я дізнався, як мінімальний, але цілком достатньо вагомий аргумент для реєстрації типу публікації; враховуючи, що це звичайний загальнодоступний CPT, і ви бажаєте замінити будь-які мітки, у яких написано «публікація» або «сторінка», фактичною назвою вашого CPT:
Огляд аргументів
Майте на увазі, що деякі аргументи успадковують значення від інших аргументів. Якщо вони не встановлені явно, за умовчанням вони можуть використовувати те саме значення або протилежне іншому. Декілька аргументів успадковують те саме або протилежне значення аргументу public
. Прочитайте документацію, щоб побачити значення за замовчуванням для кожного аргументу та чи потрібно його замінити.
Якщо ви влаштовуєте тексти в адміністраторі, які посилаються на тип вашої публікації як «публікація» або «сторінка», ви можете пропустити визначення аргументів мітки. Ймовірно, вам підійде лише label
(ім’я у множині) і лише всередині labels
масиву singular_name
(ім’я в однині).
Якщо ви явно не встановите show_in_rest
значення true, для вашого спеціального типу позиції використовуватиметься старий класичний редактор. Якщо ви бажаєте використовувати редактор Gutenberg для свого спеціального типу публікації, вам потрібно встановити show_in_rest
значення true.
Аргумент supports
повідомляє, які елементи доступні під час редагування публікації у вашому типі публікації. Як мінімум вам, мабуть, потрібен заголовок, редактор і зображення пропонованого допису.
Аргумент rewrite
із мінімумом елемента масиву slug
повідомляє WordPress переписати всі окремі повідомлення вашого типу, щоб використовувати цей слаг префікса. У наведеному вище прикладі окрема книжкова публікація отримає URL-адресу типу; ” http://example.com/book/i-robot/ “. Якщо вам цікаво, як додати налаштування правила постійного посилання в admin, щоб дозволити користувачам теми самостійно вирішувати цей слаг, перегляньте цю публікацію.
Аргументом для піктограми меню (menu_icon
) може бути будь-який із наведених нижче Dashicons, або ви можете залишити його пустим, щоб зберегти значення за замовчуванням. За замовчуванням використовується та сама піктограма, що й Публікації. Однак доцільно чітко розділити власні типи публікацій.
Позиція меню (menu_position
) дозволяє вам визначити позицію вашого власного типу публікації в меню адміністратора. У документації перераховано всі позиції меню адміністратора, щоб ви могли налаштувати; позиція 5 знаходиться одразу після «Публікацій».
Існує ще один аргумент (taxonomies
) для додавання таксономії до типу публікації. Далі в цьому дописі ми розглянемо, як додати спеціальну таксономію. Щоб додати таксономії до вашого типу публікації, додайте цей аргумент до наведеного вище масиву;
Примітка щодо постійних посилань і помилок 404 не знайдено
Після того, як ви додали свій код для реєстрації спеціального типу публікації, ви помітите, що перегляд окремої публікації повертатиме помилку «404 не знайдено». Це тому, що вам потрібно «оновити постійні посилання».
Перейдіть у «Параметри» > «Постійні посилання» та просто натисніть кнопку «Зберегти зміни» (нічого змінювати не потрібно).
Майте на увазі, що коли ви змінюєте rewrite
атрибут, вам потрібно буде знову оновити постійні посилання.
Створення власної таксономії
Спеціальну таксономію можна приєднати до одного з типів публікацій WordPress (дописи, сторінки) або до спеціального типу публікації. Ви також можете додати кілька таксономій до типу публікації. Коли ви реєструєте таксономію, вам потрібно вказати типи публікацій, до яких ви хочете її приєднати.
Таксономія може бути ієрархічною (як категорії публікацій, де ви можете створити структуру на основі дерева) або на основі тегів (як теги публікацій). Це справді єдиний фактор, який вам потрібно знати заздалегідь, за винятком його ідентифікатора. Як і у випадку з CPT, ідентифікаційна частина таксономії має бути унікальною та відповідати набору правил.
Для реєстрації спеціальної таксономії ви використовуєте register_taxonomy
функцію. Приймає слаг register_taxonomy
унікального ідентифікатора таксономії як перший аргумент, масив типів публікацій, до яких його потрібно приєднати, як другий, і, нарешті, масив з усіма іншими аргументами. Є багато аргументів, але це те, що на мою думку, є мінімальним, але достатнім для реєстрації спеціальної таксономії (це додає тип тегу/неієрархічну таксономію):
Рекомендується додавати виклик функції відразу після register_taxonomy
, щоб переконатися, що він правильно «приєднаний» до CPT: register_taxonomy_for_object_type
. Визначте свою таксономію як перший аргумент, а CPT як другий:
register_taxonomy_for_object_type('book_author', 'book');
Подібно до типу повідомлення вище, register_taxonomy
приймає набагато більше аргументів, і багато з них успадковують або залежать від значення інших аргументів. Прочитайте документацію, щоб побачити значення за замовчуванням для кожного аргументу та чи потрібно його замінити.
Огляд аргументів
Якщо ви влаштовуєте тексти, які посилаються на вашу таксономію як «тег» (якщо ієрархічний — хибний) або «категорія» (якщо ієрархічний — істинний), можливо, ви можете пропустити весь labels
масив, за винятком, можливо, singular_name
.
Це show_admin_column
зручно для додавання стовпця, що показує пов’язані терміни у вашій таксономії на екрані адміністратора CPT. Так само, як у Публікаціях, ви бачите стовпець із пов’язаними категоріями. Цей аргумент за замовчуванням має значення false
(не показувати стовпець), тому я хочу його замінити.
show_in_rest
Для того, щоб ваша таксономія була видимою в публікації в редакторі Gutenberg, потрібно встановити значення true, оскільки Gutenberg покладається на REST API.
Так само, як і з користувацькими типами публікацій, ви, ймовірно, отримаєте помилку «404 не знайдено» у вашій користувацькій таксономії. Перейдіть до Налаштування > Постійні посилання та просто натисніть кнопку «Зберегти зміни».
Повний приклад коду
Ось повний приклад створення CPT для книг і додавання двох спеціальних таксономій; жанр (ієрархічний) і автор книги (тег).