Освоение WP_Query: введение

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

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

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

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

В этом вступлении я расскажу следующее:

• Что такое WP_Query ?
• Зачем использовать WP_Query ?
• Потенциальные проблемы / что нужно знать.

Что такое WP_Query?

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

Если вы хотите точно понять, как работает WP_Query , вы можете увидеть его код в файле includes/query.php .

WP_Query состоит из четырех основных элементов:

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

На практике это будет выглядеть примерно так:

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

Сброс данных поста

В приведенном выше примере я добавил wp_reset_postdata() после каждого запроса. Это важно, потому что он сбрасывает запрос обратно к основному запросу, выполняемому на этой странице.

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

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

Зачем использовать WP_Query?

Если вы раньше не использовали класс WP_Query , возможно, вам будет интересно, почему вы должны начать. Здесь я собираюсь сосредоточиться на двух аспектах этого: зачем использовать WP_Query над другими методами написания пользовательских запросов, и сценариях, где вы можете использовать WP_Query .

Зачем использовать WP_Query поверх других методов?

WP_Query не единственный метод для создания пользовательского запроса. Есть еще четыре:

• pre_get_posts
• get_posts()
• get_pages()
• query_posts() (чего следует избегать, как я объясню)

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

• pre_get_posts — это хук, который модифицирует основной запрос. Вы можете использовать его с условным тегом, чтобы проверить, просматривается ли страница определенного типа (например, домашняя страница), а затем использовать ее для изменения выполняемого запроса (например, для удаления трех последних сообщений, если вы ‘ повторно отображать их в другом месте на странице). Это очень эффективный способ изменения основного запроса, и он должен быть вашим первым портом захода, если вы этого хотите. Однако вы не можете использовать его для создания совершенно нового запроса.
• get_posts() и get_pages() очень похожи, главное отличие очевидно из их имен. Эти теги шаблона фактически используют класс WP_Query , поэтому они представляют собой еще один способ сделать то же самое, но добавить дополнительный шаг, потому что они вызывают класс WP_Query вместо того, чтобы вы делали это напрямую. Вы можете использовать их только для запроса постов или страниц, в то время WP_Query сам WP_Query является более мощным и позволяет запрашивать практически все, что хранится в вашей базе данных.
• query_posts() изменяет основной запрос, но не должен использоваться в плагинах или темах. Это потому, что он выбрасывает основной запрос и запускается заново, заменяя основной запрос новым запросом. Он также подвержен ошибкам, особенно при разбивке на страницы, неэффективен и влияет на время загрузки страницы. Если вам нужно изменить основной запрос, используйте вместо него pre_get_posts , а если вы хотите создать совершенно новый запрос, используйте WP_Query .

Приведенная ниже диаграмма, выпущенная Андреем «Рарстом» Савченко по лицензии Creative Commons, имеет некоторый смысл:

Когда вы можете использовать WP_Query

Существует много сценариев, когда WP_Query пригодится, и я не могу охватить их все здесь, но вот обзор:

• Добавить список связанных постов под текущим постом — например, список всех постов в той же категории.
• Создать две петли на одной странице: например, страницу часто задаваемых вопросов с заголовками вопросов вверху и содержимым внизу.
• Чтобы создать собственный список последних сообщений на боковой панели или в нижнем колонтитуле вашего сайта, когда виджет «Последние сообщения» не делает то, что вам нужно (или вы предпочитаете кодировать его самостоятельно).
• Для создания пользовательских запросов для таксономий , используя более одной таксономии, чтобы определить, что отображается.
• Для запроса типов записей, которые не выводятся по умолчанию, например вложений .
• Чтобы создать пользовательские страницы с несколькими запросами для разных типов контента, как я сделал на этом примере сайта для клиента.

Некоторые предостережения

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

• Если все, что вы хотите сделать, это изменить способ отображения сообщений для определенного типа контента или архива, не используйте WP_Query . Вместо этого просто создайте файл шаблона для этого архива или типа содержимого и измените цикл в этом файле шаблона.
• Если вы хотите отобразить несколько больше или меньше сообщений, чем обычно показывается на странице архива (например, не отображая определенную категорию), не используйте WP_Query для создания нового запроса. Вместо этого используйте pre_get_posts для изменения основного запроса вместе с условным тегом, чтобы выделить, где именно вы хотите это сделать.
• Остерегайтесь слишком большого количества запросов на странице. Вы можете теоретически создать страницу с сотнями пользовательских запросов, но просто подумайте о загрузке сервера. Если вам нужно более четырех или пяти запросов на странице, вы можете рассмотреть возможность создания дополнительных страниц.

Резюме

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

В оставшейся части этой серии мы расскажем о том, как использовать WP_Query и получим от этого WP_Query .