• сейчас вот так:

    $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()

    • Тема изменена 3 месяца, 4 недели назад пользователем svg.
    • Тема изменена 3 месяца, 4 недели назад пользователем svg.
    • Тема изменена 3 месяца, 4 недели назад пользователем svg.
    • Тема изменена 3 месяца, 4 недели назад пользователем svg.
Просмотр 15 ответов — с 1 по 15 (всего 23)
  • сортировку по какому параметру вы собираетесь делать?

    Задача:

    свой тип записи «шина» , таксономия «тип шины», значение «рулевая», «ведущая» ….. Нужно менять порядок вывода записей. Думал по-простому: поставлю циферки порядка в описании значения таксономии («ведущая», к примеру, 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.
Просмотр 15 ответов — с 1 по 15 (всего 23)

Для ответа на тему необходимо авторизоваться.