В недавней серии мы говорили о том, как мы можем работать с метаданными для нескольких основных классов в WordPress.
Это включало:
На протяжении всей серии мы немного говорили о том, как WordPress 4.4 представил идею термина метаданные. Я не хотел представлять концепцию в контексте этой серии, потому что она зависела от понимания чего-то, что часто доставляет начинающим немного проблем.
Это то, к чему стремится эта серия.
О WordPress, Таксономиях и Условиях
В WordPress понятия таксономии и термины объединяются. Я подробнее остановлюсь на этом через минуту. Но чтобы правильно работать с метаданными терминов, я считаю, что важно понимать таксономии, термины и их отношения. Иначе, как еще мы можем иметь полное понимание того, что мы делаем, работая с ними на программном уровне?
В этой серии из двух статей мы рассмотрим таксономии, их роль, роль, которую они играют в WordPress, и их связь с терминами. Затем мы обратим наше внимание на термины и способы работы с новым API метаданных терминов.
Если вы еще не читали предыдущую серию, я рекомендую это сделать, поскольку она заложит некоторые основы того, как работает API, который мы собираемся исследовать. Если, однако, вы решите не делать этого, ничего страшного. Эта серия должна охватывать все, что вам нужно знать.
Что такое таксономии?
Как определено в Кодексе:
В WordPress таксономия — это механизм группировки для некоторых сообщений (или ссылок или пользовательских типов сообщений).
По общему признанию, это не то слово, которое вы часто слышите, и иногда другие могут запутаться, когда говорят о таксономиях и терминах. То есть они будут использовать пример фразы в качестве примера таксономии, но в данном случае они используют термин. Я коснусь этого чуть позже.
Проще говоря, думайте о таксономиях как о способах группировки вещей. Из коробки WordPress поставляется с двумя таксономиями: категории и теги . О каждом из них мы поговорим подробнее подробнее.
Теперь есть предостережение, по крайней мере, когда речь идет о WordPress: таксономии могут быть иерархическими или неиерархическими. Возможно, наиболее распространенный пример приведенной выше идеи выглядит следующим образом:
- Когда вы создаете категорию в WordPress, у вас есть возможность создать ее как категорию верхнего уровня или как подкатегорию уже существующей категории. Например, орел может быть подкатегорией птиц .
- Когда вы создаете тег в WordPress, вы создаете отдельное слово или фразу, которой вы хотите пометить (или, буквально, пометить) свой пост. Там нет понятия дочерних тегов или родительских тегов.
И в этом разница между иерархической и неиерархической таксономией. Это легко, не правда ли? Те, которые поддерживают детей, как категории, являются иерархическими; те, которые не поддерживают дочерние элементы, такие как теги, не являются иерархическими.
С работой, которую мы собираемся выполнить в этой серии, это не играет особой роли, кроме как помогает нам глубже понять, что означает этот язык в контексте наших усилий по развитию.
Но когда мы начинаем программно создавать эти объекты и добавлять к ним метаданные, не должно возникать путаницы в отношении того, что мы делаем.
Какие условия?
Мы определили таксономию, но как насчет терминов? Из Кодекса :
В WordPress термин — это классификация, группа или подмножество таксономии, где последним может быть категория, тег или пользовательская таксономия. По умолчанию термины имеют заголовок, слаг и описание. Иерархические таксономии, такие как категории, могут определять родительский термин.
Учитывая то, что мы обсуждали до сих пор, это именно то, что мы должны ожидать. То есть термины связаны с таксономиями. У терминов, однако, есть несколько примечательных аспектов, о которых мы должны знать, особенно если мы собираемся создавать их или работать с ними программно.
То есть термины состоят из:
- слизняк
- Заголовок
- описание
Помните, что если мы работаем с иерархической таксономией, такой как категория, тогда этот термин может дополнительно включать родительский термин.
Чтобы было ясно, это не означает, что таксономия не имеет набора информации, связанной с ней. Например, таксономия требует имя, тип сообщения, с которым она связана, и ряд аргументов, которые выходят за рамки этой статьи. Мы увидим больше об этом в следующей статье.
Как они связаны?
Отношения между таксономиями и терминами несколько симбиотичны, что означает, что одно не может существовать без другого. Это особенно верно, поскольку это относится к иерархическим таксономиям.
Во-первых, для тех, кто заинтересован, кодекс WordPress предоставляет диаграмму, объясняющую взаимосвязь:
Например, у вас может быть таксономия категории , но у вас должен быть хотя бы один термин, связанный с ней. Вот почему WordPress поставляется с термином « Без категории» по умолчанию.
С другой стороны, можно создать таксономию тегов , но не иметь тегов, существующих в базе данных.
Но, как разработчики, можем ли мы сделать этот шаг дальше? То есть, хотя все они могут быть созданы программно, пользователи также имеют возможность создавать и добавлять их. По крайней мере, если пользовательский интерфейс предоставляет им возможность сделать это.
Пример: когда вы смотрите на пользовательский интерфейс WordPress, у всех нас есть возможность создавать категории и теги.
Однако, если вы программист и хотите встроить в базу данных определенные таксономии и термины, у вас есть возможность сделать это и запретить пользователям добавлять и удалять их из пользовательского интерфейса.
Как насчет термина метаданных?
Мы изложили определения таксономий и терминов, а также различия между ними, но остается один вопрос: зачем нам нужны метаданные терминов? Или, возможно, в качестве альтернативы, в чем смысл термина метаданные?
Это хороший вопрос, и это, вероятно, неотъемлемая часть того, почему эта функция не была представлена до WordPress 4.4. Интересно, что билет на эту функцию был впервые представлен более шести лет назад . Основное обоснование для билета (прямо из самого Trac) гласит:
На данный момент нет специального способа хранения дополнительных данных для таксономии. Разработчики плагинов должны разработать свой собственный метод хранения этих данных, например, путем их хранения в кодировке в поле описания или с помощью set_option (). Для этого будет полезно добавить новые функции, например add_taxonomy_data () / get_taxonomy_data ().
Если вы опытный разработчик WordPress, то это имеет смысл. Но не все мы достигли этого уровня, поэтому мы не уверены, какие преимущества это дает нам.
Как и все другие API, он позволяет нам хранить информацию о любом данном термине, который существует в базе данных. Это может быть что-либо, связанное со временем создания термина, создателем этого термина или количеством сообщений, помеченных определенным термином, или оно позволяет нам связать изображение с термином.
Поскольку он поддерживает уровень произвольной информации, возможности чрезвычайно широки относительно того, что мы можем сделать с этой информацией. И начиная с следующей статьи, мы увидим именно это.
Вывод
На этом этапе у вас должно быть все, что вам нужно знать для работы с таксономиями и терминами. Конечно, вам, вероятно, придется несколько раз прочитать Кодекс, когда вы работаете над плагином, темой или пользовательским решением для клиента, но это не является необычным даже для опытного разработчика.
В следующей статье мы рассмотрим, как работать с метаданными термина. В частности, мы рассмотрим пример кода, подключим его к одной из тем по умолчанию в WordPress и будем отслеживать базу данных по мере внесения изменений.
В то же время, если вы заинтересованы в WordPress, разработке программного обеспечения или их пересечении, не забудьте взглянуть на страницу моего профиля, которая содержит ссылки на все курсы и учебные пособия, которые я опубликовал на Envato Tuts +.
Во-вторых, не стесняйтесь следить за мной в Твиттере на @tommcfarlin , где я часто говорю и делюсь ресурсами, связанными с WordPress, или следите за своим блогом, где я пишу ежедневно о работе, которую я делаю с WordPress, или темах, которые связаны между собой. к этому.
И наконец, если вы ищете другие утилиты, которые помогут вам создать свой растущий набор инструментов для WordPress или кода для изучения и стать более опытным в WordPress, не забудьте посмотреть, что у нас есть в Envato Market .
До тех пор, пожалуйста, не стесняйтесь оставлять вопросы или комментарии ниже, и я сделаю все возможное, чтобы ответить на каждый из них.