Содержание

Что такое Таксономии и Термины в WordPress? » Onwp.ru

Таксономии – это то, что переносит WordPress за пределы простой блог-платформы в реальности CMS.

Но как они хранятся в базе данных?

Таксономии и Термины – мощный инструмент WordPress, который позволяет добавлять больше гибкости вашим сайтам. Они относятся к двум другим типам контента: посты и ссылки. Структура базы данных означает, что это связь один ко многим, где один пост может иметь несколько терминов по нескольким таксономиям, и один термин может быть присвоен нескольким постам или ссылкам.

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

Характеристики

Таксономии

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

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

WordPress имеет три встроенные таксономии:

  • Рубрика
  • Метка
  • Ссылка рубрики

Рубрики и метки немного похожи на посты и страницы тем, что они одного типа контента (таксономии), но по умолчанию ведут себя по-разному, а именно: рубрики — иерархичны, а метки – нет.

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

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

Термины

У каждой таксономии будут термины, которые вы сможете использовать для сортировки данных. Рубрика – это всего лишь термин в таксономии рубрик, и метка – это термин в рубрике меток. После того как вы создадите таксономии, вы создадите термины для них либо с использованием консоли WordPress, либо с помощью функции wp_insert_term ().

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

Как WordPress хранит Таксономии и Термины

Как я уже описывал в руководстве по связям между данными, WordPress использует связь «многие-ко-многим». Эта связь создается с использованием трех таблиц:

  • wp_term_relationships
  • wp_term_taxonomy
  • wp_terms

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

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

Таблица wp_terms

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

  • term_id – это уникальный ID для термина
  • name (имя)
  • slug (ярлык)
  • term_group – это поле, которое в настоящий момент не используется WordPress, поэтому вы можете спокойно пропустить его.

Таблица wp_term_taxonomy

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

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

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

Это означает, что связь между этими двумя таблицами «один-ко-многим»: одна запись в таблице wp_terms может быть связана с несколькими записями в таблице wp_term_taxonomy, но каждая запись в таблице wp_term_taxonomy связана только с одной записью в wp_terms.

Таблица wp_term_relationships

Таблица wp_term_relationships является ключевой в создании связи «многие-ко-многим» между объектами и терминами. У нее всего лишь три поля:

  • object_id (связан с post_id в таблице wp_post или с link_id в таблице wp_links)
  • term_taxonomy_id (связан с аналогичным полем в таблице wp_term_taxonomy)
  • term_order (это порядок, в котором термины были добавлены к объекту. Он используется только в том случае, если вы задали такой тип инструмента, который будет истинным, когда вы зарегистрировали таксономию – по умолчанию имеет значение «Ложь» и значение по умолчанию для этого поля 0.

Поскольку каждый объект может быть связан с несколькими записями в таблице wp_term_relationships, таким же образом может быть связан и термин, это создает связь «многие-ко-многим».

Итог

Связи между объектами (т.е. постами и ссылками) и терминами являются мощным инструментом отчасти потому, что эта единственная связь «многие-ко-многим», которая используется в WordPress.

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

 

Источник: code.tutsplus.com

WordPress taxonomy — что это такое и с чем ее едят » Темы и Плагины для WordPress

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

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

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

О том, что же это такое, я покажу на примере:

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

Как это реализовать:

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

Что нам потребуется для создания такого функционала:

  1. Custom Post Type UI — плагин позволяет создавать различные типы данных и связывающую их таксономию.
  2. Advanced Custom Fields — позволяет привязывать дополнительные поля к различным типам данных, так же к уже готовым, таким как записи и страницы.
  3. Taxonomy Widget — позволяет выводить список тахономии, похож на вывод списка категорий или тегов.

Реализация задуманного:

  1. С помощью первого плагина мы создаем новый тип данных «товары» (Custom Post Type -> Add New -> заполняем левую форму -> Create Custom Post Type). Обратите внимание, что у левой формы есть два разворачивающихся меню с дополнительными настройками нового типа данных.
  2. С помощью того же плагина создаем таксономию «категории товаров» (Custom Post Type -> Add New -> заполняем правую форму -> ставим галку напротив типа данных который хотим связать -> Create Custom Taxonomy). Здесь тоже есть дополнительные настройки. Таких таксономий Вы можете создать сколь угодно много, например: категории товаров, теги товаров, производители товаров и т.п.
  3. С помощью второго плагина, Вы сможете задать дополнительные поля для Вашего типа данных «товары», такие как «название», «картинка», «описание» и «цена». Можно создать дополнительные поля разных типов, например: «название» — текст, «картинка» — картинка, «описание» — текстовое поле с редактором, «цена» — текст. Плагин позволяет создавать дополнительные поля 14-ти типов, есть даже такие, как выбор даты или выбор цвета.
  4. Все, функционал готов, теперь нам нужно вывести на сайт список «категории товаров». Для этого нам и понадобится третий плагин, который позволит вывести в виджете любую таксономию в том виде, который Вам нравится: список, выпадающее меню и облако (как облако тегов).

Более подробно, расскажу по запросу.

«Плагины для удобства работы с таксономией» — продолжение этой темы, рекомендуется к прочтению.

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

Таксономия (общая) — Taxonomy (general)

Классификация отдельных вещей, понятий или групп и принципы, лежащие в основе такой классификации

Таксономия — это практика и наука категоризации или классификации, основанная на дискретных наборах . Это слово также используется в качестве существительного счетчика : таксономия или таксономическая схема — это особая категоризация. Слово уходит корнями в греческий язык τάξις , taxis (что означает «порядок», «порядок») и νόμος , nomos («закон» или «наука»). Первоначально таксономия относилась только к категоризации организмов или определенной категоризации организмов. В более широком, более общем смысле это может относиться к категоризации вещей или концепций, а также к принципам, лежащим в основе такой категоризации. Таксономия отличается от мерономии , которая имеет дело с категоризацией частей целого.

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

Приложения

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

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

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

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

История

Антропологи заметили, что таксономии обычно встроены в местные культурные и социальные системы и выполняют различные социальные функции. Возможно, наиболее известным и влиятельным исследованием народной систематики является книга Эмиля Дюркгейма « Элементарные формы религиозной жизни» . Более новую трактовку народных таксономий (включая результаты нескольких десятилетий эмпирических исследований) и обсуждение их связи с научной таксономией можно найти в « Когнитивных основах естествознания» Скотта Атрана . Было обнаружено, что народные таксономии организмов в значительной степени согласуются с научной классификацией, по крайней мере, для более крупных и очевидных видов, что означает, что народные систематики не основаны исключительно на утилитарных характеристиках.

В семнадцатом веке немецкий математик и философ Готфрид Лейбниц , следуя работе майорканского философа тринадцатого века Рамона Лулля над его Ars generalis ultima , системой для процедурной генерации концепций путем комбинирования фиксированного набора идей, стремился разработать алфавит человеческая мысль . Лейбниц задумал, что его характеристика universalis будет «алгеброй», способной выразить все концептуальные мысли. Концепция создания такого « универсального языка » часто рассматривалась в XVII веке, в частности, английским философом Джоном Уилкинсом в его работе «Эссе к реальному персонажу и философскому языку» (1668 г.), откуда классификационная схема в Roget «S тезауруса в конечном счете происходит.

Использование таксономий в различных дисциплинах

Таксономии в программной инженерии

Vegas et al. привести убедительные доводы в пользу продвижения знаний в области разработки программного обеспечения с помощью таксономий. Аналогичным образом Ore et al. предоставить систематизированную методологию подхода к построению таксономии в вопросах, связанных с программной инженерией.

Таксономии тестирования программного обеспечения

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

  1. Таксономия методов тестирования на основе моделей
  2. Таксономия инструментов статического анализа кода

Engström et al. предложить и оценить использование таксономии для связи между исследователями и практиками, занятыми в области тестирования программного обеспечения. Они также разработали веб-инструмент для облегчения и поощрения использования таксономии. Инструмент и его исходный код доступны для публичного использования.

Таксономии в публикациях исследований

Ссылаясь на недостатки с текущей практикой в список авторов статей в медицинских научных журналах, Drummond Ренни и соавторов , называемых в статье , опубликованной в 1997 JAMA , в журнале Американской медицинской ассоциации для

радикальное концептуальное и систематическое изменение, чтобы отразить реалии множественного авторства и укрепить ответственность. Мы предлагаем отказаться от устаревшего понятия «автор» в пользу более полезного и реалистичного понятия «участник».

С 2012 года несколько крупных академических и научных издательств внедрили Project CRediT для разработки контролируемого словаря ролей участников. Известная как CRediT (Таксономия ролей участников) , это пример плоской, неиерархической таксономии; тем не менее, он включает необязательную широкую классификацию степени вклада: ведущий , равный или поддерживающий . Эми Брэнд и соавторы резюмируют свой предполагаемый результат следующим образом:

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

По состоянию на середину 2018 года эта таксономия, очевидно, ограничивает область применения результатов исследований , в частности журнальных статей; тем не менее, он довольно необычно «надеется… поддержать идентификацию рецензентов». (Таким образом, в нем еще не определены термины для таких ролей, как редактор или автор главы в книге с результатами исследования.) Версия 1, созданная первой Рабочей группой (северной) осенью 2014 года, определяет 14 конкретных участников. роли, используя следующие определенные термины:

  • Концептуализация
  • Методология
  • Программного обеспечения
  • Проверка
  • Формальный анализ
  • изучение
  • Ресурсы
  • Курирование данных
  • Письмо — оригинальный черновик
  • Написание — просмотр и редактирование
  • Визуализация
  • Надзор
  • Администрация проекта
  • Получение финансирования

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

Национальная академия наук создала TACS (прозрачность в Авторе взносах в науке) веб — страницу в список журналов, совершающие в установлении стандартов авторства, определении обязанностей для соответствующих авторов, требующий ORCID IdS и принятий Кредитной таксономии.

На той же веб-странице есть таблица со списком 21 журнала (или семейства журналов), из которых:

  • 5 внедрили или к концу 2018 года внедрили CRediT,
  • 6 требуется заявление автора и предлагается использовать CRediT,
  • 8 не используют CRediT, в 3 из которых приводятся причины, по которым это не следует делать, и
  • 2 малоинформативны.

Таксономия — это открытый стандарт, соответствующий принципам OpenStand , опубликованный под лицензией Creative Commons .

Таксономия в Интернете

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

Рекомендации по написанию таксономии для Интернета
  • Взаимоисключающие категории могут быть полезными. Если категории появляются в нескольких местах, это называется перекрестным списком или полииерархическим. Иерархия потеряет свою ценность, если перекрестные списки будут появляться слишком часто. Перекрестный список часто появляется при работе с неоднозначными категориями, которые подходят более чем одному месту.
  • Полезно иметь баланс между широтой и глубиной таксономии. Слишком много вариантов (широты) перегрузят пользователей, предоставив им слишком много вариантов. В то же время слишком узкая структура с более чем двумя или тремя уровнями перехода по клику разочарует пользователей и может сдаться.

Отношения есть и есть, и гипонимия

Два преобладающих типа отношений в системах представления знаний — это предикация и универсально определяемое условное обозначение . Отношения предикации выражают представление о том, что отдельная сущность является примером определенного типа (например, Джон — холостяк ), в то время как универсальные количественные условия выражают представление о том, что тип является подтипом другого типа (например, « Собака — это млекопитающее » , что означает то же самое, что и« Все собаки — млекопитающие » ).

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

В лингвистике отношения is-a называются гипонимией . Слова, описывающие категории, называются гиперонимами, а слова, являющиеся примерами категорий, — гипонимами. В простом примере биологии собака — это гипероним, а Фидо — один из его гипонимов. Слово может быть как гипонимом, так и гиперонимом. Например, собака — это гипоним млекопитающего, а также гипероним Фидо .

Смотрите также

Примечания

Ссылки

  • Атран, С. (1993) Когнитивные основы естествознания: к антропологии науки. Кембридж: Издательство Кембриджского университета . ISBN  978-0-521-43871-1
  • Карбонелл, Дж. Г. и Дж. Зикманн, ред. (2005). Вычислительная логика в многоагентных системах, Vol. 3487. Берлин: Springer-Verlag . ISBN  978-3-540-28060-6
  • Мэлоун, Джозеф Л. (1988). Наука лингвистики в искусстве перевода: некоторые инструменты лингвистики для анализа и практики перевода. Олбани, Нью-Йорк: Государственный университет Нью-Йорка . ISBN  978-0-887-06653-5 ; OCLC 15856738
  • * Марчелло Чарс Келлер, «Проблема классификации в исследованиях народных песен: краткая история», Folklore , XCV (1984), no. 1, 100-104.
  • Честер Д. Роу и Стивен М. Дэвис, «Набор инструментов для двигателя Excellence»; ISBN  978-0-615-24850-9
  • Härlin, M .; Сундберг, П. (1998). «Таксономия и философия имен». Биология и философия . 13 (2): 233–244. DOI : 10.1023 / а: 1006583910214 . S2CID  82878147 .
  • Lamberts, K .; Шанкс, Д.Р. (1997). Знания, концепции и категории . Психология Press. ISBN 9780863774911.

внешние ссылки

Как добавить таксономию пользователей в WordPress

Введение

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

Мотивация

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

Начало

В каталоге темы «inc» я создал таксономию «категория-пользователь».php ’, куда я добавлю весь код, показанный в этом руководстве. Этот файл необходимо вызвать в файле functions.php со следующим фрагментом:

Давайте немного закодируем

Ниже я определяю имя таксономии и мета-ключ категории пользователя в нашем файле:

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

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

Чтобы это произошло, мы будем использовать приведенный ниже хук, который вызывает функцию nopio_add_user_categories_admin_page:

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

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

Давайте исправим это с помощью приведенного ниже кода:

Обновите страницу, и вы увидите, что теперь все стало лучше.

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

В функции нам нужно обязательно отображать поле выбора только для администраторов и авторов. На следующем этапе давайте добавим новую HTML-таблицу с полем множественного выбора. Эта таблица будет последней на странице профиля автора.Кроме того, поле с множественным выбором создается с помощью настраиваемого помощника nopio_custom_form_select.

Вот вспомогательная функция select, я не буду останавливаться на этой части l, но ее можно использовать для создания полей с одним или несколькими вариантами выбора:

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

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

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

Как я упоминал ранее, функция «nopio_update_users_categories_count» заменяет неиспользуемую функциональность «update_count_callback» во время регистрации таксономии категорий пользователей.Вот как это работает. Во-первых, нам нужно объединить идентификаторы из предыдущих и новых категорий в один массив. Затем давайте пересчитаем авторов для каждой категории в цикле foreach. Мы можем сделать это с помощью запроса SELECT. В БД значение счетчика метаданных выглядит так: a: 2: {i: 0; s: 1: ”2 ″; i: 1; s: 1:” 3 ​​″;}, поэтому нам нужно использовать LIKE в выборе запрос. В качестве последнего шага мы можем обновить поле БД счетчика категорий.

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

Вот результат на интерфейсной странице, в моем случае «Категория 3» была пустой и не указана на странице:

Сводка

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

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

Код можно найти здесь, на GitHub.

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

Как создать собственную таксономию

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

Создайте собственную таксономию

Перейдите к Pods Admin> Добавить новый и нажмите кнопку Create New .

Убедитесь, что в раскрывающемся меню «Тип контента» выбрано Пользовательская таксономия (например, «Категории» или «Теги») .

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

Присвойте своей пользовательской таксономии метку множественного числа . Давайте возьмем пример веб-сайта с обзором книг, на котором книги сгруппированы по жанрам. Множественное число — жанры.

Введите метку единственного числа . В этом примере единственное число — это жанр.

Щелчок по ссылке Advanced предоставляет вам расширенный вариант. В большинстве случаев достаточно значений по умолчанию. Вариант:

  • Идентификатор — это имя, которое вы будете использовать, ссылаясь на свой собственный тип сообщения в коде и шорткодах

Когда все будет хорошо, нажмите Next Step .

Этикетки

Вкладка «Ярлыки» позволяет настраивать ярлыки таксономии в вашем администраторе. Они предварительно заполнены названием вашей Таксономии. Однако вы можете настроить их, если хотите. Добавление новой метки к первым двум полям обновит все ваши метки, или вы можете настроить каждую метку индивидуально.

Пользовательский интерфейс администратора

Вкладка «Интерфейс администратора» позволяет настроить внешний вид меню администратора, в том числе:

  • Показывать ли таксономию в меню администратора и в пользовательском интерфейсе таксономии по умолчанию
  • Название и расположение меню (соответствующие меню типов сообщений (по умолчанию), меню настроек, меню внешнего вида, новый пункт меню, подменю в другое меню)

Дополнительные параметры

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

  • Иерархическая — определяет, будет ли ваша таксономия иерархической, как категории, или плоской, как теги.
  • Связанные типы сообщений — здесь вы связываете таксономию с типом сообщения. Таксономия жанров, например, будет связана с типом публикации «Книги».

См. Кодекс WordPress для функции register_taxonomy () для получения дополнительной информации о параметрах, доступных на вкладках «Дополнительные параметры» и «Пользовательский интерфейс администратора».

Управление полями

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

Сохранить

Когда вы закончите настройку параметров, нажмите «Сохранить пакет».

Связанные

Получение сообщений по таксономии или метаполям с помощью WP API v2.0

 03 марта 2016 ОБНОВЛЕНО:

Обновлены все маршруты в этом посте, поэтому теперь они должны быть совместимы с WP API V2 beta 12.

28 февраля 2016 г. ОБНОВЛЕНО:

Только что реализовано с v2 beta 4,  / posts   WP_Query  vars был перемещен обратно в   filter   param. Я обновлю все маршруты в этом посте как можно скорее. 

В сообщении о добавлении полей в ответ JSON WP REST API вы узнали о том, как управлять данными из WP REST API (WP-API).Еще одна тема, которую меня очень часто спрашивают, — это как получить сообщения с помощью определенных фильтров — в основном таксономии и метаполя. Итак, сегодня давайте поговорим об этом.

Прежде чем мы начнем, если вы ищете обходные пути для WP-API v1.x, Джош написал для вас отличные руководства. Вот ссылки на них:

  1. Работа с таксономиями с использованием JSON REST API
  2. Работа с метаданными с помощью JSON REST API

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

Быстрые ответы

*** Обратите внимание, что начиная с WP API v2 beta 4, вам нужно установить "show_in_rest" => true при регистрации произвольного типа сообщения или таксономии, чтобы он отображался в ответе JSON. ***

Итак, вот они. Если вы хотите получать сообщения по таксономии с WP-API v2.0, вы можете использовать конечную точку / маршрут следующим образом: ( тип задания — это таксономия , а менеджер — это термин , который вы хотите сопоставить )

 wp-json / wp / v2 / posts? Filter [job-type] = manager 

Обратите внимание, если вы установите для параметра query_var значение false при регистрации пользовательской таксономии, вам нужно будет изменить параметры на:

 wp-json / wp / v2 / posts /? Filter [taxonomy] = job-type & filter [term] = manager 

Что касается таксономии по умолчанию — тег , то также применяется правило:

 wp-json / wp / v2 / posts /? Filter [tag] = любовь 

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

 wp-json / wp / v2 / posts /? Filter [имя_категории] = без категорий 

Получать сообщения по мета-полю по умолчанию недоступно

Когда дело доходит до мета-полей, вы, возможно, уже знаете, что это не работает с WP-API по умолчанию (по соображениям безопасности).При использовании термина «по умолчанию» вы должны быть очень счастливы ожидать обходного пути для его взлома. И почти все волшебство в WordPress связано с крючком — действие или фильтр , так что же в этом случае на помощь?

Вот и все: фильтр rest_query_vars . Вот как это использовать:

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

 wp-json / wp / v2 / posts? Filter [meta_key] = MY-KEY & filter [meta_value] = MY-VALUE 

Кстати, если вы заинтересованы в том, чтобы настраиваемые типы сообщений работали с WP-API v2, ознакомьтесь с советами, предоставленными @joneslloyd.

А как насчет meta_query для сложных мета-пар ключ / значение?

Если вы хотите запрашивать сообщения на основе нескольких пар мета ключ / значение, вы должны использовать для этого meta_query . Как и в приведенном выше примере, нам также нужно добавить его к допустимым переменным запроса, например:

И тогда вы можете использовать meta_query с WP API v2. Я знаю, что некоторые люди застряли в том, как писать массивы как параметры GET / POST , поскольку meta_query — это массив, составленный из массивов, что выглядит довольно пугающе, если подумать о преобразовании его в параметры URL-адреса для маршрута / сообщений в WP API .

К счастью, я обнаружил, что MailChimp задокументировал это в своей документации по API, обязательно ознакомьтесь с ней!

Что такое большая картина?

Когда я был младшим разработчиком (около 2007–2008 гг.), Меня больше всего беспокоило то, что библиотека или код, с которыми я работал, не были хорошо документированы. Честно говоря, в те дни я едва мог выполнять работу, даже когда документация была тщательно подготовлена. Например, я не мог самостоятельно создать веб-приложение на платформе Zend, что, насколько я помню, тогда было очень хорошо документировано.

К счастью, прошло

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

Серия создания тем с AngularJS и WP REST API была посвящена AngularJS в первых 14 сообщениях. Но потом я понял, что мне нужно проводить больше времени с WP REST API, поскольку иногда вопросы моих читателей можно легко решить, если они лучше понимают, как работает WP-API или WP_Query.

Все дело в query_vars

Итак, давайте взглянем на простую, но мощную функцию из исходного кода WP-API:

Эта функция get_allowed_query_vars относится к классу WP_REST_Posts_Controller , который отвечает за то, какие переменные запроса (которые мы передаем в маршрут, такие как категория категория и тег ) могут использоваться для получения сообщений с помощью WP-API.

Эта функция выполняет следующие задачи:

  1. Строка 16 : Получить все допустимые переменные запроса из $ wp-> public_query_vars .О том, что они из себя представляют, мы расскажем позже.
  2. Строка 18-33 : Если пользователь может edit_posts , он / она может получить доступ к большему количеству переменных запроса с помощью $ wp-> private_query_vars , мы также поговорим о них позже.
  3. Строка 35 : WP-API добавляет еще три переменных запроса: posts_per_page , ignore_sticky_posts и post_parent
  4. Строка 47 : В конце этой функции мы можем использовать фильтр rest_query_vars , чтобы изменить все доступные переменные запроса.Например, здесь мы можем добавлять или удалять переменные. (Мы только что научились трюку несколько минут назад.)

Списки общедоступных и частных переменных запроса

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

Трассировка до wp-includes / class-wp.php , вы увидите две переменные, которые мы ищем: $ public_query_vars и $ private_query_vars .Помимо этих переменных, когда мы регистрируем пользовательские типы сообщений или таксономии, если мы установим query_var в строку (конечно, не может быть пустой строкой), она будет присоединена к семейству $ public_query_vars .

Почему posts_per_page не работает (по крайней мере, в v2.0-beta3)

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

Я еще раз взглянул на исходный код WP-API.Из того же класса ( WP_REST_Posts_Controller ) функция get_items помогла мне понять это:

В строке 15 (из приведенной выше сути) вы можете увидеть, что WP-API фактически получает posts_per_page из другого параметра с именем per_page , но не самого posts_per_page . Я не исследовал каждый фрагмент кода в WP-API, поэтому не могу придумать вескую причину, по которой он это делает.

Судя по этой проблеме в репозитории WP-API на GitHub, я думаю, что разработчики все еще работают над стилем аргументов (см. Этот комментарий).Это очень информативное обсуждение, поэтому обязательно ознакомьтесь с ним.

Повышение безопасности мета-запросов при работе с WP-API v2.0

Если вы какое-то время следили за WP-API, вы должны заметить, что каждый раз, когда кто-то спрашивает о «мета-запросе», ему / ей будут напоминать, что « могут быть некоторые риски безопасности » при раскрытии мета-значения в WP-API.

Я никогда не храню конфиденциальные или конфиденциальные данные в мета-сообщениях, поэтому я очень надеюсь, что все будет проще.Но поскольку WordPress и WP-API так не работают, давайте посмотрим, что еще мы можем сделать.

Ограничение возможности запроса мета-ключей

Независимо от того, какой фильтр вы используете для добавления мета_ключа и мета_значения к $ valid_vars (вы можете использовать query_vars , rest_private_query_vars и поля rest_query_vars 67), все вы можете в основном разрешить спросил. Если это слишком рискованно для вас, попробуйте ограничить meta_key только разрешенными полями с фильтром rest_post_query .


Надеюсь, вам понравится этот пост, и я хотел бы потратить больше времени, чтобы лучше узнать WP-API v2.0. Если у вас возникнут какие-либо вопросы при выполнении шагов из этого руководства, просто напишите мне по электронной почте: yoren [at] 1fix.io или напишите мне в Twitter (@ 1fixdotio), и комментарии приветствуются. Скоро поговорим!

Как переводить категории и пользовательские таксономии в WordPress

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

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

В этом руководстве мы собираемся использовать TranslatePress, удобный для новичков плагин перевода WordPress, который позволяет вам переводить все заголовки таксономии в одном месте, используя интуитивно понятный интерфейс перевода, который выглядит так:

Он также работает «из коробки» с любой темой или плагином, включая WooCommerce или конструкторы страниц, такие как Elementor. С его помощью вы можете переводить любой контент на вашем сайте, страницу за страницей, используя редактор визуального перевода.

Погрузимся в…

Перевод категорий, пользовательских таксономий и терминов WordPress с помощью TranslatePress

Таксономии

WordPress полезны для группировки таких вещей, как сообщения в блогах или пользовательские типы сообщений (события, книги, фильмы и т. Д.)) все вместе. Регулярно используются две популярные таксономии: «Категории» и «Теги». Пользователи могут добавлять теги к своим записям WordPress вместе с категориями.

Пользовательская таксономия может быть чем-то вроде «Жанр» для пользовательского типа публикации «Фильмы». В этом случае термины таксономии «Жанр» могут включать: «Боевик», «Романс», «Триллер» и другие.
Очевидно, здесь много возможностей для группировки вашего контента.

TranslatePress позволяет легко переводить любую таксономию или название терминов.

Используя интерфейс перевода URL Slug, вы можете:

  • Перевести ярлыки таксономии
  • Перевести ярлыки терминов
  • Перевести ярлыки сообщений (включая страницы и пользовательские типы сообщений)
  • Перевести базовые слага типа поста
  • Перевести ярлыки WooCommerce (база магазина, категория продукта, тег продукта)

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

Начало работы с TranslatePress

Установка TranslatePress на ваш веб-сайт — несложный процесс. Перейдите в панель управления WordPress, выберите «Плагины → Добавить новый » и найдите « TranslatePress ». Нажмите Установить , а затем Активировать рядом с названием плагина.

Для перевода категорий, таксономий и терминов вам также понадобится надстройка SEO Pack (входит в любую премиум-версию TranslatePress).

Затем в TranslatePress Settings убедитесь, что вы добавили язык перевода, на который вы хотите сделать свой сайт доступным. В этом примере мы выберем « испанский ». На странице настроек также есть такие параметры, как настройка переключателя языка, но пока мы оставим их по умолчанию.

Обязательно сохраните настройки и нажмите « Translate Site ».

Вам будет предложен визуальный редактор перевода (аналогичный настройщику), где вы просто нажимаете, чтобы выбрать определенный текст, а затем вводите его перевод на левой боковой панели.Нажмите «Сохранить перевод», и вы только что перевели свой первый фрагмент текста. Просто повторите тот же процесс для каждой строки на странице, и весь ваш контент будет переведен.

Чтобы ускорить процесс, вы можете использовать автоматический перевод (TranslatePress объединяет сервисы машинного перевода Google Translate и DeepL), а после просто изменить то, что не было переведено должным образом.

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

Перевод названия категории или произвольной таксономии WordPress

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

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

Помимо фактического имени, нам нужно перевести еще одну важную вещь, это таксономия и название термина.

Перевод ярлыков таксономии WordPress

Лучший способ перевести все таксономии и краткие названия терминов из одного места — переключиться с Visual Editor на вкладку String Translation (внизу слева).

Здесь вы можете выбрать тип заголовков URL, которые хотите перевести, с помощью мини-вкладок, а также отфильтровать и найти определенные.

Мы выберем вкладку « Taxonomy Slugs » и переведем каждую таксономию на испанский язык.Как вы заметили, первая таксономия WordPress по умолчанию: « категория ». Просто нажмите на нее, введите перевод, нажмите «Сохранить» и перейдите к следующей таксономии.

Перевести категорию и тег продукта WooCommerce

Используя этот интерфейс, вы также можете переводить категории продуктов WooCommerce, а также теги продуктов. Мы продолжим и переведем таксономию « товар-категория » на испанский язык.

Вы можете переводить любые типы категорий (в том числе пользовательские) из интерфейса перевода строки URL TranslatePress.

Перевод терминов WordPress

Теперь, когда мы перевели все таксономии, мы можем перейти к переводу кратких терминов. При нажатии на вкладку « Term Slugs » будут перечислены все термины. Интерфейс также покажет вам соответствующую таксономию для этого конкретного термина.

Перевод любых словосочетаний выполняется точно так же. Вы выбираете термин, вводите его испанский перевод на боковой панели перевода и нажимаете « Сохранить перевод ».

После того, как вы закончите перевод всего, просто закройте интерфейс перевода URL Slug Translation и просмотрите интерфейс своего веб-сайта на испанском языке.Вы заметите, что все таксономии и заголовки терминов переведены правильно.

Начните перевод таксономий WordPress с помощью TranslatePress

Используя TranslatePress вместе с надстройкой SEO Pack, вы можете переводить таксономии и термины WordPress в одном месте, используя знакомый интерфейс.