WordPress get posts: get_posts() – Получает записи (посты, страницы, вложения) из базы данных по указанным критериям.

Получить любые сообщения с помощью WP_Query. WordPress загружает последние 10… | от Прасана | Timeless

WordPress загружает последние 10 сообщений на главной странице и правильные сообщения на страницах архива. Что, если вы хотите отсортировать все свои сообщения и страницы по дате?

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

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

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

Мы создаем новый запрос WordPress, используя класс WP_Query , передавая ему параметры, чтобы указать типы необходимых сообщений. Затем мы вызываем have_posts() и методы the_post() для нашего объекта $scheduled.

Некоторые аргументы довольно просты, например, параметр tag или tag_id . Первый принимает слаг тега, второй — идентификатор тега. Вы также можете разделить несколько элементов запятыми или использовать отрицательные идентификаторы, чтобы указать, что вы хотите получать сообщения, к которым не прикреплен этот конкретный тег.

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

author, author_name, cat, category_name, s (для условий поиска), post_status, post_type являются примерами некоторых более простых полей. Обратите внимание, что некоторые поля, такие как post_status , требуют передачи массива статусов, если вы хотите использовать несколько значений.

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

Для простых вещей достаточно использовать упомянутые аргументы для извлечения сообщений на основе категорий или тегов, но что, если у вас есть пользовательская таксономия или вам нужно объединить несколько параметров? Ответ кроется в аргументе tax_query , который сам по себе является массивом. Сначала рассмотрим пример.

Здесь мы получаем несколько сообщений из нашего типа «книга», добавляя некоторые параметры таксономии. Параметр отношения определяет отношение между двумя массивами. В нашем случае это отношение «и», означающее, что должны быть выполнены оба условия.

Даты могут быть немного сложными, но очень гибкими. В документации WP_Query есть множество примеров, если вам нужна дополнительная информация.

Получить сообщения за определенное время довольно просто. Вы можете использовать год, номер месяца, w (неделя года), день , и пару других параметров, чтобы указать время. Приведенный ниже код извлечет все сообщения за май 2014 года.

Если вы хотите получить более сложные временные диапазоны, вам нужно использовать дата_запрос . Это позволяет довольно легко указывать произвольные диапазоны, используя знакомый формат массива. В следующем примере показано, как вы можете получить сообщения, написанные между 9:00 и 17:00 в будние дни.

Попробуйте этот материал на своем сайте WordPress и ответьте ниже, если у вас есть вопросы по нему.

Выбор правильного запроса для разработки WordPress

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

Какой бы ни была ваша цель, вы решили создать собственный шаблон страницы с запросом, который делает что-то немного другое. Однако, прежде чем вы начнете программировать, вам нужно принять решение: какой инструмент запросов WordPress вы должны использовать?

WordPress включает в себя несколько разных запросов: WP_query , query_posts() , get_posts() , get_pages() и pre_get_posts . Во многих случаях для достижения желаемых результатов можно использовать более одного из этих инструментов. Однако остается вопрос, что на

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

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

• WP_Query
• pre_get_posts
• запрос_сообщений ()
• get_posts()
• get_pages()
• Применение теории на практике

Давайте сразу к делу.

WP_Query — это класс, стоящий за (почти) каждым запросом WordPress. Когда вы загружаете страницу или сообщение в WordPress, создается объект WP_query , $query , который извлекает соответствующие данные сообщения или страницы. Подумай о WP_Query как механизм, который поддерживает большинство запросов WordPress.

Вы используете WP_Query , даже не подозревая об этом. Когда вы загружаете URL-адрес, ядро ​​​​WordPress создает запрос к базе данных с WP_Query на основе URL-адреса и настроек, которые вы применили к своему веб-сайту. Таким образом, если вы обращаетесь к странице с URL-адресом, например http://example.com/category/wordpress , WordPress создает объект WP_Query , который находит все сообщения в WordPress 9.0024 и загружает все данные сообщения.

WP_Query поддерживает стандартные запросы записей и страниц, встроенные в WordPress, а также может использоваться для создания пользовательских запросов. Это делается с помощью объектно-ориентированного программирования. Все, что вам нужно сделать, это создать новую переменную и объявить ее как новый экземпляр класса WP_Query , например: запрос. Однако это выходит за рамки этого урока. Вместо этого обратитесь к списку руководств в конце этого поста, если вам нужна помощь в установке WP_Query на практике.

Как разработчик WordPress вы, вероятно, будете использовать WP_Query чаще, чем любую другую функцию запроса или хук. Он универсальный и мощный. Хотя некоторые другие запросы, описанные в этом посте, в некоторых случаях могут сэкономить вам несколько нажатий клавиш, в целом вы не ошибетесь, выбрав WP_Query для своих нужд написания пользовательских запросов.

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

pre_get_posts

pre_get_posts — это хук, а не функция. Вместо того, чтобы запрашивать базу данных заново, pre_get_posts позволяет изменять объект $query до того, как будет сделан запрос к базе данных, эффективно фильтруя результаты, возвращаемые стандартным запросом.

В большинстве случаев pre_get_posts сочетается с условными тегами для фильтрации результатов запроса в определенных ситуациях. Например, вы можете использовать

pre_get_posts , чтобы вернуть другое количество сообщений на главной странице сайта. По сути, если вы хотите запустить стандартный запрос, но каким-то образом изменить его, pre_get_posts — это инструмент для этой работы.

В некоторых случаях pre_get_posts не работает и не должен использоваться. Кодекс WordPress предлагает два таких экземпляра:

• Фильтр pre_get_posts не следует использовать для изменения запроса в шаблоне для одной страницы, поскольку это будет мешать свойствам, уже установленным parse_query() .
• Фильтр pre_get_posts не будет работать, если к шаблону добавлены такие файлы, как archive.php , поскольку эти файлы загружаются после того, как основной запрос уже запущен.

Что нам остается? Это означает, что pre_get_posts — отличный выбор для изменения запроса загрузки сообщений в основной цикл домашней страницы, страницы блога и отдельных страниц, таких как page.php и single.php .

Однако иногда фильтрации стандартного запроса недостаточно. Возможно, вы хотите использовать несколько запросов WordPress или манипулировать результатами запросов способом, который не позволит

pre_get_posts . В этом случае вы можете вернуться к WP_Query или прочитать о нескольких дополнительных параметрах.

query_posts()

Если вы покопаетесь в учебниках WordPress, выпущенных несколько лет назад, вы найдете множество руководств, рекомендующих использовать query_posts() . Однако современные учебники почти повсеместно не рекомендуют этого делать. Вот почему.

Функция query_posts() заменяет основной объект запроса,

$query , который создается и используется циклом по умолчанию, запускаемым ядром WordPress. Он делает это, создавая новый экземпляр WP_Query и назначая его объекту $query .

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

В официальном справочнике по коду WordPress приводится несколько причин, по которым в подавляющем большинстве случаев следует избегать использования query_posts() .

Основные причины, приведенные для этого, включают:

• Использование query_posts() может значительно замедлить время загрузки страницы, увеличив вдвое объем работы, необходимой для обработки запроса.
• Начиная с query_posts() заменяет стандартные данные запроса, это может вызвать множество проблем с нумерацией страниц и нанести ущерб страницам, которые используют несколько запросов.

Короче говоря, использование query_posts() — опасное предложение. На самом деле официальная документация начинается с оговорки: Эта функция полностью переопределит основной запрос, а не предназначена для использования плагинами или темами

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

WPMU DEV AccountPRO

Наши лучшие профессиональные инструменты WP в одном комплекте

Попробуйте бесплатно в течение 7 дней

30-дневный возврат денег

это именно то, что делает подавляющее большинство из нас — избегайте использования query_posts() . Вместо этого создайте совершенно новый объект WP_Query или используйте вместо него get_posts() , get_pages() или pre_get_posts .

get_posts()

Думайте о функции get_posts() как о модифицируемом, предопределенном экземпляре класса WP_Query , потому что это именно то, чем оно является. Когда вы используете get_posts() , вы фактически вызываете предустановленные значения по умолчанию и используете их для создания экземпляра класса WP_Query .

В каком-то смысле get_posts() очень похоже на query_posts() : они оба являются предопределенными экземплярами WP_Query . Однако они также сильно отличаются, потому что query_posts() заменяет объект $query по умолчанию , а get_posts() просто создает совершенно новый запрос, который не взаимодействует с глобальными переменными, как это делает query_posts() . .

Итак, какой смысл использовать get_posts() ? Почему бы просто не использовать WP_Query ? Ответ — удобство. Если вы думаете об использовании get_posts() , вы определенно можете выполнить все, что вы пытаетесь выполнить с помощью WP_Query . Однако, используя get_posts() , вы экономите несколько нажатий клавиш.

Есть еще одно различие между WP_Query и get_posts() . То есть последний возвращает массив сообщений, а первый возвращает сообщения по одному с помощью функции the_post() . Это означает, что get_posts() возвращает все сообщения сразу в виде массива, в то время как WP_Query перебирает сообщения по одному, отображая соответствующий контент каждого сообщения по мере его повторения. На практике это означает, что при использовании get_posts() вы используете функцию foreach для отображения результатов, но вы используете стандартную структуру цикла if. ..while для вывода содержимого при использовании WP_Query .

Еще одна вещь, о которой следует помнить, это то, что, поскольку get_posts() не изменяет глобальный объект $query , вам необходимо использовать setup_postdata() для каждого сообщения, чтобы получить доступ к методам и свойствам WP_Query . Хотя это может показаться сложным, на самом деле это не так. Посмотрите:

Загрузка gist jpen365/67592c6e5f70553692a002fea13da63f

Таким образом, этот фрагмент кода вернет четыре сообщения из категории слайдера (предположительно, чтобы отобразить их в слайдере сообщений). Во-первых, мы убеждаемся, что запрос вернул что-то с кодом if ( $slider_posts ) , а затем прокручиваем сообщения, отображающие заголовок и содержание. Используя setup_postdata() , мы можем использовать глобальные переменные, такие как $id и $authordata , а также теги шаблона, такие как the_title() и the_content() . Без настройки данных публикации мы не смогли бы использовать эти переменные и теги шаблона.

get_pages()

Одной из функций запроса, которой не уделяется много внимания, является запрос get_pages() . В отличие от всех других запросов в этом посте, которые так или иначе связаны с WP_Query , get_pages() — это функция, которая обходит WP_Query 9.0072 и напрямую запрашивает базу данных.

Подобно get_posts() , эта функция возвращает содержимое, найденное в массиве. Однако, в отличие от get_posts() , который можно использовать для извлечения любых сообщений любого типа (сообщений, страниц, пользовательских типов сообщений и т. д.), get_pages() можно использовать только для получения иерархических типов сообщений. такие как страницы и иерархические пользовательские типы сообщений.

Кроме того, get_pages() позволяет указать несколько параметров запроса, уникальных для иерархических типов записей, включая 'child_of' , 'родительский' и 'иерархический' . Доступ к этим параметрам является основной причиной, по которой вы можете рассмотреть возможность использования этого конкретного запроса.

Применение теории на практике

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

• Подробное руководство по преодолению WP_Query
• Объяснение цикла WordPress
• Как расположить записи WordPress в любом порядке
• Разработка WordPress для пользователей среднего уровня: запросы и циклы
• 5 простых методов создания пользовательских запросов в WordPress

Резюме

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

• WP_Query : универсальный класс, который поддерживает большинство запросов WordPress. Он гибкий и может использоваться для создания любого типа запроса.
• pre_get_posts : хук, который можно использовать для уточнения объекта $query перед запросом к базе данных, тем самым безопасно изменяя запрос по умолчанию. Используйте его вместе с условными тегами для уточнения результатов стандартного запроса.
• query_posts() : мощный экземпляр WP_Query , который заменяет объект $query по умолчанию и не предназначен для разработки тем или плагинов. Не используйте его.
• get_posts() : экземпляр класса WP_Query , который возвращает массив сообщений. Он включает в себя ряд значений по умолчанию, которые могут сэкономить вам несколько нажатий клавиш по сравнению с созданием собственного экземпляра WP_Query , но только в том случае, если параметры по умолчанию соответствуют вашим потребностям.