Більшість користувачів WordPress знайомі з такими елементами системи, як мітки і категорії, а також з тим, як їх використовувати для організації записів у блозі. Якщо ви використовуєте користувальницькі типи записів WordPress, вам, можливо, доводилося організовувати їх за категоріями і мітках.
Категорії і мітки — це приклади класифікацій, і WordPress насправді дозволяє створювати стільки індивідуальних таксономій, скільки ви захочете. Ці користувальницькі таксономії працюють як категорії або мітки, але окремо від них.
У цій статті ми будемо говорити про користувальницьких таксономиях і те, як їх створювати. Ми також розглянемо, які файли шаблонів теми WordPress пов’язані з вбудованими архівами та користувацькими класифікаціями, а також деякі передові методи налаштування архівів таксономії.
Термінологія
Перш ніж продовжити, давайте розберемося з термінами. Таксономії WordPress — це тип вмісту, який використовується в основному для організації будь-якого іншого типу контенту.
З двома вбудованими типами таксономій знайомі всі — це категорії і мітки (теги). Ми називаємо їх «теги«, але, якщо бути точним, то ми повинні використовувати визначення «термін«, а не «тег» таксономії. Однак у користувальницьких таксономиях ми, як правило, називаємо елементи «термінами» таксономії.
Категорії та теги представляють два типи таксономії: ієрархічний і не ієрархічний. Ієрархічні таксономії, такі як категорії, можуть мати підпорядковані зв’язку між термінами таксономії. Наприклад, у вашому блозі може бути категорія «фільми«, яка має кілька дочірніх категорій, з назвами на кшталт «іноземні» і «вітчизняні«.
Користувальницькі таксономії можуть також бути ієрархічними, як категорії, або не ієрархічними, як теги:
«Ієрархія шаблонів WordPress«
Архів таксономії — це список записів таксономії, який автоматично генерується WordPress. Наприклад, це може бути список сторінок, який ви бачите, коли натискаєте на посилання категорії, в ньому ви можете бачити всі записи цієї категорії. Ми займаємося зміною поведінки цих сторінок та дізнаємося, які файли шаблонів генерують їх.
Як працюють архіви міток, категорій і таксономій
Для кожної категорії, мітки і користувальницької таксономії WordPress автоматично генерує архів, в якому у зворотному хронологічному порядку перераховані всі записи, пов’язані з цією таксономією.
Добре, якщо у своєму блозі ви організуєте записи по категоріях і мітках. Якщо ж у вас є складна система організації записів користувацьких типів за користувальницьким таксономиям, то її важко налаштувати ідеально. Ми розглянемо деякі способи зміни цих архівів.
Для цього в першу чергу нам потрібно знати, які файли нашої теми використовуються для виведення архіву. Різні теми мають різні файли шаблонів, але всі теми містять шаблон index.php. Шаблон index.php використовується для відображення вмісту сайту, за винятком тих випадків, коли в ієрархії шаблонів існує шаблон вищого порядку.
Ієрархія шаблонів WordPress — це система, яка визначає, який файл шаблону використовується для відображення певного контенту. Ми коротенько розглянемо ієрархію шаблонів категорій, тегів і користувальницьких таксономій.
Більшість тем містять шаблон archive.php, який використовується для архівів міток (тегів) і категорій, а також архівів по даті і по автору. Ви можете додати окремий файл шаблону для обробки архівів категорій і міток. Ці шаблони будуть називатися category.php або tag.php, відповідно.
Крім того, ви можете створювати шаблони для окремих тегів або категорій, за допомогою ID або slug категорії або тега. Наприклад, тег з ідентифікатором 7 буде використовувати шаблон tag-7.php, якщо він існує, а не tag.php або archive.php. Тег з slug «avocado» буде відображатися за допомогою шаблону tag-avocado.php.
Тут слід враховувати один нюанс — slug шаблону перевизначає порядок ідентифікатора шаблону. Так, якщо тег з slug «avocado» мав ідентифікатор 7, то переважно буде використовуватися шаблон tag-avocado.php, якщо він існує, а не tag-7.php.
Порядок ієрархії шаблонів користувача таксономії трохи відрізняється від загального порядку, тому що для всіх класифікацій існують окремі шаблони, для конкретних класифікацій і для конкретних умов конкретної таксономії.
Отже, уявіть собі, що у вас є дві таксономії, «фрукти» і «овочі«, і в таксономії «фрукти» існують два терміна, «яблука» і «апельсини«.
У таксономії «овочі» у свою чергу також існують два терміни: «морква» і «селера«. Давайте додамо в тему нашого сайту три шаблону: taxonomy.php, taxonomy-fruits.php і taxonomy-vegetables-carrots.php.
Для термінів таксономії «фрукти» всі архіви будуть виводитися з допомогою шаблону taxonomy-fruits.php, тому що окремих шаблонів для конкретних термінів не передбачено.
У той же час, термін «морква» в архіві таксономії «овочі» буде виводитися за допомогою шаблону taxonomy-vegetables-carrots.php. Так як окремого шаблону taxonomy-vegetables.php не існує, всі інші терміни таксономії «овочі» будуть виводитися через шаблон taxonomy.php.
Використання тегів умов
Хоча ви можете додати будь-який з користувацьких шаблонів, перерахованих вище, і створити абсолютно унікальне подання для будь-якої категорії, тега, користувача або терміна таксономії користувача таксономії, іноді все, що вам потрібно, це зробити одне або два невеликі зміни.
Справді, нам слід прагнути до того, щоб не створювати багато шаблонів, тому що їх потрібно буде налаштовувати кожен раз, коли ми вносимо загальні зміни в основну HTML-розмітку, використовувану для кожного шаблону теми.
Якщо мені потрібен шаблон, який радикально відрізняється від шаблону теми archive.phpя, як правило, використовую додавання умов archive.php.
WordPress надає функції умов для визначення того, що відображається в категорії архіві міток або таксономії.
Щоб визначити, чи застосовується в даний час архів категорії для виведення контенту, ви можете використовувати функцію is_category() для категорій, is_tag() для тегів і is_tax() для таксономій. is_tag() і is_category() можуть перевіряти конкретні категорії або мітки з slug або ID.
Наприклад:
Для таксономій, функція is_tax() може використовуватися для перевірки будь таксономії (за винятком категорій і тегів), конкретної таксономії або конкретного терміна таксономії.
Наприклад:
Створення користувальницької таксономії
Додавання користувача таксономії можна здійснити одним з трьох способів: складання коду вручну у відповідності з інструкціями Кодексу, що я не рекомендую робити; генерація коду, з використанням GenerateWP; або з допомогою плагінів для створення користувацьких типів контенту, таких як Pods або Types.
Плагіни для користувацьких типів контенту дозволяють створювати користувальницькі таксономії і користувальницькі типи записів, використовуючи механіку WordPress без необхідності писати код самому.
Їх використання — це один з найпростіших способів додати користувача таксономію і застосувати принцип фреймворку для роботи з користувацькими типами вмісту.
Якщо ви виберете один з перших двох варіантів, а не плагін, то вам потрібно буде додати або код у файл functions.php теми, або у власний плагін. Я настійно рекомендую створити власний плагін, а не додавати код functions.php. Навіть якщо ви ніколи раніше не створювали плагін, я рекомендую вам зробити це.
Тому що при додаванні коду functions.php таксономія буде працювати, однак при перемиканні теми (скажімо, тому що ви захочете використовувати нову тему або для усунення неполадок), таксономії будуть відключені.
Якщо ви захочете написати власний код таксономії, слідуючи вказівкам Кодексу, або створити його за допомогою GenerateWP, просто вставте його в текстовий файл і додайте в самому верху один рядок, і ви отримаєте власний плагін. Завантажується і встановлюється він, як і будь-який інший плагін.
Єдиною рядком, яку ви повинні додати, щоб створити власний плагін, є: /* Plugin name: Custom Taxonomy */.
Нижче наводиться код плагіна, який реєструє користувача таксономію «vegetables». Я створив її за допомогою GenerateWP, тому що це значно простіше і набагато менше ймовірність помилок, ніж, якби я робив це вручну:
_x( ‘Vegetables’, ‘Taxonomy General Name’, ‘text_domain’ ),
‘singular_name’ => _x( ‘Vegetable’, ‘Taxonomy Singular Name’, ‘text_domain’ ),
‘menu_name’ => __( ‘Taxonomy’, ‘text_domain’ ),
‘all_Veggies’ => __( ‘All Veggies’, ‘text_domain’ ),
‘parent_Veggie’ => __( ‘Parent Veggie’, ‘text_domain’ ),
‘parent_Veggie_colon’ => __( ‘Parent Veggie:’, ‘text_domain’ ),
‘new_Veggie_name’ => __( ‘New Veggie name’, ‘text_domain’ ),
‘add_new_Veggie’ => __( ‘Add new Veggie’, ‘text_domain’ ),
‘edit_Veggie’ => __( ‘Edit Veggie’, ‘text_domain’ ),
‘update_Veggie’ => __( ‘Update Veggie’, ‘text_domain’ ),
‘separate_Veggies_with_commas’ => __( ‘Separate Veggies with commas’, ‘text_domain’ ),
‘search_Veggies’ => __( ‘Search Veggies’, ‘text_domain’ ),
‘add_or_remove_Veggies’ => __( ‘Add or remove Veggies’, ‘text_domain’ ),
‘choose_from_most_used’ => __( ‘Choose from the most used Veggies’, ‘text_domain’ ),
‘not_found’ => __( ‘Not Found’, ‘text_domain’ ),
);
$args = array(
‘labels’ => $labels,
‘hierarchical’ => false,
‘public’ => true,
‘show_ui’ => true,
‘show_admin_column’ => true,
‘show_in_nav_menus’ => true,
‘show_tagcloud’ => false,
);
register_taxonomy( ‘vegetable’, array( ‘post’ ), $args );
}
// Підключення до дії ‘init’
add_action( ‘init’, ‘slug_veggies_tax’, 0 );
}
?>
Між іншим, в GenerateWP я створив цей код менш ніж за дві хвилини! Відмінний сервіс, тому писати код вручну не має сенсу, цей сайт може автоматично згенерувати код для вас.
Щоб зробити процес ще простіше, можна використовувати плагін Pluginception, який створить порожній плагін, а потім вставити в нього код з GenerateWP з допомогою редактора плагінів WordPress.
Використання WP_QUERY користувача таксономиях
Після того, як ви додали користувача таксономію, ви можете запитати записи по термінам цієї таксономії. Для цього ми можемо використовувати запити таксономії через WP_QUERY.
Запити таксономії можуть бути і дуже простими, і досить складними. Прикладом найпростішого запиту є запит всіх записів з певним терміном. Наприклад, якщо у вас є тип записів під назвою «лицар» і пов’язана з ним користувацька таксономія під назвою «level», ви можете отримати список всіх лицарів-магістрів джедаїв наступним чином:
‘jedi’,
‘level’ => ‘master’
);
$query = new WP_Query( $args );
?>
Якщо ви додали другу користувача таксономію під назвою «era», ви можете вибрати всіх джедаїв Старої Республіки:
‘jedi’,
‘level’ => ‘master’,
‘era’ => ‘old-republic’,
);
$query = new WP_Query( $args );
?>
Ми також можемо зробити більш складні порівняння з використанням повного tax_query. Аргументи tax_query дозволяють здійснювати пошук по ID замість slug (як ми робили раніше) і шукати більш ніж по одному терміну.
Вони також дозволяють об’єднати кілька запитів таксономії і встановити взаємозв’язок між ними. Крім того, ми навіть можемо використовувати оператори SQL, такі як NOT IN, щоб виключити умови.
Можливості нескінченні. Для отримання додаткової інформації по «Class Reference/WP_Query» ознайомтеся з розділом «Параметри таксономії» сторінки Кодексу.
За допомогою наведеного нижче фрагмента коду здійснюється пошук записів типу «джедаїв», щоб визначити лицарів-джедаїв і магістрів, які не відносяться до епохи Старої Республіки:
‘jedi’,
‘tax_query’ => array(
‘relation’ => ‘AND’,
array(
‘taxonomy’ => ‘level’,
‘field’ => ‘slug’,
‘terms’ => array( ‘master’, ‘knight’ )
),
array(
‘taxonomy’ => ‘era’,
‘field’ => ‘slug’,
‘terms’ => array( ‘old-republic’ ),
‘operator’ => ‘NOT IN’
)
)
);
$query = new WP_Query( $args );
?>
Користувацька настройка архівів таксономії
Досі ми розглядали, як працюють таксономії, теги і категорії за замовчуванням, а також створювати власні таксономії. Якщо поведінка за умовчанням не відповідає вашим завданням, ви завжди можете його змінити.
Зараз ми розглянемо можливості зміни вбудованого функціоналу WordPress. Це буде корисно для тих з вас, хто використовує WordPress не як блог-платформу, а як систему управління контентом, для якої часто потрібні користувальницькі таксономії.
Знайомство з pre_get_posts
Перед виведенням будь-яких записів через цикл WordPress, система автоматично витягує користувачеві запису у відповідності зі сторінкою, на якій вони знаходяться. Робиться це з допомогою класу WP_QUERY. Наприклад, на головній сторінці блогу виводяться останні записи. В архіві таксономії, користувачеві витягуються останні записи таксономії.
Щоб змінити цей запит, ви можете перед витяганням записів використовувати фільтр pre_get_posts. Цей фільтр уточнює об’єкт запиту після того, як він встановлений, але перед тим, як він безпосередньо використаний для отримання записів.
Це означає, що ви можете змінити запит з використанням методів класу перед запуском основного циклу WordPress. Якщо це звучить не зовсім зрозуміло для вас, не хвилюйтеся — у наступних декількох розділах цієї статті я наведу практичні приклади того, як це працює.
Додавання користувацьких типів записів в категорії або архіви міток
Величезна перевага зміни об’єкта WP_QUERY з допомогою pre_get_posts полягає в тому, що ми можемо додати записи типу в архів категорії.
За замовчуванням, користувацькі типи записів не включені в цей запит. Якщо ми задаємо аргументи, які передаються в WP_QUERY і хочемо включити в нього як стандартні запису, так і записи типу «джедаїв», наш аргумент повинен виглядати наступним чином:
array(
‘post’,
‘jedi’
)
);
?>
У функцію зворотного виклику для фільтра pre_get_posts ми повинні передати аналогічний аргумент. Проблема полягає в тому, що об’єкт WP_QUERY вже існує, тому ми не можемо передати у нього аргумент так, як ми робимо, коли створюється екземпляр класу. Замість цього ми використовуємо метод класу set(), що дозволяє нам змінювати будь-який з аргументів після того, як клас був створений.
У наведеному нижче фрагменті коду ми використовуємо set(), щоб змінити аргумент post_type зі значення за замовчуванням, яке використовує записи, на масив типів записів, у тому числі запису і наш користувацький тип записів «джедаїв».
Зверніть увагу, що ми використовуємо тег умови is_category() таким чином, щоб зміни відбувалися тільки тоді, коли виводяться архіви категорій:
is_category() && $query->is_main_query() ) {
$query->set( ‘post_type’,
array(
‘post’,
‘jedi’
)
);
}
return $query;
}
?>
Параметр цієї функції $query є об’єкт WP_QUERY до того, як він використовується для заповнення основного циклу.
Так як сторінка може містити кілька циклів, наприклад тих, які використовуються віджетами, ми застосовуємо функцію умови is_main_query(), щоб зробити так, щоб це впливало тільки на основний цикл, і не впливало на будь-які вторинні цикли сторінки.
Створення категорії або ієрархічної таксономії
Ієрархії архівів
За замовчуванням архіви категорій та інших ієрархічних класифікацій працюють, як і будь-який інший архів таксономії: вони виводять всі записи в цій категорії чи з цим терміном таксономії. Щоб вивести тільки батьківські терміни і виключити дочірні, ви повинні знову використовувати фільтр pre_get_posts.
Так само, як при створенні власного WP_QUERY для записів таксономії, WP_QUERY основного циклу використовує для отримання записів таксономії аргументи tax_query.
tax_query має аргумент include_children, для якого за умовчанням встановлено значення 1 або true. Змінивши його на 0 або false, ми можемо вилучити з архіву запису з дочірніми термінами:
tax_query->queries;
$tax_query[‘include_children’] = 0;
$query->set( ‘tax_query’, $tax_query );
}
}
?>
Результат виглядає в принципі прийнятно, але мають місце кілька серйозних недоліків. Це нормально, тому що коли ми розберемося з цими недоліками, це буде перший крок до створення чогось реально крутого.
Перша і найбільша проблема полягає в тому, що результат не є сторінкою архіву, на якій виводяться дочірні терміни; це все ще запис з материнським терміном. Інша проблема полягає в тому, що у нас немає задовільного способу перейти до архіву дочірнього терміна.
Можна вирішити це, поєднавши приводиться раніше фільтр pre_get_post з модифікованим шаблоном архіву категорії або таксономії. Ми розглядали раніше, як визначити, який шаблон використовується для виведення архіву категорії або користувальницьких таксономій.
Крім того, майте на увазі, що ви завжди можете обернути вносяться зміни в теги умов, такі як is_category() або is_tax(), але дуже скоро це може призвести до захаращення коду; тому більш логічно буде зробити копію файлу archive.php і видалити непотрібний код.
На першому етапі ми укладаємо всі елементи всередину елемента, який буде перевіряти, чи існують у поточного терміна таксономії дочірні терміни. Якщо це не так, то ми не хочемо виводити зовсім нічого. Ми використовуємо get_term_children(), який повертає порожній масив, якщо поточний термін не має підпорядкованих елементів, що ми можемо перевірити за допомогою !empty().
Щоб виконати все це для будь таксономії, яка може виводитися, ми повинні отримати поточну таксономію і термін таксономії з масиву query_vars глобального об’єкта $wp_query. slug таксономії міститься в ключі таксономії, а slug терміна — в ключі tax.
Для використання get_term_children(), нам потрібен ID терміна. ID не міститься в query_vars, але щоб одержати його, ми можемо передати slug в get_term_by().
Ось як ми отримуємо змінні всю потрібну нам інформацію:
query_vars[‘taxonomy’];
$term = $wp_query->query_vars[‘tax’];
$term_id = get_term_by( ‘slug’, $term $taxonomy );
$term_id = $term_id->term_id;
$terms = get_term_children( $term_id, $taxonomy );
?>
Ми продовжуємо обробку тільки в тому випадку, якщо $terms не є порожнім масивом. Щоб перевірити, чи не є він порожнім, ми спочатку повторно заповнюємо терміни з допомогою get_terms(). Це необхідно, тому що get_term_children повертає масив ідентифікаторів.
А нам потрібні ідентифікатори та імена, які містяться в об’єкті, повернутого get_terms(). Ми можемо пропустити цей об’єкт через цикл і вивести імена у вигляді посилань. Посилання можна згенерувати, передавши ідентифікатори термінів у get_term_link().
Ось повний код:
query_vars[‘taxonomy’];
$term = $wp_query->query_vars[‘tax’];
$term_id = get_term_by( ‘slug’, $term $taxonomy );
$term_id = $term_id->term_id;
$terms = get_term_children( $term_id, $taxonomy );
if ( !empty( $terms ) ) {
$terms = get_terms( $taxonomy, array( ‘child_of’ => $term_id ) );
echo ‘
- ‘;
- term_id.'»>’.$term->name.’
foreach ( $terms as $term ) {
echo ‘
‘;
}
echo ‘
‘;
?>
Створення власної цільової сторінки таксономії архіву
Якщо ієрархічна класифікація не містить батьківських термінів верхнього рівня, то стандартна система архіву таксономії буде для вас марною. Замість цього ви хочете вивести посилання на нижні рівні ієрархії.
В цьому випадку можна створити власну цільову сторінку термінів. Ми знову використовуємо query_vars, щоб визначити, чи перебуває користувач на першій сторінці архіву таксономії; якщо так, то ми використовуємо фільтр taxonomy_archive, щоб включити окремий шаблон:
query_vars[‘paged’];
if ( $page = 0 ) {
$template = get_stylesheet_directory(). ‘/taxonomy-page-one.php’;
}
}
return $template;
}
?>
Цей зворотний виклик спочатку перевіряє, чи дійсно користувач знаходиться в таксономії, яку ми хочемо зробити цільової. Ми можемо провести перевірку за всіма таксономиям, використовуючи is_tax().
Потім, отримуємо поточну сторінку, використовуючи змінну query_var з ім’ям paged, і якщо користувач знаходиться на першій сторінці архіву, то йому повертається адресу нового файлу шаблону. Якщо ні, повертається файл шаблону за замовчуванням.
Що ви вкладете у цей окремий шаблон, залежить тільки від вас. Ви можете створити список термінів, використовуючи код, наведений вище. Насправді ви можете вивести що завгодно — наприклад, більш детальну інформацію про термінах таксономії або посилання на конкретні записи.
Висновок
Витративши деякий час, ви можете налаштувати базову архітектуру WordPress, який все ще заточений під своє початкове призначення — блог-платформи, під завдання майже будь-якого сайту або веб-додатки.
Використання користувальницьких таксономій для організації контенту у відповідності з вашими потребами допоможе вам у розвитку багатьох ваших проектів на WordPress.
Сподіваюся, ця стаття посприяє тому, щоб ви повністю задіяли у своїй роботі потужні можливості, які WordPress надає розробникам.
Переклад статті «Customizing WordPress Archives For Categories, Tags And Other Taxonomies» був підготовлений дружною командою проекту Сайтостроение від А до Я.
