Зачем для пользовательского типа записи нужен параметр 'hierarchical'?
Я не до конца понимаю некоторые моменты, связанные с CPT (пользовательскими типами записей), и мне нужна помощь. Я вижу, что таксономии часто должны быть иерархическими, но не понимаю, как и когда это может быть применимо к пользовательскому типу записи?
Например, у меня есть CPT под названием 'projects'. Для этого типа записи зарегистрирована таксономия 'fields', в которой есть множество подкатегорий, таких как:
- 'Документальные'
- 'Документальные' > 'Личные проекты'
- 'Документальные' > 'Классика'
- 'Корпоративные'
- 'Корпоративные' > 'Цифровой маркетинг'
- и т.д.
Чтобы просмотреть проект в категории 'Документальные' > 'Классика', я использую такой URL: mydomain.com/field/classic/
У меня накопилось около 30 вопросов, но задам два самых важных:
- Зачем и как тип записи 'projects' может быть иерархическим?
- Возможно ли просматривать записи в категории 'classic' по такому URL: mydomain.com/projects/classic (mydomain.com/projects показывает все записи, но если углубиться дальше, все ломается)
Любая помощь будет ценна! Я потратил около 3 часов, экспериментируя и читая, но так и не разобрался!
Спасибо!
Ниже мой (сокращенный) код для справки:
function register_cpt_projects() {
$labels = array(
'name' => _x('Projects', 'projects'),
// остальные метки и т.д.
);
$args = array(
'labels' => $labels,
'hierarchical' => true,
'supports' => array('title', 'editor', 'author', 'thumbnail'),
'taxonomies' => array('field'),
'public' => true,
'show_ui' => true,
'show_in_menu' => true,
'show_in_nav_menus' => true,
'publicly_queryable' => true,
'exclude_from_search' => false,
'has_archive' => true,
'query_var' => true,
'can_export' => true,
'rewrite' => true,
'capability_type' => 'post'
);
register_post_type('projects', $args);
}
add_action('init', 'register_cpt_projects');
function create_projects_tax(){
register_taxonomy('field', 'projects', array(
'hierarchical' => true,
'label' => 'Fields'
));
}
add_action('init', 'create_projects_tax');

Когда у вас есть два объекта контента с похожим интерфейсом или общими свойствами, у вас хороший кандидат для иерархических типов записей.
Возьмем в качестве примера места (см. этот ответ):
- Азия
- Европа
- Германия
- Берлин
- Австрия
- Вена
- Германия
Каждое место имеет схожие метаданные: население, географические координаты, разговорные языки. Вы можете просто повторно использовать один и тот же интерфейс.
Кроме того, если вы создадите отдельный пользовательский тип записи для каждого вида места, вы столкнетесь с проблемой отсутствия таблицы связей между записями в WordPress.

Спасибо, это может быть полезно. Я прочитал другой пост и попытался разобраться, как установить CPT в качестве родительского, но не смог. Я не вижу выпадающего списка для выбора родителя на странице редактирования CPT 'projects'. Имеет ли значение, какой 'capability_type' у моего CPT? Он был 'post', но я изменил его на 'page' и проверил, но выпадающий список так и не появился. У меня уже есть несколько записей 'projects', так что там должно быть что-то, что можно выбрать в качестве родителя. Большое спасибо за помощь :)

Пользовательский тип записи требует иерархической настройки только если вы хотите, чтобы тип записи вел себя как страницы.
Если вы хотите иметь возможность выбирать родительский элемент и использовать метабокс порядка в меню, вам также нужно добавить 'page-attributes' в массив supports.
Аргумент hierarchical также позволяет вам обрабатывать иерархические типы записей иначе, чем другие, с помощью условного тега is_post_type_hierarchical()
. Он принимает объект записи, название типа записи или ID записи в качестве единственного параметра.
Возможно ли просматривать элементы в 'классическом' поле следующим образом: mydomain.com/projects/classic (mydomain.com/projects показывает все элементы, но переход дальше нарушает работу)
Вы можете использовать аргумент rewrite для определения того, как выглядят URL-адреса отдельных записей типа:
slug: Префикс, который вы хотите использовать для своих записей.
with_front: Должен ли ваш тип записи использовать базовый префикс из настроек постоянных ссылок.
'rewrite' => array( 'slug' => 'classic', 'with_front' => false ),
сделает URL-адреса для отдельных записей проектов такими:
yoursite.com/classic/post-name
Если вы хотите, чтобы URL-адреса архивов выглядели как: mydomain.com/projects/classic
, вам нужно применить аналогичные правила перезаписи к аргументам register_taxonomy.
Вам нужно будет установить slug для rewrite в projects, а with_front в false. Также стоит отметить, что массив rewrite в register_taxonomy поддерживает: 'hierarchical' - true или false разрешает иерархические URL-адреса
Это позволяет использовать полную иерархию для терминов таксономии в ваших URL-адресах:
