WordPress сортировка query post

query_posts() — модификация основного цикла

Когда я писал про циклы, я говорил, что если хотите как-то «по-особому» вывести записи, например в случайном порядке, используйте query_posts() .

Итак, query_posts() видоизменяет основной цикл WordPress, то есть, если раньше на главной показывались последние 10 записей с блога, то теперь там может показываться что угодно и сколько угодно.

Обычные примеры

Этот код выведет заголовки всех записей из рубрики с >

Как и в случае с wp_list_categories(), параметры можно указывать в скобках, а можно выносить в отдельную переменную-массив (кстати, советую использовать именно двойные кавычки, как в примере).

Выводим записи из всех рубрик кроме и >

Выводим записи, опубликованные в текущем месяце.

Записи из рубрики с опубликованные в текущем месяце и отсортированные по заголовкам (в алфавитном порядке) по возрастанию:

Примеры с модификацией основного цикла страницы

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

Сортируем посты на странице по имени:

Тот же самый пример, но только через массивы:

Вы наверное понимаете, что таким образом можно вытворять всё, что угодно, например сортировать товары по цене (и по возрастанию и по убыванию).

P.S. в самой документации WordPress не рекомендуется использовать несколько query_posts() на странице, они говорят, что это приводит к багам, хотя лично я ничего такого не замечал.

Впервые познакомился с WordPress в 2009 году. Организатор и спикер на конференциях WordCamp. Преподаватель в школе Нетология.

Пишите, если нужна помощь с сайтом или разработка с нуля.

Комментарии — 31

Привет Миша! Помоги решить задачу.
На главную нужно вывести из трех кат.(например с по три записи(c как осуществить, что удалить может. Спасибо.

Привет!
пришли мне плиз код по скайпу или по почте, что-то у меня тут листинги в комментах косячат

скинул в скайп и в вк, тихо)

тихо, потому что я спать пошел, гг)

Здравствуйте.
Собственно, ситуация следующая.
На главной странице использую плагин для пагинации — PageNavi, все работает корректно.
Сейчас создал свою страницу для одной из категорий, и решил подключить стандартную пагинацию, т.к. шаблоны страниц слегка отличаются.

На сайте ограничение стоит на 10 записей, всего в базе — 12.
Пагинация выводит три номера страницы и дублирует одни и те же записи.

В чем может заключаться проблема?

Добрый день!
Если у вас в настройках сайта стоит 10 записей, а выводится другое количество, это значит, что в цикле параметр posts_per_page переопределяется, вам нужно найти где.

Спасибо большое! Нашел, где идет перераспределение) Одна лишняя страница исчезла, но осталась ещё одна, которая дублирует записи на предыдущей странице.
В базе — 12 записей, она дубликатом выдает 20.

Какой здесь подвох? Безумно буду благодарен за совет!)

Может как-то циклом задать, что если нет постов, не дублировать предыдущие записи?

Проблема найдена! И она крылась намного глубже)) Дело даже не в posts_per_page, как оказалось, wp_query был лишним и вызывал сбой в работе.

Михаил, огромное Вам спасибо за наводку. И огромное спасибо за ресурс и статьи!

Пожалуйста! я рад, если смог помочь 🙂

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

// далее идёт цикл

сама навигация отображается, но при клике на ссылку второй страницы вижу 404 (
есть решение?

сам спросил и сам отвечу )
временно вопрос решил через функцию:

но глобально вопрос остался
если будет опубликовано больше 4х статей, то система обрежет лишнее (

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

но глобально вопрос остался
если будет опубликовано больше 4х статей, то система обрежет лишнее (

Разве?
По-моему вы уже нашли решение через pre_get_posts ?

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

Разделить по дням? А почему не используете архивы по дням?
Например http://сайт/2015/02/18 ?

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

Добрый вечер, я вот в wpmag прочитал что query_posts нежелательно использовать т.к. она заменяет основной цикл и что вроде могут быть ошибки. Могут быть с этой функцией проблемы?

Добрый вечер!
По сути с любой функцией могут 🙂 Что касается query_posts() , то просто следует знать, где её нужно использовать, а где нет.

Если вы скажите, для каких целей вы хотите её задействовать, я могу вам подсказать — нужно или нет 🙂

Миша, это снова я.
Напомню. На вордпрессе создана произвольная таксономия, сделана страница архива этой таксономии, скажем, taxonomy-nane.php.
Нужно написать код, который сделает так, чтобы на странице архива не выводились ссылки на посты, принадлежащие дочерним таксономиям (подтаксономиям).
мне вот тут посоветовали вот так код построить:
сначала вот это:

потом тайтлы, контенты
а потом вот это

куда я только это не втыкал. либо белая страница, либо без результата.
что-же не так то.

Окей, по порядку.

1. query_posts() .
Нужен именно он. В самом начале файла:

вероятно, я не знаю каких-то основ, но я пишу вот это

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

Через обычный while ?

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

Привет, Михаил. Дублирую из скайпа вопрос:

В купленной мной теме есть файл портфолио, которое выводит все записи из избранной рубрики. Так же в нем организован фильтр, который переключает записи по подрубрикам для удобства. Это портфолио я приспособил под каталог. Изначально было предусмотрен вывод 60 записей в виде плитки по три в ряд, что вполне смотрибельно. Но в моем каталоге около 200 записей, так что страница долго загружается и имеет длинную прокрутку.

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

Так что сейчас задача такая:

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

Источник

Аргументы WP_Query: статус, порядок и пагинация

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

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

Вспоминаем, как работают аргументы в WP_Query

Когда вы используете WP_Query в собственных темах оформления или плагинах, приходится включать в код четыре основных элемента:

• Аргументы для запроса, в которых используются параметры;
• Сам запрос;
• Цикл;
• Завершающий этап: сброс данных записи.

На практике это выглядит следующим образом:

Аргументы сообщают WordPress , какие данные нужно извлекать из базы данных. Давайте сосредоточим внимание на самом начале кода:

Как видно, аргументы заключены в массив.

Создаем код для аргументов

Существует определенный синтаксис инициализации аргументов в массиве:

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

Параметры статуса

Как вы знаете, WordPress задает каждой записи отдельный статус. Можно использовать параметр post_status для запросов записей с одним или несколькими статусами.

Доступны следующие аргументы:

• publish : опубликованная запись или страница;
• pending : запись ожидает рассмотрения;
• draft : запись в статусе черновика;
• auto-draft : только что созданная запись, без какого-либо контента;
• future : запланированная запись;
• private : запись не видна посетителям, которые не авторизовались на сайте;
• inherit : измененная версия записи или статус для прикрепленных записей;
• trash : запись находится в корзине;
• any : запрашивает любой статус, за исключением тех, у которых параметр ‘exclude_from_search’ выставлен на true ( например , auto-draf t или trash ).

Если вы не укажете статус в аргументах вашего запроса, WordPress по умолчанию будет ориентироваться на publish ; если пользователь авторизован на сайте, то в запросе также будут учитываться записи со статусом private . Если вы запускаете запрос от имени администратора, то WordPress также будет учитывать защищенные статусы: future , draft и pending .

Предположим, что у вас есть сайт-афиша, на котором используется собственный тип записей event , и в качестве даты публикации используется дата, на которую запланировано то или иное мероприятие. По умолчанию, WordPress не будет отображать еще не состоявшиеся события. Несмотря на то, что вы запланировали, дата публикации находится в будущем, а, значит, статус записи будет future .

Чтобы обойти эту проблему, можно использовать следующие аргументы:

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

Параметр post_status важен при осуществлении запросов к вложениям, потому что используется статус inherit , а не publish . Чтобы осуществить запрос всех вложений, можно использовать следующий код:

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

Параметры сортировки

Существует два параметра, которые можно использовать для сортировки записей, полученных при помощи WP_Query : order и orderby . Как вы уже поняли, order определяет порядок, в котором записи выводятся в цикле, а orderby определяет, по какому полю в базе данных они будут сортироваться.

Параметр order

Есть всего аргумента, которые можно использовать для сортировки:

• ASC : по возрастанию ( 1, 2, 3; a, b, c ).
• DESC : по убыванию ( 3, 2, 1; c, b, a ).

Если вы не включите аргумент для order, по умолчанию WordPress будет использовать DESC .

Параметр orderby

Вы можете сортировать записи по нескольким полям:

• none : нет условий сортировки ( доступно с версии 2.8 );
• ID : сортировка по id записи. Не забывайте про верхний регистр;
• author : сортировка по автору;
• title : сортировка по заголовку;
• name : сортировка по slug записи;
• type : сортировка по типу записи;
• date : сортировка по дате;
• modified : сортировка по последней дате изменения;
• parent : сортировка по id родительской записи/страницы;
• rand : случайный порядок;
• comment_count : сортировка по количеству комментариев;
• menu_order : сортировка по порядку расположения страниц. Наиболее часто используется для страниц ( здесь используется значение, которое указывается в мета-блоке при редактировании страницы ), а также для вложений ( используется целое число из диалогового окна Вставка / Загрузить медиафайл ). Также можно использовать для любого типа записи с включенным параметром menu_order ;
• meta_value : сортировка по значению мета-ключа или пользовательского;
• поля : Будет работать только в том случае, если установлен параметр meta_key . Мета-значения сортируются по алфавиту, а не по числам ( то есть 34 выведется раньше цифры 4 );
• meta_value_num : сортировка по числовому мета-значению. Как и в случае с meta_value , в запросе должен использоваться аргумент meta_key ;
• post__in : сохраняет сортировку по ID записей, выставленную в массиве post__in .

По умолчанию, для сортировки используется поле date . То есть, сортируется по дате публикации.

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

Сортировка по нескольким полям

Чтобы отсортировать записи по нескольким полям, нужно воспользоваться массивом с параметром orderby и с параметром order , если нужна сортировка каждого поля в разном порядке.

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

Я включила в запрос аргумент meta_key , и это позволит WordPress понять, какое произвольное поле мы используем. Это нужно делать именно потому, что WordPress хранит метаданные записей в таблице wp_postmeta , а не в wp_posts .

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

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

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

Параметры пагинации

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

Доступны следующие параметры:

• nopaging ( boolean ) : отображать все записи или использовать пагинацию. По умолчанию выставлено значение ‘false’ , то есть, используется постраничный вывод;
• posts_per_page ( int ) : количество записей на странице;
• posts_per_archive_page ( int ) : количество записей на странице, но только на странице архива;
• offset ( int ) : количество записей, после которого начинается вывод;
• paged ( int ) : страница в архиве, из которого выводятся страницы;
• page ( int ) : количество страниц для статичной главной страницы. Отображение записей, которые должны в обычном режиме показываться только на странице Х при включении статичной главной страницы ( Front Page );
• ignore_sticky_posts ( boolean ) : игнорируем прикрепленные записи. По умолчанию используется значение false .

Количество записей и пропуск записей

Чтобы показать пять самых свежих записей, используем следующий код:

Показываем пять самых свежих записей, за исключением самой последней опубликованной:

Учтите, что, несмотря на то, что вы извлекаете записи из шести последних записей в базе данных, вы по-прежнему используете ‘posts_per_page’ => ‘5’ , так как именно такое количество записей должно быть отображено.

Можно создать два запроса: один для отображения самых свежих записей, а второй – для отображения еще 10 записей, за исключением той записи:

Для отображения всех записей можно использовать posts_per_page :

Прикрепленные записи

Обычно прикрепленные записи отображаются первыми в любом запросе. Если нужно переопределить эту установку, то воспользуйтесь параметром ignore_sticky_posts :

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

Если нужно отобразить только прикрепленные записи, то нужно использовать функцию get_option() и аргумент post__in следующим образом:

Приведенный выше код позволит получить пять последних прикрепленных записей. Если их будет меньше пяти ( например, три ), то будет выведено только доступное количество прикрепленных записей.

Пагинация в архивах

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

К примеру, следующий код можно использовать на странице архива, чтобы вывести по 20 записей на каждую страницу:

Примечание: аргумент posts_per_archive_page переопределяет posts_per_page .

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

Также можно использовать аргумент offset :

Этот запрос пропустит 40 записей, которые расположены на первых двух страницах архива, и извлечет следующие 20 ( с третьей страницы ).

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

В завершение

Класс WP_Query является достаточно гибким с точки зрения определения количества записей для запроса, их сортировки и статуса.

Некоторые аргументы удобно использовать в запросах к определенным типам записей. Например, аргумент ‘post_status’ => ‘inherited’ при работе с вложениями. А с помощью остальных можно контролировать выполнение самих запросов.

Сергей Бензенко автор-переводчик статьи « WP_Query Arguments: Status, Order and Pagination »

Источник