Мой вопрос прост, я использую WP_Query
фильтрацию некоторых сообщений пользовательского типа по таксономии с использованием tax_query
.
Теперь моя проблема в том, что я хотел бы orderby
, taxonomy
но из документации и поиска в Интернете я не могу найти решение.
In позволяет упорядочивать orderby
по WP_Query
множеству полей даже настраиваемые метаполя, но, похоже, он не поддерживает таксономию.
Любые указатели в правильном направлении?
Спасибо вам всем.
Нет, упорядочить по таксономии невозможно, потому что с определенной точки зрения это не имеет особого смысла.
Таксономии — это способы группировки вещей. Таким образом, смысл таксономии постов на самом деле состоит в том, чтобы иметь термины в этой таксономии, которые являются общими для постов. Если бы в таксономии были термины, которые использовались только в одном сообщении, то это сделало бы таксономию бессмысленной. И если бы термины были разделены так, как они должны быть, то упорядочение по нему не дало бы ничего особенно полезного.
То, что вы должны использовать в такой ситуации, — это post meta. Вы можете упорядочить по метаданным поста, и он уникален для каждого поста.
Изменить: Тем не менее, вы можете упорядочить по таксономии, создав собственный SQL-запрос с использованием фильтра, вы просто не можете сделать это из немодифицированного WP_Query: http://scribu.net/wordpress/sortable-taxonomy-columns.html
Однако, если вам приходится прибегать к подобным вещам, то ваша структура проектирования данных изначально неверна. «Термины» в таксономии не являются фактическими «данными». Сами по себе термины не имеют внутреннего значения, они просто ярлыки для конкретной группы, которую они описывают. Если вы рассматриваете их как значимые данные, то у вас есть основной недостаток дизайна.
Таксономии группируют вещи, назначая им термины. В этой группировке и заключается весь смысл таксономии, термины — это просто красивые лица в группировке. Если у вас есть значимые метаданные для назначения сообщению, то вместо этого вы должны использовать для него метаданные сообщения. И это вы можете упорядочить, потому что метаданные сообщений используют как ключи, так и значения для хранения информации. С таксономией вы действительно храните только ключи, а их значения представляют собой сообщения, сгруппированные вместе по этому термину.
В долгосрочной перспективе все становится проще, если вы используете правильный подход. Хотя я не говорю, что вы не можете сделать что-то странное с таксономией, вы просто усложняете себе жизнь в долгосрочной перспективе, используя ее неправильно.
Привет Отто, спасибо за ответ. Я понимаю вашу точку зрения, и, возможно, я иду неправильным путем с этим. В моем примере на сайте телешоу у меня есть таксономия для серии 1, серии 2, серии 3 и т. д. Таким образом, я могу сгруппировать все различные телешоу по номеру серии. Тогда у меня то же самое для эпизодов, Эпизод 01, Эпизод 02 и т. Д. Я хотел бы, чтобы при отображении списка всех эпизодов они были упорядочены по эпизодам и сериям. Я проанализирую, а затем опубликую мета и настраиваемые поля. Спасибо, Отто.
@yeope ваша таксономия должна быть серией, а ваши термины должны быть серией 1, серией 2 и т. д. Что касается эпизодов, я предполагаю, что сериал содержит несколько эпизодов, поэтому он может использовать одну и ту же таксономию, «серию», и если они иерархичны, тогда эпизод 1, эпизод 2 и т. д. будет иметь родительский термин «серия x». Затем вы можете запросить всю серию по порядку, чтобы эпизоды располагались там, где должны.
На самом деле использование таксономии для эпизодов не имеет большого смысла, потому что группировка бесполезна. Подумайте об этом, если у вас есть термин «эпизод 1», то вы группируете эпизод 1 с каждым другим эпизодом 1 из любого другого телешоу. Номера эпизодов и серий имеют больше смысла как post_meta, потому что они специфичны для этого конкретного шоу и бесполезны как группа. Название телешоу было бы полезно в качестве термина в таксономии телешоу, потому что тогда вы группируете шоу как единое целое.
Отто продолжил это интересным сообщением в блоге: Когда (не) использовать пользовательскую таксономию.
Извините @Otto, я только сейчас заметил ваш ответ… Я полностью согласен с вашими смысловыми точками и логикой. Но в моем контексте «сортировка» была бы главным образом вопросом эргономики. Визуальное группирование прогнозов по «фестивалю» может, что немаловажно, помочь пользователю получить визуальное резюме, основанное на наиболее важном для него факторе, это с первого взгляда. Таким образом, не уверен, что смогу добиться этого как-то иначе, кроме как «сортировкой», что, я согласен, не является подходящим термином…
Извините, но вы не правы. Заказ по таксономии также не имеет никакого смысла в вашем случае. Что вы хотите показать? Сначала все завтраки, затем все ужины, потом все обеды? Вы должны выбрать то, что вы хотите, и порядок, в котором вы хотите это сделать, но таксономия — это просто ярлык для группировки. Это не значимые «данные», по которым вы должны упорядочивать. Если это так, то это не должен быть термин в таксономии, вместо этого вы должны сделать его пост-мета.
Да ладно, конечно, будут некоторые случаи, когда вы захотите упорядочить сообщения по термину таксономии. Другим примером является тип публикации Movie с таксономией Rating. В списке фильмов очень легко представить людей, желающих упорядочить список фильмов по рейтингу, чтобы все фильмы с рейтингом G, затем с рейтингом PG и т. д. отображались вверху. (В этом примере и в примере с едой они могут быть упорядочены по term_id, а не по имени.) Существует большая серая область случаев, когда вам, вероятно, лучше всего подходит таксономия, а не мета, но, вероятно, также полезно, чтобы эта таксономия была упорядочена. -способный.
Рейтинги PG и G и тому подобное — хороший выбор таксономии, за исключением того, что это данные о конкретных фильмах. Таким образом, они являются мета. Это данные, а не категории. Просто наличие ограниченного числа вариантов не делает таксономию. Если требуется сортировка, то либо сделайте ее мета, либо принудительно выполните сортировку по таксономии с помощью специального кода таксономии. Кстати, NC17 идет после PG. Итак, вам в любом случае нужен код для выполнения этого заказа.
Я знаю, что опаздываю на вечеринку с этим комментарием, но просто наткнулся на это. Упорядочивание по таксономии может иметь смысл в некоторых ситуациях. У нас есть списки вакансий в одном проекте в качестве типа сообщения, а затем штат и город, в котором находится работа, являются таксономиями. Мы хотим, чтобы их было легко группировать (показывать все вакансии в штате или показывать все вакансии в городе), поэтому таксономия была лучшим решением. В то же время есть общий поиск работы, где мы хотим отсортировать их сначала по названию, затем по штату, затем по городу.
Другой вариант использования: у клиента есть куча статей, каждая из которых имеет категорию. Клиент хочет, чтобы была страница со списком всех статей, которые можно отсортировать по алфавиту, по дате или по категории. Категории также могут быть отфильтрованы, но перечисление всех статей по категориям в алфавитном порядке не так уж и безумно, и вы видите, что это всплывает довольно часто.
Спасибо, Дрю, я попробую запустить этот SQL, нужно немного отредактировать, но это может сработать. Моя единственная проблема сейчас в том, что я могу идти не в том направлении, как указал Отто. Спасибо, Дрю. РЕДАКТИРОВАТЬ. Нет необходимости редактировать, я вижу, где это нуждается в настройке 🙂 Спасибо.
Если вы схватили его в течение последних двух минут, он не сработает, давай, схвати его сейчас, я это исправил. Он был установлен для двух определенных таксономий, я улучшил код для работы со всеми зарегистрированными таксономиями.
еще раз, спасибо. На всякий случай я попробовал ваше решение, и оно работает. Также, если кто-то еще хочет использовать его, вам нужно изменить
add_filter('posts_clauses', 'orderby_tax_clauses', 10, 2 );
его наadd_filter('posts_clauses', 'todo_tax_clauses', 10, 2 );
Спасибо 🙂Да, теперь это исправлено в блоке кода, я взял это из проекта, над которым работаю, и забыл изменить имя функции, хотя я изменил его в хуке.
Знаете ли вы, можно ли упорядочить таксономии по идентификатору вместо имени? Я пытаюсь получить тот же результат, упорядочивая группы таксономии по идентификатору.
Любая идея о том, как заказать по имени вместо term_taxonomy_id? изменение term_taxonomy_id в orderby_statement вызывает ошибки
Это правильный ответ для всех, кто заинтересован!
@tehlivi этот метод не работает для заказа по имени, потому что имя находится в
wp_terms
таблице. Похоже, что WordPress кэширует термины таксономии, поэтому, даже если ваш налоговый запрос выполняет поиск по слагу или имени, которые также находятся вwp_terms
таблице, WordPress прогоняет их через свой кешированный список и обменивает их на идентификаторы, хранящиеся вterm_relationships.term_taxonomy_id
, поэтому ему не нужно запрашиватьwp_terms
таблицу как часть основного запроса. Это означает, что ни имя, ни слаг не включаются в результирующий SQL-запрос. Вы должны добавить соединения.@EthanC, чувак, спасибо за твой подробный ответ, и, надеюсь, если кто-нибудь найдет это в будущем, он найдет твой ответ полезным. Но лично мне, конечно, трудно вспомнить что-либо из 2016 года. Я думаю, что закончилось тем, что я пропустил массив через функцию сортировки после завершения запроса. Я уверен, что любой разработчик, взявший на себя этот проект после моего ухода из компании, ненавидит меня. Ха.
@tehlivi Да, в итоге я полностью проигнорировал основной запрос, если некоторым сообщениям было присвоено более одного термина. Вместо этого решил запускать
get_terms()
и запускатьget_posts
для каждого термина. Добавил ~15 запросов на загрузку страницы, но дизайнер получает тот результат, который хотел.@yeope Почему это принятый ответ !? слава богу пролистал
не мог заставить это работать. Можете ли вы указать сайт с некоторым объяснением этого? ничего здесь, что поддерживает ваш код
Хорошая работа, смешно, что такое количество кода потребовалось для сортировки чего-то по таксономии. Огромная проблема с WP.
Большое спасибо, это очень полезно. Здорово, что есть возможность сделать заказ визуально. Знаете ли вы, почему там есть часть «ИЛИ таксономия IS NULL»? Вроде бы что-то не нужное.
Он правильно отображает первый термин, но после этих сообщений следующий термин логически не следует порядку меню, как указано в SCP Order. Мне интересно, потому что я пытаюсь сделать это с продуктами, а в WooCommerce уже есть порядок атрибутов… может быть, они конфликтуют. В БД идентификаторы в столбце term_order верны…
Кажется, помогает изменение строки GROUP_CONCAT orderby на следующую: $clauses[‘orderby’] = «{$wpdb->terms}.term_order ASC»;
Я тоже об этом думаю, хотя это дублирует данные.
Принятый ответ на этот вопрос неприемлем. Нелогично полагать, что упорядочение по налогам «не имеет смысла». Ответ, который он дал, не имеет смысла.
Подумайте о типе поста меню. Тогда у вас есть пользовательский налог «FoodCategories». Налог на категории продуктов питания включает термины «завтрак», «обед» и «ужин». Если вы отправляете запрос с использованием параметра tax_query, теперь у вас есть набор результатов со всеми терминами, однако они упорядочены по дате публикации.
Чтобы получить правильный порядок из них относительно их терминов, а затем правильно отобразить их во внешнем интерфейсе, разделив сообщения на их различные категории, вы должны пройтись по набору результатов, а затем запросить каждое отдельное сообщение в пределах набор результатов, чтобы найти его термины и сравнить с текущим термином, отфильтровать в массив и продолжить. Затем вам нужно снова просмотреть новый массив для отображения. Это не продуктивно.
Было бы неплохо, если бы у WP была опция orderby «tax__in», как она делает «post__in», но поскольку ее нет, вам либо придется выполнить описанный выше нелепый процесс; настроить запрос самостоятельно с помощью фильтров ‘posts_orderby’ и ‘posts_join’, чтобы настроить метод orderby и добавить терм в результирующий набор соответственно; или вам нужно сделать новый запрос для каждого термина, который вы фильтруете, в разделах html относительно этих терминов.
Наиболее эффективным было бы изменение строки запроса с помощью фильтров. Проще всего было бы сделать три отдельных запроса. API WP должен обрабатывать упорядочение по налогам или любым ограничительным параметрам запроса. Если вы ограничиваете запрос на основе определенных условий, существует высокая вероятность того, что многим придется упорядочивать те же самые условия.
Да, но это довольно сложно…
Добавьте в functions.php вашей темы:
Это Франкенштейн из некоторых найденных вещей и некоторых вещей, которые я сделал сам. Объяснить это довольно сложно, но суть в том, что при выполнении этого задания вы можете указать ?orderby=(taxonomy query var)&order=ASC (или DESC), и она сразу же уйдет!
Я опаздываю в эту игру, но есть более простой, более WordPress-способ сделать это.
Создайте свой налоговый запрос, как обычно.
Настройте аргументы для query_posts или WP_Query.
Прежде чем сделать вызов query_posts/WP_Query, подключитесь к фильтру orderby и переопределите его.
не забудь потом вынуть фильтр…
это работает, потому что tax_query создает для вас соединения и т. д., вам просто нужно заказать одно из полей соединения.
Я не уверен, почему все решения здесь в значительной степени переполняют его. Хорошо, это было полвека назад, но сейчас я просто запускаю следующий код, и он работает:
Это отсортирует таксономии вашего CPT сначала по таксономии в алфавитном порядке, а внутри этих групп таксономии также по алфавитному порядку.
Что ж, я хотел бы поделиться своим опытом сортировки пользовательских типов сообщений по категориям/таксономии.
ПАУТИНА
ДЕЛО
На страницах списка архивных категорий клиент хотел, чтобы сообщения были отсортированы по
ШАГИ
Во- первых, я перехватываю запрос из немодифицированного запроса страницы архива, который выглядит следующим образом:
Во- вторых, я отредактировал код sql в Sequel Pro для базы данных, чтобы он соответствовал моим потребностям. Я получаю это (да, возможно, это можно улучшить: мои знания о MySQL не являются выдающимися):
В- третьих, я подцепил запрос к файлу functions.php с тремя фильтрами: posts_fields, posts_join и posts_orderby.
Код в functions.php:
Наконец, я активировал фильтры из хука pre_get_post в соответствии с некоторыми условиями.
Надеюсь, это может помочь кому-то
У меня была очень похожая проблема, с которой я столкнулся: я хочу заказать пользовательский архив типа поста (журнальные статьи) по пользовательской таксономии (проблемы). Я никогда не выполняю прямые SQL-запросы на своем сайте, и обычно, если вам нравятся эти другие ответы, вам нужно переосмыслить свой подход.
ПРОБЛЕМЫ:
1) WordPress не позволяет разумно упорядочивать таксономии.
2) WordPress просто не позволяет
orderby
использовать таксономии в пост-типе WP_Query (как указано Отто).РЕШЕНИЯ:
1) На данный момент сортировку таксономий лучше всего выполнять с помощью плагина Custom Taxonomy Order NE. Это позволяет вам упорядочивать таксономию через WYSIWYG
wp-admin
, что я бы не сделал, но я не нашел ничего лучше.Когда вы настроите плагин, вы получите что-то похожее на то, что я сделал здесь. Обратите внимание на опцию
Auto-sort Queries of this Taxonomy
— установите для нее значениеCustom Order as Defined Above
; это дает вам заказ, который вам нужен. Снимок экрана:2) Имея отсортированную таксономию, теперь вы можете создавать серию вызовов WP_Query, которые проходят через каждый термин, эффективно создавая архив, упорядоченный по таксономии. Используйте
get_terms()
для создания массива всех налоговых терминов, затем выполнитеforeach
над каждым термином. Это создает элементWP_Query
для каждого термина, который будет возвращать все сообщения для данного термина, эффективно создавая архив, упорядоченный по термину таксономии. Код, чтобы это произошло:Связанное чтение на этом сайте: Отображение всех сообщений в пользовательском типе сообщений, сгруппированных по пользовательской таксономии.
Вот решение, которое я использовал для этой конкретной проблемы. Это решение предназначено для крайних случаев, когда невозможно использовать
pre_get_posts
фильтр и существует разбиение на страницы в запросе (например, WooCommerce):Я использовал это для создания навигационного меню, упорядоченного по таксономии, термину и количеству сообщений за термин.
Если вам просто нужны сообщения, измените запрос на
SELECT p.*
иGROUP BY p.ID
Мне нравится сортировать термины вручную, поэтому для этого я использую плагин. и я поклонник
pre_get_posts
фильтра, поэтому я взял правильный рабочий пример Дрю Гурли и заставил его работать с ним. так что это какой-то особый случай, но я все равно публикую это, на случай, если это кому-то поможет. следующий код входит в functions.php или пользовательский плагин.сначала давайте начнем с фильтра. мы упорядочиваем пользовательский тип сообщения
music
по пользовательской таксономииstyle
затем мы вызываем фильтр post_clauses:
теперь все, что вам нужно сделать, это отсортировать ваши таксономии с помощью следующего плагина: Simple Custom Post Order. Этот плагин является обязательным для этого решения, так как он добавляет столбец
term_order
в базу данных!и эта строка здесь:
$clauses['orderby'].= ", {$wpdb->posts}.post_name ASC"
упорядочивает сообщения по заголовку, поэтому полная сортировка приведенного выше решения такова: термин таксономии => заголовок сообщения.Довольно простой способ сделать это — добавить функцию, которая говорит:
А затем в своем цикле упорядочите свои сообщения по этому мета-значению.
Так:
Затем в своем запросе WP добавьте в свои $args:
Это работает, если вы можете найти способ ограничить пользователей назначением только одной категории для каждого сообщения или если ваши категории являются взаимоисключающими. Однако, если они назначат более одной категории, пост будет исключен из одной из них.
Это похоже на запрос перед запросом, но не будет беспокоить, если мы не запрашиваем слишком много сообщений… Идея состоит в том, чтобы изменить основной запрос, чтобы нам даже не нужно было переходить к шаблонам и генерировать новые запросы и петли…