Зачем для пользовательского типа записи нужен параметр 'hierarchical'?

2 февр. 2012 г., 22:45:04
Просмотры: 17.1K
Голосов: 4

Я не до конца понимаю некоторые моменты, связанные с CPT (пользовательскими типами записей), и мне нужна помощь. Я вижу, что таксономии часто должны быть иерархическими, но не понимаю, как и когда это может быть применимо к пользовательскому типу записи?

Например, у меня есть CPT под названием 'projects'. Для этого типа записи зарегистрирована таксономия 'fields', в которой есть множество подкатегорий, таких как:

  • 'Документальные'
  • 'Документальные' > 'Личные проекты'
  • 'Документальные' > 'Классика'
  • 'Корпоративные'
  • 'Корпоративные' > 'Цифровой маркетинг'
  • и т.д.

Чтобы просмотреть проект в категории 'Документальные' > 'Классика', я использую такой URL: mydomain.com/field/classic/

У меня накопилось около 30 вопросов, но задам два самых важных:

  1. Зачем и как тип записи 'projects' может быть иерархическим?
  2. Возможно ли просматривать записи в категории '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');
0
Все ответы на вопрос 2
1

Когда у вас есть два объекта контента с похожим интерфейсом или общими свойствами, у вас хороший кандидат для иерархических типов записей.

Возьмем в качестве примера места (см. этот ответ):

  • Азия
  • Европа
    • Германия
      • Берлин
    • Австрия
      • Вена

Каждое место имеет схожие метаданные: население, географические координаты, разговорные языки. Вы можете просто повторно использовать один и тот же интерфейс.

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

2 февр. 2012 г. 23:07:21
Комментарии

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

Mere Development Mere Development
3 февр. 2012 г. 00:00:21
0

Пользовательский тип записи требует иерархической настройки только если вы хотите, чтобы тип записи вел себя как страницы.

Если вы хотите иметь возможность выбирать родительский элемент и использовать метабокс порядка в меню, вам также нужно добавить '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-адресах:

3 февр. 2012 г. 01:33:45