No Image

Что такое таксономия wordpress

СОДЕРЖАНИЕ
0 просмотров
11 марта 2020

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

Начну с того, что таксономии нужны для группировки постов.

Каким образом? Ну возьмём к примеру хэштеги в инстаграм — когда вы постите фото и присваиваете ему теги — это как раз и есть та самая группировка, о которой я говорю. По умолчанию WordPress тоже поддерживает теги для постов, а ещё рубрики. И их можно объединить одним словом — таксономии.

В WP есть стандартные таксономии, а также те, которые разработчики и пользователи создают сами.

1. Стандартные таксономии в WordPress

Рубрики и метки

Что-то мне подсказывает, что если вы читаете этот пост, то вы уже представляете, что такое рубрики (категории) и метки (теги), что у рубрик есть иерархия, у меток нет и так далее.

А теперь мне нужно донести одну важную мысль.

В WordPress есть своя группа функций для работы с рубриками и отдельная группа функций для работы с метками. Наверняка с какими-то из них вы уже знакомы.

Чуть выше мы с вами определили, что и рубрики и метки являются таксономиями, а это значит, что при работе как с теми, так и с другими вы можете спокойно использовать функции таксономий. Я например так и делаю.

Рубрики ссылок

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

Если вы недавно установили WP, то вы не найдёте их у себя в админке. Дело в том, что с версии 3.5 ссылки по умолчанию сделали отключенными. Но не удалили — вставьте следующий код в файл functions.php вашей темы и ссылки вновь появятся у вас в админке. Вполне возможно, что вы найдете им применение.

Форматы постов

Форматы на самом деле с трудом можно назвать таксономией, но фактически это так. На моём блоге им посвящён отдельный пост.

2. Пользовательские таксономии

И вот в один прекрасный день наступает момент, когда нам начинает не хватать стандартных рубрик и меток для группировки записей…

Чуть подробнее про регистрацию таксономии

Техническую сторону регистрации я подробно описал в статье про функцию register_taxonomy(). Сейчас же мы рассмотрим несколько моментов.

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

Пример: вы зарегистрировали тип записей — Автомобили, и их нужно группировать скажем по марке, стране и по объему двигателя (хотя объем лучше затолкать в произвольные поля).

Как присваивать таксономии к различным типам записей

Ну во-первых, если вы сами регали таксономию через код, то конечно же надо было сразу указать все типы записей, для которых будет использована группировка по этой таксономии.

Если же изменение параметров регистрирующей функции не в вашей власти (возьмем те же рубрики и метки), тогда вы можете и должны использовать register_taxonomy_for_object_type().

Допустим вы взяли и захотели, чтобы в рубрику можно было добавлять не только записи но и страницы! Тогда код будет следующим:

Другие примеры смотрите в описании функции, ссылку на которое я дал вам выше.

Вывод таксономий в виде списка

Вы знакомы с функцией wp_list_categories()? Если нет, то наверняка видели, как на блогах рубрики выводятся в столбик в виде списка (иногда еще справа в скобках указывается количество постов в рубрике).

Самое интересное, что функция wp_list_categories() позволяет выводить элементы любой таксономии, достаточно лишь указать название таксономии в параметрах функции.

Где же брать название таксономии?

  • Если таксономию создавали вы сами, то этот вопрос у вас не должен возникать.
  • Если же нет, то просто откройте страницу этой таксономии и посмотрите на ссылку в браузере:

Более сложный, но в то же время более удобный и настраиваемый вариант — функция get_terms(). Если бы мне предложили выбрать любимую функцию из кодекса, я бы выбрал её — она реально потрясающая.

Вывод постов из таксономии

Тут нам безусловно поможет WP_Query с параметром tax_query . Подробное описание и примеры смотрите здесь.

3. Плагины для работы с таксономиями

Сам я придерживаюсь мнения, что в данном случае лучше обойтись без лишних плагинов, тем не менее вот некоторые бесплатные варианты:

  • Simple Taxonomies by Yoast,
  • Pods,
  • Types.

Некоторые из функций для работы с таксономиями

Впервые познакомился с WordPress в 2009 году. С 2014 года меня можно встретить на WordCamp по всему миру — официальной конфе по WordPress, иногда там выступаю. Также периодически школа Epic Skills и LoftSchool приглашают меня вести у них уроки/вебинары.

Если вам нужна помощь с вашим сайтом или может даже разработка с нуля — пишите мне.

Что такое таксономии / пользовательские таксономии WordPress?

По сути таксономии — это способ группировки информации.

WordPress использует собственные встроенные таксономии категорий и тегов, чтобы обеспечить группировку типов контента и по умолчанию применяет их к типу контента posts . Эти таксономии состоят из одного или нескольких терминов, чьи названия, как правило, используются для группировки элементов.

Иногда вам вполне достаточно стандартных таксономий, в то время как иногда могут потребоваться дополнительные способы группировки контента, что вызвано вашими потребностями. Именно в таких случаях пользовательские таксономии могут оказаться исключительно полезными.

Пользовательские таксономии позволяют задавать собственные имена и структуру для организации записей. Вы можете создать новую таксономию под названием grade_ranking , которая будет обрабатывать ранжирование записей по шкале с такими значениями, как pass , credit , distinction и high distinction .

Стандартная информация для таксономий

При определении таксономии вам нужно указать, будет ли это таксономия hierarchical или non-hierarchial . Это задает то, как будет группироваться информация в вашей таксономии.

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

non-hierarchial (не иерархические) таксономии действуют как теги, где все термины принадлежат одному уровню.

Пользовательские таксономии позволяют вводить следующую информацию для каждого из терминов:

  • Имя: определяет имя, используемое для термина, оно показывается конечному пользователю. Применяется и к категориям, и к тегам;
  • Slug : определяет URL -адрес, используемый для термина ( как правило, состоит из символов нижнего регистра, разделенных тире ). Применяется и к категориям, и к тегам;
  • Родительский элемент: позволяет определить, является ли термин родительским элементом верхнего уровня или это дочерний термин. Относится только к иерархическим таксономиям, таким как категории;
  • Описание: краткое описание того, что содержит этот термин. Показывается на странице списка терминов ( когда вы кликаете по ссылке, чтобы просмотреть сам термин ).

Это все, что предоставляет WordPress в отношении ваших терминов.

Расширение таксономий

Хотя информации по умолчанию вам может оказаться достаточно, вы также можете сохранить дополнительную информацию, которую можно использовать в другом месте на своем сайте.

WordPress предоставляет ряд обращений ( hooks ), которые можно использовать для изменения панели администрирования таксономии, и которые помогают в процессе сохранения дополнительной информации.

В этой статье мы будем расширять таксономию по умолчанию category . Вы можете легко расширить и встроенные таксономии, и таксономии, которые вы создали сами, но для простоты мы будем изменять существующую таксономию.

С чего начнем?

WordPress предоставляет два основных способа, с помощью которых можно создать термины таксономий:

  • Создание через панель администрирования таксономий;
  • На лету при редактировании типа записи, который связан с таксономией.

Например, вы можете создать термин таксономии категории, такой как featured или sponsored , либо в меню администрирования категории ( определив имя, slug, описание и т.д. ), либо путем их создания непосредственно из панели редактирования записи или страницы ( с помощью мета-бокса категории, добавив новую категорию динамически ).

Читайте также:  Микроскоп digital blue qx5 программа

Поскольку мы хотим сохранить дополнительную информацию о наших терминах, мы будем использовать панель администрирования таксономии, так как таким способом добавлять, редактировать и удалять термины правильнее.

Что нужно изменить?

При работе с таксономией вы будете работать и с панелью редактирования, и с панелью добавления терминов. Соответственно эти панели предназначены для добавления нового термина и редактирования существующего. WordPress предоставляет ряд обращений, которые предназначены для того, чтобы помочь вам подключить определенный функционал, а также дать вам возможность просто изменить базовый функционал.

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

В этой статье мы будем добавлять дополнительные элементы формы, чтобы вы могли собрать больше информации о категориях. Мы настроим захват информации с помощью следующих элементов:

Это наиболее распространенные элементы форм, таким образом, вы получите лучшее представление о том, как можно расширить таксономию и сохранить дополнительную информацию.

Изменение панели добавления категории

Первое, что нам нужно будет изменить, это панель добавления категории. Через это меню вы, как правило, будете добавлять все ваши категории, и через него нужно будет сохранять дополнительную информацию.

Мы должны использовать обращение category_add_form_fields .

Обращение category_add_form_fields используется для добавления дополнительной информации в панель администрирования категории.

Это обращение принимает один аргумент, которым является имя самой таксономии. Оно позволяет добавить дополнительную информацию в панель администрирования категории, поэтому сначала нам нужно будет определить функцию, которая выводит для нас несколько полей.

Следующий код должен быть добавлен в файл functions.php вашей темы ( или другой файл, который вы используете для своего кода ):

Теперь, когда наша функция определена, все что нам нужно сделать, это подключить ее к обращению category_add_form_fields , и оно будет активировать функцию при выводе панели добавления категории. Мы будем делать это через вызов функции:

После этого в вашей панели администрирования категории должны появиться дополнительные поля, которые мы определили в нашей функции. Она должна выглядеть следующим образом:


В качестве дополнительного совета: когда вы определяете поля, которые должны быть добавлены в панель, вы, как правило, обертываете их в класс form-field , это гарантирует, что содержащиеся элементы ввода будут выводиться на всю ширину панели.

Как вы можете видеть в нашем примере, я оставил этот класс подключенным для всех элементов, кроме переключателя опций. Мы не хотим, чтобы чекбокс растягивался на всю ширину панели.

Кроме того, если вы добавите класс form-required , это обеспечит то, что данное поле станет обязательным для заполнения. Новый термин невозможно будет добавить, пока оно не заполнено.

Сохранение новой информации о категории

Теперь, когда мы изменили панель добавления категории, мы должны сохранить дополнительную информацию, чтобы позже использовать ее.

Нам нужно будет подключить функцию к другому обращению, чтобы вызвать действие сохранения. Это обращение create_category . Функция, которую мы создадим, будет обрабатывать сохранение информации нашего термина.

При сборе информации, которая будет напрямую записываться в базу данных WordPress , всегда нужно проверять безопасность данных. Мы можем использовать ‘sanitize_text_field($string)’ , чтобы проверить безопасность строк, убрать все теги, удалить разрывы строк, отступы и преобразовать значимые символы, такие, например, как :

sanitize_text_field отлично подходит для обеспечения безопасности этих значений. Тем не менее, здесь вы можете найти дополнительные функции для обработки различных типов данных .

Данная функция принимает один параметр, ID нового сохраняемого термина.

Имея этот ID , мы можем вызвать функцию get_term($term_id,$taxonomy_name) .

Эта функция принимает два параметра, ID самого термина и имя таксономии. Так как мы знаем идентификатор самого термина, а также то, что мы имеем дело с таксономией category , теперь мы можем получить доступ к объекту термина.

Мы собираем значение slug из термина объекта и сохраняем его. После этого мы собираем все четыре значения новых полей из объекта $_POST . Наконец мы вызываем другую функцию update_option($option_name,$option_value) .

Эта функция позволяет создавать новую запись в таблице опций WordPress , чтобы с ее помощью мы могли сохранить наше значение. Все, что нужно этой функции, это название новой опции и ее значение. Мы вызываем данную функцию четыре раза, по одному разу для каждого из новых полей.

Например, если мы создаем новую категорию под названием test, когда мы сохраняем информацию из текстового поля, имя опции будет term_category_textarea_test , когда сохраняем данные из поля выбора вариантов, имя будет — text_category_select_test и т.д. Мы добавляем для этих полей slug в конце имени, чтобы обеспечить уникальность значений ( так как все значения slug являются уникальными ).

Теперь нам нужно подключить эту функцию к обращению create_category :

Изменение панели редактирования категории

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

Для отображения наших дополнительных полей нам нужно будет подключиться к обращению category_edit_form_fields .

Обращение category_edit_form_fields используется для вывода дополнительных полей в панели редактирования категорий. Это обращение принимает одно значение — сам объект термина. Так как это обращение будет иметь доступ к самому объекту термина, нам будет очень просто собрать информацию.

Мы должны создать функцию, которая будет выводить дополнительные поля и предварительно заполнить их сохраненной ранее информацией. Поскольку у нас теперь есть доступ к объекту термина, это будет легко:

Эта функция использует свой предыдущий объект term для доступа к slug самого термина. С помощью этого slug , она ищет четыре сохраненных значения пользовательских полей, используя функцию get_option($option_name) .

Эта функция ищет опции с указанным именем и присваивает им значения. В нашем случае мы ищем четыре значения полей и присваиваем их переменным.

Большая часть этой функции выводит элементы нашей HTML -формы, они будут добавлены как табличные элементы. Для каждого из наших полей мы отображаем метки и элементы текстового поля, текстовой области, поля выбора вариантов или поля переключения опций.

Способ, с помощью которого мы предварительно заполняем наши пользовательские поля, отличается для каждого типа полей.
Вот что мы делаем:

  • Текстовое поле — для текстового поля мы назначаем значение непосредственно его атрибуту value , который будет предварительно заполняться сам собой;
  • Поле текстовой области — для текстовой области мы выводим ее значение непосредственно между тегами , вследствие чего значение выводится в элементе текстовой области;
  • Поле выбора вариантов — для выбора вариантов мы сначала создаем элемент выбора вариантов и все связанные с ним параметры. Мы добавляем для элемента выбора вариантов атрибут, который называется value , и заполняем его нашим сохраненным значением ( это очень похоже на то, как мы разобрались с текстовым полем ). Даже с учетом того, что мы выводим все возможные значения списком, нам все равно нужно определить, какой вариант в данный момент назначен. Поэтому мы перебираем каждый из возможных вариантов выбора в элементе и определяем, совпадает ли его значение, с тем значением, которое мы собрали ранее. Если так, то в данный момент он является выбранным вариантом. Мы используем оператор IF , и, если он определяет совпадение значения опции с атрибутом selected , то данный вариант используется браузером, как вариант по умолчанию;
  • Поле переключателя опций — для этого поля мы выводим опции непосредственно на страницу и определяем, соответствует ли их значение значению, сохраненному в базе данных. Если это так мы используем оператор IF для вывода в поле атрибута checked . Этот атрибут указывает браузеру принять эту опцию в качестве значения по умолчанию ( во многом это похоже на обработку вывода поля выбора вариантов, так как мы должны указать браузеру, какую опцию выводить ).
Читайте также:  Virtualbox увеличить размер диска vdi

Обеспечение корректности предварительного заполнения этих значений является критически важным, чтобы пользователь сделал правильный выбор при обновлении термина таксономии. Иначе данные могут быть несовместимы.

Все, что теперь нам осталось сделать, это подключить нашу новую функцию к обращению category_edit_form_fields , и тогда она будет выполняться, когда мы вызываем панель редактирования терминов:

После подключения этой функции ваш экран редактирования категории должен обновиться, и в нем появятся дополнительные поля и значения. Теперь он выглядит следующим образом:

Сохранение обновленной информации о категории

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

К счастью, у нас уже есть такая функция. Ранее мы создали функцию save_extra_taxonomy_fields($term_id) , которую мы использовали при добавлении нового термина в категорию.

Мы можем вызвать эту функцию при обновлении категории, подключив ее к другому обращению. Мы подключаем нашу функцию save_extra_taxonomy_fields($term_id) к обращению edit_category , и когда мы обновляем категорию, эта функция будет сохранять информацию:

Расширение пользовательских таксономий

Пользовательские таксономии могут быть расширены тем же образом, что и встроенные ( категории и теги ).

Единственное, что нужно будет изменить, это имена используемых обращений.

Для категорий вы должны использовать следующие обращения:

  • category_add_form_fields – добавление полей в панель добавления новой категории;
  • category_edit_form_fields – добавление полей в панель редактирования категорий;
  • create_category – используется, когда вы хотите сохранить новые термины категории;
  • edit_category – используется, когда вы хотите обновить термины категории.

Эти обращения соединяют вас с областями, которые необходимо отредактировать, что позволяет сохранять и извлекать дополнительную информацию.

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

  • $TAXONOMY_NAME_add_form_fields ;
  • $TAXONOMY_NAME_edit_form_fields ;
  • create_$TAXONOMY_NAME ;
  • edit_$TAXONOMY_NAME .

Например, если вы зарегистрировали собственную таксономию под названием members , ваши обращения будут называться:

  • members_add_form_fields ;
  • members_edit_form_fields ;
  • create_members ;
  • edit_members .

Вы должны следовать этой общей схеме и применять ее к вашим пользовательским таксономиям. Тогда у вас будет возможность редактировать эти панели и сохранить информацию, как вам нужно.

В заключение всего этого

Теперь, когда вы знаете, как сохранять дополнительную информацию ваших таксономий / терминов, вы можете расширить функционал WordPress , чтобы он больше подходил под ваши задачи.

Вы можете получить доступ к конкретным терминам с помощью get_term($term_name,$taxonomy_name) , а затем оттуда вы можете использовать slug , так как вы уже получили доступ к дополнительной информации, извлекаемой из таблицы опций WordPress .

Вы можете редактировать файлы своих дочерних тем и другие ресурсы, чтобы воспользоваться этой новой информацией. Я бы начал с редактирования файла category.php или tag.php , если вы изменили эти таксономии, чтобы подтянуть новую информацию.

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

Данная публикация представляет собой перевод статьи « Extending WordPress Taxonomies » , подготовленной дружной командой проекта Интернет-технологии.ру

Что такое таксономии в WordPress? Кто не знает, и тем кто думает, что знает о таксономиях все, будет полезно прочитать эту статью. Я подробно разберу что скрывается под этим странным словом, что оно значит в WordPress и как таксономии устроены. Думаю, в этом разборе что-то полезное найдет каждый.

Читайте также, как устроенны записи в WordPress
Читайте также, как устроенны метаполя в WordPress

Слово «Taxonomy» пришло к нам, как всегда, из греческого: taxis — расположение, nomos — закон, принцип. Т.е. Таксономия — это принцип расположения чего-либо. Для WordPress — это принцип расположения записей.

Образно, таксономии можно сравнить с папками на компьютере: куда складываются файлы. Заходим в папку, видим список файлов. В WordPress аналогично: заходим в таксономию (рубрику), видим список записей в ней.

Структура контента в WordPress очень простая: контент состоит из записей и таксономий, которые связывают эти записи — по сути, это все! К контенту также относятся комментарии и файлы, но и то и другое является частью записи. Есть еще пользователи, но это как бы и не контент, а отдельная сущность. Вот и получается, что таксономии связывают только записи.

Стоит обратить внимание, что в WordPress «Таксономия» — это только название, т.е. таксономии как таковой не существует — есть только запись о её существовании. А что-то реальное в таксономии — это её элементы. Например, возьмем таксономию «Рубрики» ( category ) — это только название — запись в переменной PHP, а реальные данные таксономии — это созданные рубрики — её элементы. Например, если не создавать ни одной рубрики, то условно можно сказать, что таксономии нет (она пуста) — в базе данных она нигде не записана, а существует лишь в переменных PHP, где указано название таксономии и её свойства (опции), причем создается такая переменная налету во время генерации страницы. Записи привязываются именно к элементам таксономии, а не к самой таксономии. Так как записи связаны не с таксономией, а с её элементами, то и вся последующая работа с таксономией — это работа с её элементами.

Элементы таксономии называются terms . Для краткости так и будем их называть — термины.

Выше я говорил, что при создании таксономии ей задаются свойства. Одно из самых важных свойств — это тип таксономии. Так, таксономии делятся на два типа:

Древовидные — например рубрики

  • Линейные (плоские) — например метки
  • Отличия. Элементы древовидных такс. могут быть родительскими и дочерними, т.е. одни элементы как бы вложены в другие. А элементы плоских такс. всегда сами по себе, т.е. все они находятся на одном уровне, а значит не зависят друг от друга.

    Схематически это выглядит как-то так:

    меню

    Базовые таксономии WordPress

    По умолчанию в WordPress существует пять таксономии:

    category — рубрики

    post_tag — метки

    post_format — скрытая таксономия. Термины этой таксономии — это форматы записей.

    nav_menu — скрытая таксономия. Термины этой таксономии — это созданные меню навигации, к ним прикрепляются записи (ссылки меню). Если в меню создается произвольная ссылка, то её данные помещаются в таблицу записей (wp_posts) с типом записи nav_menu_item , а запись прикрепляется к термину. Все опции ссылки (URL, анкор и т.д.) хранятся в метаполях записи. Тоже самое происходит, если в эту таксономию помещается элемент другой таксономии, например рубрика — также создается запись в таблице записей, а данные помещаются в метаполя записи. Система топорная и не очень практичная, зато независимая, хорошо расширяемая, а главное простая — в стиле WordPress.

  • link_category — разделы для ссылок, которые отключены в последних версиях. Подробнее о включении ссылок.
  • меню

    Создание своих таксономий

    Создается таксономия с помощью функции register_taxonomy() или соответствующего плагина, например, «Custom Post Type UI». При этом, как я уже говорил, в базу данных ничего не добавляется, а создается только описание таксономии и её свойств в глобальной переменной PHP и в правилах ЧПУ. Как только был создан хоть один элемент таксономии, в БД появляется запись о новом термине, а к нему уже можно прикрепить запись.

    При создании таксономии, ей можно указать самые разные свойства (опции), например:

    тип: древовидная или плоская.

    тип записи для которой создается такса, тогда при редактировании записи в админке появится блок, где можно добавить запись в таксономию (связать запись с термином). Например таким блоком является блок рубрик при редактировании записи.

    как будет выглядеть ссылка на элемент таксономии. Эта «хрень» называется ЧПУ (человеко-понятный УРЛ).

    Читайте также:  Как запустить командную строку в биосе

    можно создать скрытую таксономию, тогда её нигде не будет видно, в частности в админке, но её можно использовать как-то нестандартно, чтобы группировать записи или делать что-то еще. Так например, плагины галерей связывают галереи или отдельные картинки.

  • другие параметры. Полный список смотрите в описании функции register_taxonomy().
  • Почему нужно создавать произвольные таксономии?

    Если везде использовать Рубрики, то довольно быстро ваш код превратиться в кашу. В результате расширять функционал сайта будет все сложнее, а скорость работы будет все медленнее.

    Предположим у нас есть сайт по недвижимости с типом записей houses — дома. Нам нужно распределить дома по месту, ценовой категории, количеству комнат и т.д. Все это можно реализовать с помощью стандартных рубрик и это очень просто: создаем рубрики: дешевые дома, дома в Воронеже, дома с 3 комнатами и т.д. С увеличением количества домов и рубрик для них, искать нужные рубрики будет сложнее, а с увеличением функций сайта все сложнее будет управлять всем этим — в результате будет путаница и банальные ошибки в заполнении и в коде.

    В этом случае, новые таксономии в разы все упростят. Если у нас будут отдельные таксономии для каждой группы свойств, например: sale_price , number_of_bedrooms , location , то у нас появятся отдельные блоки при редактировании дома, в которых удобнее сориентироваться и выбрать куда что разместить, а также, можно будет создавать отдельные запросы по каждому типу свойства. Все это будет иметь отдельные названия, что упростит написание, понимание и скорость запросов.

    Так может выглядеть запрос, когда нужно получить дешевые дома в Воронеже:

    А если тоже самое сделать с рубриками, то код получится больше, будет менее понятный и быстрый.

    Создавать новые таксы — это часто удобно и выгодно, в конечном счете.

    Структура: таблицы таксономий в БД

    В базе данных WordPress за таксономии отвечают, не много не мало, четыре таблицы. Разберем каждую.

    Содержит элементы таксономии (термины) и базовую информацию о них. Это основная таблица элементов таксономии. Зависит от таблицы wp_term_taxonomy — они всегда идут в связке.

    term_id Уникальный ID термина (ID строки таблицы). name Название термина, пр: «Авторские функции». slug Ярлык (слаг) термина, пр: «avtorskie-funkcii». term_group Устарелое поле, больше не используется.

    Cодержит дополнительные данные об элементе таксономии, в частности важные из них — это к какой таксономии относится термин (поле taxonomy) и с какой записью связан (поле term_taxonomy_id).

    term_taxonomy_id ID строки в этой таблице, связывается с полем term_taxonomy_id из wp_term_relationships . term_id ID термина. Связывается с полем term_id из wp_terms . taxonomy название таксономии, к которой относится термин. description описание для термина. parent содержит ID родительского термина (для древовидных такс.). count содержит количество записей в термине.

    Если устанавливается WP 4.4 или выше, то в БД будет одна запись в wp_term_taxonomy для каждого термина в wp_terms , а это значит что значения полей term_taxonomy_id и term_id всегда будут одинаковые. Но если вы создавали сайт на версии ниже 4.4, то может быть несколько записей для одного термина. Такое происходило, когда создавался термин, но в другой таксономии уже был термин с таким же названием и ярлыком. В этом случае новый термин в wp_terms не создавался, а вместо этого создавалась новая запись в wp_term_taxonomy , которая означала что тот термин принадлежит к еще одной таксономии. Именно для таких «мультитерминов» нужны дополнительные поля: description , parent и count , чтобы они отличались для одного термина и его разных таксономий.

    А с версии WP 4.4, каждый термин имеет свой уникальный ID, и даже при совпадении названия и ярлыка терминов из разных таксах, создаются одинаковые записи в таблице wp_terms . Такой подход в разы понятнее и проще, при этом минусов почти нет. Сразу так сделать не догадались. Впрочем до версии WP 2.3 логика таксономий была еще хуже.

    Сегодня старая логика еще поддерживается и это означает, что нужно учитывать что одна запись в wp_terms , может иметь несколько записей в wp_term_taxonomy .

    Технически таблица wp_term_taxonomy не нужна с версии 4.4, потому что логика хранения данных изменилась и по новой логике поля taxonomy , description , parent , и count можно поместить в таблицу wp_terms и переписать весь связанный код движка и всех плагинов. Но все это совсем не просто, учитывая полную обратную совместимость WordPress (привет тем, кто не любит обновляться). Поэтому пока наслаждаться новой логикой в полной мере невозможно.

    При обновлении до версии WP 4.2 сдвоенные термины были разделены и теперь данные о разделении находятся в опции get_option(‘_split_terms’) , подробнее об этом читайте в описании функции wp_get_split_terms().

    К слову, на этом сайте таких сдвоенных терминов оказалось всего 12 из нескольких сотен существующих, что еще раз доказывает несостоятельность прежней логики такс (было столько разветвлений в коде и всяких JOIN в sql запросах, только для того, чтобы не писать 12 строк в таблицу БД).

    Содержит связи терминов с записями. Таблица показывает какая запись какому термину принадлежит. Только ID термина тут связывается через поле term_taxonomy_id , почему именно такая непонятная связь, описано выше: в таблице wp_term_taxonomy .

    Эта таблица содержит всего три поля:

    object_id Содержит ID записи (значение поля ID из таблицы wp_posts ). Если включена поддержка ссылок, то также будет содержать ID ссылки из таблицы wp_links . term_taxonomy_id Содержит значение такого же поля из таблицы wp_term_taxonomy . term_order

    Содержит порядок в котором были указаны термины, при прикреплении их к записи. Например, при редактировании записи мы указали ей 2 рубрики и 3 метки, вот в каком порядке мы их видим (они передались в POST запросе), такие значения сюда будут записаны: 1, 2 для рубрик, и 1, 2, 3 для меток.

    По умолчанию эта функция отключена для всех встроенных таксономий (поле содержит 0). Чтобы её включить, нужно указать параметр sort при регистрации таксономии, см. register_taxonomy() .

    Содержит метаданные терминов. Эта таблица дополняет таблицу wp_terms .

    В wp_termmeta принято сохранять любые дополнительные данные термина, например это могут быть СЕО поля: заголовок, описание и что угодно еще.

    Структуру таблица имеет такую же, как и другие таблицы метаданных: wp_postmeta , wp_commentmeta , wp_usermeta . Логика хранения, кэширования и получения метаданных WP едина для всех типов метаданных: посты, таксы, комменты, юзеры (об этом написал отдельную статью).

    По умолчанию, эта таблицы не задействована и всегда пуста. Она используется при расширении базовых возможностей WP, как правило плагинами.

    meta_id ID метаполя. Обычно нигде не используется. term_id ID термина из таблицы wp_terms . meta_key Ключ метаполя. meta_value Значение метаполя. Всегда строка, т.е. числа хранятся как строки, а массивы в сериализованном виде.

    До версии 4.4 у терминов не было метаполей и их записывали в опции, жуткое было время. Для тех времен я делал так.

    Связь всех таблиц

    Для создания своих SQL запросов, когда базовые функции не справляются или справляются не так как хотелось бы, нужно знать как таблицы связываются.

    Давайте посмотрим SQL запрос, который свяжет все таблицы с помощью JOIN. Запрос ниже вернет все записи типа post и данные к какому термину прикреплена каждая запись:

    Создавая подобные запросы и объединяя таблицы с помощью JOIN, вы быстро и хорошо разберетесь в зависимостях между таблицами таксономий.

    Таксономии довольно мощный инструмент в WordPress, при этом логика таблиц сравнительно простая. Разобравшись, как работают таксономий, вы сможете создавать более сложные сайты.

    Также, понимание как устроены таксономии и как записи связываются с ними, поможет вам понять где, как и какую функцию таксономий лучше использовать. Все функции таксономий вы найдете по этой ссылке.

    Комментировать
    0 просмотров
    Комментариев нет, будьте первым кто его оставит

    Это интересно
    No Image Компьютеры
    0 комментариев
    No Image Компьютеры
    0 комментариев
    No Image Компьютеры
    0 комментариев
    Adblock detector