У цій статті ми будемо говорити про користувальницьких таксономії і тому, як їх створювати. Ми також розглянемо, які файли шаблонів теми WordPress пов'язані з вбудованими архівами і призначеними для користувача таксономії, а також деякі передові методи настройки архівів таксономії.
Термінологія
Перш ніж продовжити, давайте розберемося з термінами. Таксономії WordPress - це тип контенту, який використовується в основному для організації будь-якого іншого типу контенту.
![Призначена для користувача настройка архівів wordpress для категорій, міток і інших таксономій, cms і движки (призначена для користувача) Призначена для користувача настройка архівів wordpress для категорій, міток і інших таксономій, cms і движки](https://images-on-off.com/images/171/polzovatelskayanastroykaarxivovwordpress-7fae6973.png)
"Ієрархія шаблонів WordPress"
Для цього в першу чергу нам потрібно знати, які файли нашої теми використовуються для виведення архіву. Різні теми мають різні файли шаблонів, але все теми містять шаблон index.php. Шаблон index.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.
Створення користувальницької таксономії
Додавання користувальницької таксономії можна здійснити одним з трьох способів: складання коду вручну відповідно до інструкцій Кодексу, що я не рекомендую робити; генерація коду, з використанням GenerateWP; або за допомогою плагінів для створення користувацьких типів контенту, таких як Pods або Types.
Модулі для користувача типів контенту дозволяють створювати призначені для користувача таксономії і призначені для користувача типи записів, використовуючи механіку WordPress без необхідності писати код самому.
Їх використання - це один з найпростіших способів додати призначену для користувача таксономию і застосувати принцип фреймворка для роботи з одними типами контенту.
Якщо ви виберете один з перших двох варіантів, а не плагін, то вам потрібно буде додати код або в файл functions.php теми, або в власний плагін. Я настійно рекомендую створити власний плагін, а не додавати код в functions.php. Навіть якщо ви ніколи раніше не створювали плагін, я рекомендую вам зробити це.
Тому що при додаванні коду в functions.php таксономія буде працювати, однак при перемиканні теми (скажімо, бо ви захочете використовувати нову тему або для усунення неполадок), таксономії будуть відключені.
Якщо ви захочете написати власний код таксономії, виконуючи вказівки Кодексу, або створити його за допомогою GenerateWP. просто вставте його в текстовий файл і додайте в самому верху один рядок, і ви отримаєте власний плагін. Завантажується і встановлюється він, як і будь-який інший плагін.
Єдиною рядком, яку ви повинні додати, щоб створити користувальницький плагін, є: / * Plugin name: Custom Taxonomy * /.
Нижче наводиться код плагіна, який реєструє призначену для користувача таксономию "vegetables". Я створив її за допомогою GenerateWP. тому що це значно простіше і набагато менше ймовірність помилок, ніж, якби я робив це вручну:
Між іншим, в GenerateWP я створив цей код менш ніж за дві хвилини! Відмінний сервіс, тому писати код вручну не має сенсу, цей сайт може автоматично згенерувати код для вас.
Використання WP_QUERY в призначених для користувача таксономії
Після того, як ви додали призначену для користувача таксономию, ви можете запросити записи по термінам цієї таксономії. Для цього ми можемо використовувати запити таксономії через WP_QUERY.
Запити таксономії можуть бути і дуже простими, і досить складними. Прикладом найпростішого запиту є запит всіх записів з певним терміном. Наприклад, якщо у вас є тип записів під назвою "jedi" і пов'язана з ним призначена для користувача таксономія під назвою "level", ви можете отримати список всіх лицарів-магістрів джедаїв наступним чином:
Якщо ви додали другу призначену для користувача таксономию під назвою "era", ви можете вибрати всіх джедаїв Старої Республіки:
Ми також можемо зробити більш складні порівняння з використанням повного tax_query. Аргументи tax_query дозволяють здійснювати пошук по ID замість slug (як ми робили раніше) і шукати більш ніж по одному терміну.
Вони також дозволяють об'єднати кілька запитів таксономії і встановити взаємозв'язок між ними. Крім того, ми можемо навіть використовувати оператори SQL. такі як NOT IN. щоб виключити умови.
Можливості нескінченні. Для отримання додаткової інформації по "Class Reference / WP_Query" ознайомтеся з розділом "Параметри таксономії" сторінки Кодексу.
За допомогою наведеного нижче фрагмента коду здійснюється пошук записів типу "jedi", щоб визначити лицарів-джедаїв і магістрів, які не належать до епохи Старої Республіки:
Призначена для користувача настройка архівів таксономії
Зараз ми розглянемо можливості зміни вбудованого функціоналу WordPress. Це буде корисно для тих з вас, хто використовує WordPress не як блог-платформу, а як систему управління контентом, для якої часто потрібні для користувача таксономії.
Перед висновком будь-яких записів через цикл WordPress. система автоматично витягує користувачеві записи відповідно до сторінкою, на якій вони знаходяться. Робиться це за допомогою класу WP_QUERY. Наприклад, на головній сторінці блогу виводяться останні записи. В архіві таксономії, користувачеві витягуються останні записи таксономії.
Це означає, що ви можете змінити запит з використанням методів класу перед запуском основного циклу WordPress. Якщо це звучить не зовсім зрозуміло для вас, не хвилюйтеся - в наступних декількох розділах цієї статті я приведу практичні приклади того, як це працює.
За замовчуванням, призначені для користувача типи записів не включені в цей запит. Якщо ми ставимо аргументи, які передаються в WP_QUERY і хочемо включити в нього як стандартні записи, так і записи користувача типу "jedi", наш аргумент повинен виглядати наступним чином:
У наведеному нижче фрагменті коду ми використовуємо set (). щоб змінити аргумент post_type зі значення за замовчуванням, яке використовує записи, на масив типів записів, в тому числі записи і наш користувальницький тип записів "jedi".
Параметр цієї функції $ query є об'єкт WP_QUERY до того, як він задіюється для заповнення основного циклу.
Так як документ може містити кілька циклів, наприклад тих, які використовуються віджетами, ми застосовуємо функцію умови is_main_query (). щоб зробити так, щоб це впливало лише на основний цикл, і не впливало на будь-які вторинні цикли сторінки.
ієрархії архівів
Так само, як при створенні власного WP_QUERY для записів таксономії, WP_QUERY основного циклу використовує для отримання записів таксономії аргументи tax_query.
tax_query має аргумент include_children. для якого за замовчуванням встановлено значення 1 або true. Змінивши його на 0 або false. ми можемо виключити з архіву записи з дочірніми термінами:
Результат виглядає в принципі прийнятно, але мають місце кілька серйозних недоліків. Це нормально, тому що коли ми розберемося з цими недоліками, це буде перший крок до створення чогось реально крутого.
Перша і найбільша проблема полягає в тому, що результат не є сторінкою архіву, на якій виводяться дочірні терміни; це все ще запис з материнським терміном. Інша проблема полягає в тому, що у нас немає задовільного способу перейти до архіву дочірнього терміна.
Крім того, майте на увазі, що ви завжди можете обернути вносяться зміни в теги умов, такі як 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 ().
Ось як ми отримуємо в змінні всю потрібну нам інформацію:
Ми продовжуємо обробку тільки в тому випадку, якщо $ terms не є порожнім масивом. Щоб перевірити, чи не є він порожнім, ми спочатку повторно заповнюємо терміни за допомогою get_terms (). Це необхідно, тому що get_term_children повертає тільки масив ідентифікаторів.
А нам потрібні ідентифікатори та імена, які містяться в об'єкті, повернутому get_terms (). Ми можемо пропустити цей об'єкт через цикл і вивести імена у вигляді посилань. Посилання можна згенерувати, передавши ідентифікатори термінів в get_term_link ().
Створення власної цільової сторінки таксономії архіву
Якщо ієрархічна таксономія не містить батьківських термінів верхнього рівня, то стандартна система архіву таксономії буде для вас марною. Замість цього ви хочете вивести посилання на нижні рівні ієрархії.
В цьому випадку можна створити власну цільову сторінку термінів. Ми знову використовуємо query_vars. щоб визначити, чи знаходиться користувач на першій сторінці архіву таксономії; якщо так, то ми використовуємо фільтр taxonomy_archive. щоб включити окремий шаблон:
Цей зворотний виклик спочатку перевіряє, чи дійсно користувач знаходиться в таксономії, яку ми хочемо зробити цільової. Ми можемо провести перевірку за всіма таксономиям, використовуючи is_tax ().
Що ви вкладете в цей окремий шаблон, залежить тільки від вас. Ви можете створити список термінів, використовуючи код, наведений вище. Насправді ви можете вивести що завгодно - наприклад, більш детальну інформацію про терміни таксономії або посилання на конкретні записи.
висновок
Витративши деякий час, ви можете налаштувати базову архітектуру WordPress. який все ще заточений під своє початкове призначення - блог-платформи, під завдання майже будь-якого сайту або веб-додатки.
Використання призначених для користувача таксономій для організації контенту відповідно до ваших потреб допоможе вам у розвитку багатьох ваших проектів на WordPress.
Переклад статті «Customizing WordPress Archives For Categories, Tags And Other Taxonomies» був підготовлений дружною командою проекту Сайтобудування від А до Я.