Используя wp_query это возможно к orderby таксономии?

Мой вопрос прост, я использую WP_Query получать некоторую пользовательскую фильтрацию сообщений типа по использованию таксономии tax_query.

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

orderby в WP_Query позволяет Вам заказать набором полей даже пользовательские meta поля, но это, кажется, не поддерживает таксономию.

Какие-либо указатели в правильном направлении?

Спасибо всем.

50
20.01.2020, 23:08
3 ответа

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

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

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

Править: Тем не менее можно заказать таксономией путем создания пользовательского SQL-запроса с помощью фильтра, Вы просто не можете сделать этого от неизмененного WP_Query: http://scribu.net/wordpress/sortable-taxonomy-columns.html

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

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

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

15
19.02.2020, 21:53
  • 1
    Привет Otto, спасибо за ответ. Я вижу Вашу точку, и возможно я иду неправильным путем с этим. В моем примере сайт сериалов у меня есть таксономия для серии 1, serie 2, serie 3 и т.д. Таким образом, я могу сгруппировать все различные сериалы серийным числом. Затем у меня есть то же для эпизодов, Эпизода 01, Эпизода 02, и т.д. То, что я хотел бы, при показе списка всех эпизодов, чтобы быть порядком эпизодом и serie. Я проанализирую затем сообщение meta и пользовательские поля. Спасибо Otto. спасибо –  yeope 08.04.2011, 19:35
  • 2
    @yeope Ваша таксономия должна быть рядом и Вашими условиями, должен быть серией 1, серия 2 и т.д. С эпизодами я предполагаю, что ряд содержит несколько эпизодов, таким образом, он мог использовать ту же таксономию, "ряд" и если бы они - hierarchal затем эпизод 1, эпизод 2 и т.д. имел бы родительский термин "серией x". Затем Вы могли запросить целый ряд в порядке с эпизодами, падающими в строке, где они должны. идентификатор –  Chris_O 08.04.2011, 22:17
  • 3
    @Chris_O, который я вижу, Вы могли бы быть на деньгах там! Единственной проблемой, которую я вижу, является факт необходимости повторить условия "Эпизод 1", "Эпизод 2" для каждого ряда. Также не будучи способен группировать все эпизоды 1 не в зависимости от ряда, но я думаю, что существует, вероятно, путь вокруг этого. Спасибо спасибо Chris_O –  yeope 09.04.2011, 01:26
  • 4
    Используя таксономию для эпизодов не имеет большого смысла, на самом деле, потому что группировка бесполезна. Думайте об этом, если у Вас есть "эпизод 1" как термин, затем Вы группируете эпизод 1 с любым эпизодом 1 из любого сериала. Эпизод и серийные числа имеют больше смысла как post_meta, потому что они характерны для того конкретного шоу и не полезны как группа. Название сериала было бы полезно как термин в таксономии сериала, потому что затем Вы группируете шоу в целом вместе. –  Otto 15.04.2011, 22:28
  • 5
    Otto развил это с интересным сообщением в блоге: Когда (не) использовать Пользовательскую Таксономию. –  Jan Fabry 05.05.2011, 09:55

Да, но это довольно включено...

Добавьте к functions.php в своей теме:

function orderby_tax_clauses( $clauses, $wp_query ) {
    global $wpdb;
    $taxonomies = get_taxonomies();
    foreach ($taxonomies as $taxonomy) {
        if ( isset( $wp_query->query['orderby'] ) && $taxonomy == $wp_query->query['orderby'] ) {
            $clauses['join'] .=<<<SQL
LEFT OUTER JOIN {$wpdb->term_relationships} ON {$wpdb->posts}.ID={$wpdb->term_relationships}.object_id
LEFT OUTER JOIN {$wpdb->term_taxonomy} USING (term_taxonomy_id)
LEFT OUTER JOIN {$wpdb->terms} USING (term_id)
SQL;
            $clauses['where'] .= " AND (taxonomy = '{$taxonomy}' OR taxonomy IS NULL)";
            $clauses['groupby'] = "object_id";
            $clauses['orderby'] = "GROUP_CONCAT({$wpdb->terms}.name ORDER BY name ASC) ";
            $clauses['orderby'] .= ( 'ASC' == strtoupper( $wp_query->get('order') ) ) ? 'ASC' : 'DESC';
        }
    }
    return $clauses;
}

    add_filter('posts_clauses', 'orderby_tax_clauses', 10, 2 );

Это - frankensteined от некоторого найденного материала и некоторого материала, который я сделал самостоятельно. Объяснение довольно жестко, но нижняя строка с этим выполнением, можно ли поместить? orderby = (var запроса таксономии) &order=ASC (или DESC) и она возьмет сразу же!

15
19.02.2020, 21:53
  • 1
    Потянуло, я дам движение и попытку выполнить тот SQL, должен отредактировать немного, но это могло бы работать. Моя единственная проблема теперь, я мог бы идти на неправильные направления, как указано Otto. Спасибо Потянуло. РЕДАКТИРОВАНИЕ - Никакая потребность отредактировать I не видит, где ему нужна тонкая настройка :) Спасибо –  yeope 08.04.2011, 19:45
  • 2
    При захвате его в течение прошлых двух минут это не будет работать, идти вперед и захватывать его теперь, я зафиксировал его. Это было установлено для двух определенных taxonomies, я улучшился, код для работы над всеми зарегистрировал taxonomies. –  Drew Gourley 08.04.2011, 19:48
  • 3
    еще раз. На всякий случай я попробовал Ваше решение и это вид работ. Также, если кто-то еще хочет использовать его, необходимо измениться add_filter('posts_clauses', 'orderby_tax_clauses', 10, 2 ); кому: add_filter('posts_clauses', 'todo_tax_clauses', 10, 2 ); Поблагодарите Вас :) –  yeope 09.04.2011, 01:29
  • 4
    Да, это теперь фиксируется в блоке кода, я взял это из проекта, я продолжаю работать и забыл менять имя функции даже при том, что я изменил его в рычаге. –  Drew Gourley 09.04.2011, 09:39
  • 5
    Вы знаете, возможно ли заказать taxonomies идентификатором вместо имени? Я пытаюсь получить тот же результат, приказывая группы таксономии идентификатором –  Javier Villanueva 17.07.2013, 01:43

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

Рассмотрите наличие типа сообщения меню. Затем у Вас есть пользовательский налог "FoodCategories". Налог FoodCategories завтракает, "Ланч" и условия "Ужина". При представлении запроса, использующего tax_query параметрический усилитель у Вас теперь есть набор результатов со всеми условиями, однако им заказывает дата сообщения.

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

Было бы хорошо, если бы WP имел "налог __ в" orderby опция, поскольку это делает "сообщение __ в" одном, но так как это не делает, Вы любой должен сделать вышеупомянутый смешной процесс; настройте запрос сами посредством фильтра 'posts_orderby' и фильтра 'posts_join', чтобы скорректировать orderby метод и добавить термин к набору результатов, соответственно; или необходимо сделать новый запрос для каждого термина, для которого Вы фильтруете в разделах HTML относительно тех условий.

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

49
19.02.2020, 21:53
  • 1
    Извините, но Вы неправы. Упорядочивание таксономией не имеет никакого смысла в Вашем случае также. Что Вы хотите показать? Все Завтраки сначала, сопровождаемый всеми Ужинами, затем всеми Ланчами? Необходимо выбрать то, что Вы хотите и порядок, в котором Вы хотите это, но таксономия является просто группирующейся маркировкой. Это не значимые "данные", которыми необходимо заказывать. Если это, то это не должен быть термин в таксономии, необходимо сделать это post-meta вместо этого. –  Otto 20.10.2014, 14:57
  • 2
    Продвиньтесь, конечно, там будут некоторыми экземплярами, в которых Вы захотите заказать сообщения термином таксономии. Другим примером является тип сообщения Фильма с таксономией Оценки. В списке фильмов очень легко вообразить людей, желающих заказать список фильмов путем оценки так все с рейтингом G, затем с рейтингом PG, и т.д. фильмы появляются наверху. (В этом и примере еды им мог заказать term_id вместо имени.) существует большая серая область экземпляров, где Вы, вероятно, лучше всего обслуживаетесь таксономией и не meta, но, вероятно, также полезно для той таксономии быть упорядочиваемым. –  SeventhSteel 10.03.2015, 22:51
  • 3
    PG и оценки G и такой являются хорошим выбором таксономии, за исключением того, что они - данные об определенных фильмах. Таким образом они - meta. Они - данные, не категории. Просто наличие ограниченного количества выбора не делает таксономии, делают. Если этому нужен вид, то или сделайте это meta или вызовите вид таксономией через таксономию определенный код. BTW, NC17 прибывает после Стр. Так, Вы должны кодировать, чтобы сделать то упорядочивание так или иначе. –  Otto 10.11.2015, 03:05
  • 4
    я знаю, что опаздываю стороне с этим комментарием, но просто врезался в это. Упорядочивание таксономией может иметь смысл в некоторых ситуациях. У нас есть списки заданий на одном проекте как тип сообщения и затем состояние и Город, в котором задание, taxonomies. Мы хотим, чтобы они были легко grupable (покажите все задания в состоянии или покажите все задания в городе), таким образом, таксономия была лучшим решением. В то же время существует общий поиск работы, где мы хотим отсортировать их сначала по заголовку, затем по состоянию, затем по городу. –  Dennis Puzak 23.10.2018, 13:39
  • 5
    Другой вариант использования: у клиента есть набор статей, каждая из которых имеет категорию. Клиент хочет там быть страницей, перечисляющей все статьи, которые могут быть отсортированы в алфавитном порядке, по дате, или по категориям. Категории могут также быть фильтрованы, но перечисляющий все статьи по категориям в алфавитном порядке не является настолько сумасшедшим из варианта использования, и Вы видите, что он открывается довольно часто. –  Wilson Biggs 06.06.2019, 19:06

Теги

Похожие вопросы