Получить descr! таксономии записи в цикле
-
сейчас вот так:
$cur_terms = get_the_terms( $post->ID, 'tip-shina' ); if( is_array( $cur_terms ) ){ foreach( $cur_terms as $cur_term ){ echo $cur_term->description; // description - это описание! } }А покороче можно сделать? Может встроенное что-то есть?
задача: сделать сортировку по этому значению в new WP_Query()
-
сортировку по какому параметру вы собираетесь делать?
Задача:
свой тип записи «шина» , таксономия «тип шины», значение «рулевая», «ведущая» ….. Нужно менять порядок вывода записей. Думал по-простому: поставлю циферки порядка в описании значения таксономии («ведущая», к примеру, 1 ), отсортирую. И не получается что-то.
мета поля записи в момент создания аргументов для WP_Query() есть, а $post->ID почему-то не видно
Нет такой сортировки
хм, странно. Вот здесь https://wordpress.stackexchange.com/questions/14306/using-wp-query-is-it-possible-to-orderby-taxonomy про это пишут. Только вот нигде не сказано как ПРАВИЛЬНО, по-вордпрессовски, а не костылями, решить вроде бы востребованную задачу.
в статье правильно изложено, почему задача не является востребованной. wordpress термы — средство группировки (выбора группы) постов, а не сортировки. иными словами, в вашем случае на странице должна быть не группа шин, а ссылка на эту группу.
В своем случае проблему решил, красиво не получилось, но работает. Но так и не смог понять, почему выведя несколько «групп постов» на одну страницу, невозможно поменять порядок вывода. Группа2, группа1, далее еще сортировка… Статья — подтверждение, что я не один такой дурак, впрочем, как сделать «идеологически правильно» — ни слова…
Идеологически правильно предоставлять пользователю структурированную информацию, а не вываливать все, что у вас есть. В магазинах ведь есть отдельные полки для групп товаров, и здесь то же самое. То есть нужно давать, например, ссылки на группы Рулевая… Ведущая… или фильтровать чекбоксами. А сортировка — это достаточно убогий тип фильтрации. Тем более тематическая сортировка — неизвестно ведь, что важнее посетителю.
Что-то важное от меня ускользает в понимании «таксономия». Не магазин, наоборот, хочу видеть то, что имею, на одном экране/странице. ШИНЫ -тип записи
ШИНА >»0″(это количество), далее сортируем по таксономии «тип»- рулевая там и т.д , далее сортируем по строке(!) размер: 385/65 , 385/55 ….. потом еще немного сортировки. Свои классы css у каждой группы после сортировки. Ну, решил, кучей new WP_Query(). Как-то некрасиво получилось). Оформление — как надо все, а вот куча запросов…
ШИНА =»0″ — делаю то же самое. Только стили оформления другие.
Из всего прочитанного выше делаю для себя вывод: не связывайся с таксономиями. Фильтровать можно, сортировать — НЕЛЬЗЯ
-
Ответ изменён 3 месяца, 3 недели назад пользователем
svg.
посоветуйте, пожалуйста, вариант вывода записей получше
В вашей задаче лучше сделать десять программных, а не запросных сортировок массива, чем один лишний запрос (к базе) WP_Query. Поэтому считываете все, раскладываете в многомерный массив с индексами сортировки, сортируете по индексам, выводите… но решение не работает с пажинатором, в общем случае.
Традиционно в таких случаях советуют кастомные поля, чтобы они в выборке запроса участвовали. Но с ними своя проблема при большой базе постмета. Они при отсутствии индексации в базе данных по значению постмета начинают сильно тормозить запросы к базе.
Повторюсь, у вас прежде всего методологически неверная постановка задачи, на уровне построения витрины магазина… вы на витрину все вываливаете кучей, что мешает сделать выбор. И то, что у вас куча слева направо упорядочена, не сильно улучшает ситуацию. Если разделять кучу, то запросы к базе сильно упрощаются.
У меня не магазин. Сотня записей. Правильная постановка, привычное = удобное отображение отчетов, полная реализация задачи — в MS ACCESS — сделана и отработана. Хочу теперь в WP. Пагинация не нужна. Попробую wpdb использовать, впрочем, сейчас 6 штук WP_Query вроде как работает, даже не тормозит)
Традиционно в таких случаях советуют кастомные поля, чтобы они в выборке запроса участвовали. Но с ними своя проблема при большой базе постмета. Они при отсутствии индексации в базе данных по значению постмета начинают сильно тормозить запросы к базе.
Можно тут поподробней ? Посмотрел в БД, там же ищёт по индексу umeta_id ?
Смотрите, вот структура и индексы таблицы постмета
Видите, meta_value, в котором хранятся обычно данные, по каким вы можете сделать сортировку в запросе, не имеет индекса. Это не просто так, в meta_value обычно хранится такое большое количество вариативных значений, что его индексация не имеет смысла — индексы таблицы распухнут, а скорости выборки/сортировки не добавится. В результате имеем полнотекстовый поиск/сортировку по таблице, и при ее серьезном размере (а она обычно растет быстрее остальных таблиц, и ее размер в несколько гб — это больно) — тормоза при запросе к базе. Поэтому везде, где можно, лучше использовать все-таки таксономии. Ну в вашем случае, если не будете в постмета пихать что попало, если база будет относительно невелика — можно и пренебречь.
Однако, так и не понял. Вывел в одном запросе пару значений одной таксономии, а поменять порядок их вывода — не могу! Как в магазине: в одном отделе(таксономии) — две полки(значение этой таксономии) — и все гвоздями приколочено… Одну полку выше другой поставить нельзя?
-
Ответ изменён 3 месяца, 2 недели назад пользователем
svg.
-
Ответ изменён 3 месяца, 3 недели назад пользователем
Для ответа на тему необходимо авторизоваться.