Повне керівництво по користувацьких типів посад у WordPress

24

Від автора: Дні, коли WordPress був просто системою для блогів, пройшли. Можливість розширення функціоналу за допомогою плагінів і тим, групування посад, структуризацію даних за типами, а також поява в ядрі WP Rest API призвели до еволюціонування WordPress в повномасштабну систему управління контентом і платформу розробки.

За ці роки я успішно створив велику кількість кастомних веб-додатків на новітніх версіях WordPress, в яких по повній використовувалися кастомні типи постів. Прикладом може послужити сайт theme marketplace мого плагіна WordPress ProfilePress.

Якщо детальніше придивитися до магазину тим по посиланню вище, можна помітити, що на ньому використовується кастомний система посторінкової навігації на основі URL посилань для наступної і попередньої сторінок. Тобто можна створити свою систему посторінкової навігації, яка відмінно буде працювати з запитами постів користувацьких типів.

Ну вистачить довгих промов, перейдемо до основної мети даного уроку – вивчення всіх тонкощів користувацьких типів WordPress.

Сподіваюся, ми вирішимо багато проблем, з якими я особисто зіткнувся при роботі з кастомних типами посад, а також розглянемо інші круті можливості.

Визначення типу постів

WordPress може зберігати і відображати безліч різних типів контенту. Одна частина даного контенту називається постом, хоча піст сам по собі є специфічним типом постів. «Всі типи постів зберігаються в одному місці, в таблиці wp_posts бази даних, але пости розрізняються по колонці post_type»

Post type відноситься до різних структурованим даним, згрупованих разом, і які обслуговуються в базі даних WordPress в таблиці posts.

Прикладом типу постів служить тип post (група постів блогу), page (група сторінок), attachment (група завантажуваних медіа файлів), а також revision (група редакцій постів). Всі ці типи рідні або вбудовані в WordPress. Знаючи, що таке тип посту, можна створити і зареєструвати новий тип, який буде ставитися до кастомным типами посад.

Якщо ви створюєте сайт для компанії або бізнесу на WordPress, то типами постів можуть бути Portfolio, Testimonials і Products. Тепер, коли ми розібралися з концепцією користувацьких типів постів, давайте навчимося їх створювати.

Як створити користувальницький тип постів

Створити користувальницький тип постів досить просто. Спершу, необхідно зареєструвати тип за допомогою функції register_post_type(), потім помістити його в функцію і прикріпити все це до екшену init:

function portfolio_cpt() {
$args = array(
‘label’ => ‘Portfolio’,
‘public’ => true,
);
register_post_type( ‘portfolio’, $args );
}
add_action( ‘init’, ‘portfolio_cpt’ );

У коді вище можна помітити, що другий параметр функції register_post_type() приймає масив з декількох обов’язкових аргументів, які потрібні для створення користувальницького типу посту. Створений тип Portfolio можна подивитися в панелі адміністратора.

Повне керівництво по користувацьких типів посад у WordPress

Необхідно також сказати, що у функції register_post_type() другий необов’язковий аргумент. Користувальницький тип постів можна створити і по-іншому:

function portfolio_cpt() {
register_post_type( ‘portfolio’ );
}
add_action( ‘init’, ‘portfolio_cpt’ );

Якщо створити тип, як показано вище, то він не буде відображатися в панелі адміністратора (хоча до нього можна звернутися за посиланням http://example.com/wp-admin/edit.php?post_type=portfolio“), назва також не буде відображатися (label), а повідомлення адміністратора будуть такими ж, як і для вбудованих типів посад. Пробіжимося по аргументам масиву налаштування користувацьких типів і по відповідним функціям.

Label

Множинне описове ім’я типу. Наприклад, якщо створити тип movie, то він повинен називатися Movies. За умовчанням коштує $post_type – перший параметр функції register_post_type().

Labels

Масив лейблів для типу постів. Кожна текстова рядок відображається на певній сторінці панелі адміністратора. Якщо плагін створюється для публічного користування, перевірте, щоб рядки були перекладними.

name: Множинна форма назви типу постів.

singular_name: Форма назв типів постів в однині.

add_new: Пункт меню для додавання нового поста.

add_new_item: При створенні нового посту відображається заголовок.

edit_item: Заголовок відображається при редагуванні посту.

new_item Відображається в меню улюблених в шапці панелі адміністратора.

view_item: Відображається разом з посиланням на екрані редагування посту.

search_items: Текст кнопки панелі пошуку на екрані редагування посту.

not_found: Текст відображається, коли не знайдено жодної посади в пошуку через панель адміністратора.

not_found_in_trash: Текст відображається, коли в кошику немає постів.

Повний список лейблів та їх описів можна знайти за посиланням.

Description

Короткий опис типу посту. Я не знайшов, де в WordPress можна задіяти.

Public

Залежно від Булеві значення воно автоматично вирішить, які повинні бути аргументи, якщо вони не задані. Якщо ви хочете контролювати публічні аргументи, можна задати три аргументи:

show_ui: задає відображення екрани панелі адміністратора.

publicly_queryable: визначає, чи можна виконати запити по цьому типу постів з боку користувача.

exclude_from_search: чи повинні пости з’являтися в результатах пошуку.

menu_position

За замовчуванням новий тип постів додається після пункту меню «Коментарі» в панелі адміністратора. Але є можливість пересунути цей новий пункт меню. Наприклад, якщо задати menu_position 70 ваш пункт меню виявиться нижче пункту «Користувачі».

menu_icon

Новим типам посад присвоюються іконки за замовчуванням, але якщо ви хочете вказати свої іконки, додайте адреса на іконці до значенню цього лейблу.

‘menu_icon’ => get_stylesheet_directory_uri() . ‘/images/portfolio-icon.png’,

В якості іконок для користувацьких типів постів можна використовувати dashicon. Скажімо, ви хочете використовувати іконку download dashicon, для цього встановіть лейблу нижче значення dashicons-download:

‘menu_icon’ => ‘dashicons-download’,

Hierarchical

За допомогою цього аргументу можна встановлювати ієрархію для нових типів. За замовчуванням варто значення false. Якщо встановити true, нові типи стануть ієрархічними.

Supports

За допомогою цього аргументу можна задати масив мета боксів і полів, які будуть з’являтися на екрані під час редагування або створення нового посту. За замовчуванням стоїть title й editor. Якщо задати false, відключиться стандартна поведінка. Є кілька можливих опцій:

title: Поле введення тексту для створення заголовку поста.

editor: TinyMCE редактор для написання тексту поста.

author: Випадаючий список, де можна змінити автора посту.

thumbnail: вбудовані зображення.

excerpt: Область textarea для уривка посту.

trackbacks: включення і відключення трекбеков і пингбеков.

custom-fields: кастомні поля вводу.

comments: увімкнення або вимкнення коментарів.

revisions: Можливість редакції постів.

post-formats: Додає формати постів

page-attributes: Атрибути сторінки. Важливий параметр для ієрархічних типів постів, можна обрати батьківський пост.

register_meta_box_cb

Додає колбек функцію, яка викликається при установці мета боксів для форми редагування. Функція приймає один аргумент $post, в якому зберігається об’єкт WP_Post поточного редагованого посту. Функція особливо корисна для розробників. З її допомогою можна створювати користувальницькі мета бокси, які будуть відображатися на екрані редагування типу.

‘register_meta_box_cb’ => ‘metabox_callback_func’,

Taxonomies

Масив зареєстрованих таксономій, таких як category або post_tag, які будуть використовуватися з кастомным типом постів.

‘taxonomies’ => array( ‘post_tag’, ‘category ‘),

has_archive

Якщо встановити даний аргумент в true, до кастомным типами посад додадуться архіви. Наприклад, новий тип books, якщо зайти на сторінку http://yoursite.com/books, то відобразиться список постів за типом books.

Rewrite

За допомогою даного аргументу при перегляді одного поста або архіву можна задати структуру посилань даного типу. За замовчуванням стоїть true і використовується змінна $post_type. Щоб відключити перезапис, необхідно встановити даний параметр в false. Для повної ясності розберемо кілька прикладів. Скажімо, ви створили новий тип постів review і хочете змінити URL з review на assessment. Аргумент для перезапису нижче змінить URL з http://example.com/review/harry-potter/ на http://example.com/assessment/harry-potter/ для конкретного поста і http://example.com/review/ на http://example.com/assessment/ для архіву даного типу.

‘rewrite’ => array(
‘slug’ => ‘assessment’,
‘with_front’ => false
),

Завжди при зміні URL в WordPress зберігайте зміни в панелі Установки >> посилання для повторного створення правил перезапису. Параметр slug відповідає за URL, а with_front задає буде структуру посилання. Все ще не зрозуміли для чого потрібен with_front? Розберемо приклад. Скажімо, структура вашого посилання точно така ж як на зображенні нижче з написом blog на кінці.

Повне керівництво по користувацьких типів посад у WordPress

Якщо with_front дорівнює false, URL конкретного поста та архіву будуть виглядати http://example.com/blog/assessment/harry-potter/ і http://example.com/blog/assessment відповідно, але якщо поставити true, то посилання до посту і до архіву будуть наступні http://example.com/assessment/harry-potter/ і http://example.com/assessment/. Помітили, що в останніх посиланнях немає blog? От у цьому різниця.

can_export

За допомогою даного аргументу можна задати, чи можна експортувати пости кастомного типу через інструменти WordPress. За замовчуванням стоїть true.

query_var

За допомогою даного аргументу можна контролювати змінні запиту, що використовуються для отримання постів даного типу.
Якщо встановлено значення true, ви зможете запросити кастомный тип book за посиланням example.com/?book=harry-potter, де harry-potter це параметр slug посилання. Якщо задати рядок, а не true, можна написати так: example.com/?publication=harry-potter.

Нюанс з query_var

Якщо query_var не заданий в аргументі масиву реєстрації типу, за замовчуванням встановлюється значення $post_type, тобто даний параметр заданий завжди, якщо його примусово не встановити в false.

І тут є один нюанс. Якщо значення query_var додати через рядок запиту в URL, завжди буде видаватися сторінка 404. Тут потрібно прояснити. Скажімо, значення query_var одно review, то URL вашого сайту можна вказати будь-який з наступних форм:

http://example.com/?review=some-random-string

http://example.com/a-post-slug-here/?review=some-random-string

http://example.com/a-post-slug-here/?foo=bar&review=some-random-string

Ці посилання приведуть вас на сторінці 404. Про це я дізнався з власного гіркого досвіду. Коли я зіткнувся з цією проблемою я створив тему на WordPress core trac і повідомив про помилку. У мене пішло кілька тижнів на те, щоб розібратися з цією проблемою перед тим, як мені відповіла команда WordPress.

Прискорюємо налаштування користувацьких типів постів за допомогою плагінів

Тепер, коли ми розібралися з основами, варто сказати про те, що існує безліч плагінів для WordPress, з допомогою яких можна сильно спростити процес створення кастомних типів посад. Приклади (не всі):

Custom Post Type UI

Pods Framework

Custom Post Type Maker

Висновок

У цьому уроці ми дізналися, що таке користувальницькі типи постів і як їх створювати. Ця перша стаття з серії про кастомних типи посад в WordPress. У наступному уроці ми навчимося налаштовувати різні повідомлення в панелі адміністратора, дізнаємося, як реєструвати кастомні таксономії до певних типів постів і як додавати вкладку контекстної довідки на екран типу постів.