Wp reset postdata: в соответствие с текущей страницей.

5 простых методов создания пользовательских запросов в WordPress

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

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

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

Хорошая новость заключается в том, что WordPress делает это возможным. Есть несколько методов, которые можно использовать для изменения основного запроса или создания нового.

В этом посте я рассмотрю:

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

Продолжить чтение или перейти вперед по этим ссылкам:

• Понимание основ пользовательских запросов в WordPress
• Пользовательские типы запросов и когда их использовать
• Методы создания пользовательского запроса

Основные сведения о пользовательских запросах в WordPress

Если вы раньше не создавали пользовательские запросы, вам необходимо понять несколько терминов. Если вы раньше работали с файлами шаблонов тем или запросами, вы можете пропустить этот момент!

• Запрос — это процедура, которую WordPress запускает для получения данных из базы данных вашего сайта. Это будет включать сообщения, вложения, комментарии, страницы или любой контент, который вы добавили на свой сайт.
• Цикл — это код вашей темы (или иногда плагина), используемый для указания того, как результаты запроса будут отображаться на странице. Так, например, на главной странице вашего блога цикл может включать заголовок каждого сообщения, выдержку, возможно, избранное изображение и ссылку на собственную страницу сообщения (называемую постоянной ссылкой).
• Файлы шаблонов используются вашей темой для отображения страниц для каждого типа контента. Различные темы имеют разные файлы шаблонов, но они должны включать основной файл index.php и часто также включают файл page.php для статических страниц, файл single.php для отдельных сообщений и файл archive.php для архивных страниц и, возможно, файл category.php и файл tag.php для архивов категорий и тегов соответственно. Темы могут использовать больше файлов шаблонов, например, для тусклой таксономии или архивов типов сообщений — для получения более подробной информации см. Иерархию шаблонов.
• Условные теги могут использоваться в ваших файлах шаблонов или плагинами для проверки того, какая страница отображается в данный момент. Например, is_page() проверяет, отображается ли статическая страница, а is_home() проверяет, находимся ли мы на домашней странице. Существует множество других условных тегов, в том числе теги, определяющие, вошел ли пользователь в систему, и другие.

Типы пользовательских запросов и когда их использовать

Существует два типа пользовательских запросов:

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

Давайте посмотрим, когда вы можете использовать каждый из них.

Изменение основного запроса

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

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

Примеры:

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

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

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

Написание нового запроса

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

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

• Запуск двух циклов на странице архива: один для первого сообщения, а другой для всех последующих сообщений. Вы должны сделать это, если хотите отобразить другой контент для первого сообщения, например, если вы хотите включить отрывок или избранное изображение для первого сообщения, но не для других. Обратите внимание, что если все, что вы хотите сделать, это изменить стиль первого сообщения, маловероятно, что вам понадобится несколько циклов: вместо этого вы должны иметь возможность использовать CSS, ориентированный на первое сообщение.
• На одной странице сообщения запускается дополнительный цикл для отображения других последних сообщений (или рекомендуемых сообщений) под содержимым сообщения, чтобы побудить ваших читателей читать больше.
• Добавление баннера со ссылкой на один избранный пост (или на все избранные посты) в верхней части каждой из ваших страниц, например, если вы добавили пост, рекламирующий новый продукт. Это дает вам больше гибкости, чем добавление статического баннера, поскольку вы можете легче изменить используемый пост.
• Создание списка страниц в одном разделе сайта, если ваш сайт имеет структуру, основанную на иерархических страницах. Возможно, вы захотите поместить это в боковую панель.
• Создание шаблона страницы с полностью настраиваемым запросом для отображения сообщений по таксономии или типу сообщения (или, возможно, по обоим, в сетке).
•  На странице архива типа сообщения список сообщений по категории или термину таксономии, а не по дате (например, создание столбцов или полей со ссылками на последние сообщения в каждой категории).
• Создание баннера на боковой панели для ссылки на самую последнюю публикацию и отображения ее избранного изображения.
•  Создание страницы для публикации сообщений с указанным термином в нескольких таксономиях (например, на сайте фильмов, где перечислены научно-фантастические фильмы, снятые в США, где жанр и страна являются таксономиями).
• Создание типа записи для содержимого боковой панели и запрос сообщений этого типа на боковой панели. Это поможет пользователям, не занимающимся кодированием, добавлять контент на боковую панель с большей гибкостью, чем они могут получить с помощью виджетов.

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

Методы создания пользовательского запроса

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

• Использование хука действия pre_get_posts . Это позволяет вам вносить изменения в основной запрос, добавляя функцию в файл функций вашей темы или через плагин (но не в файлы шаблона вашей темы). Вы можете комбинировать его с условным оператором, чтобы убедиться, что он работает только на страницах, отображающих определенные типы контента.
• Использование query_posts() . Я включил это сюда отчасти для полноты, но что более важно, чтобы объяснить, почему вам не следует его использовать. query_posts()  – это неэффективный и потенциально ненадежный способ изменения основного запроса. Вместо фактического изменения основного запроса он извлекает основной запрос, затем выбрасывает его и запускает снова, повторно запуская основной запрос с вашими изменениями. Это замедлит работу вашего сайта. Это также ненадежно и может сломаться, особенно когда требуется нумерация страниц. Так что не пользуйтесь!!

Все три оставшихся метода позволяют создать новый запрос:

• Класс WP_Query . Это самый мощный и гибкий способ создания нового запроса, и его можно использовать при создании второго цикла в файле шаблона или при создании файла шаблона с полностью настраиваемым запросом, заменяющим основной цикл. Вы должны быть осторожны при его использовании: основной риск заключается в том, что вы не сбросите запрос после запуска цикла, а это означает, что WordPress не сможет правильно определить, какой тип страницы отображается. Но это можно легко обойти.
• Тег шаблона get_posts() . Вы можете использовать это в файле шаблона (включая, например, боковую панель или нижний колонтитул) для получения списка сообщений. Для этого он использует класс WP_Query , поэтому на самом деле это более простой способ его использования, если все, что вам нужно, это посты. Вы можете использовать параметры с ним, чтобы указать, какие сообщения вы хотите.
• Тег шаблона get_pages() . Это работает так же, как get_posts() , извлекая страницы вместо сообщений.

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

Хук действия pre_get_posts

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

Чтобы использовать pre_get_posts , вы создаете функцию, а затем подключаете ее к действию, например: 0003

• Во-первых, он создает функцию с именем моя_функция . То, что делает функция, заключено в фигурные скобки.
• Затем он прикрепляет эту функцию к хуку pre_get_posts  с помощью функции add_action()  . Без этого ваша функция не будет работать.

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

Loading gist ace2bcc588907961dbc9657a705c27be

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

Включение пользовательских типов сообщений на главную страницу блога

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

Для этого вы добавляете следующее в файл functions.php вашей темы или в созданный вами плагин:

Загрузка gist 36f169922c1bdeac0bdaf97550cc4574

Это проверяет две вещи: является ли это основным запросом и является ли это домашней страницей (используя is_home() ). Затем он устанавливает запрос для включения двух типов сообщений: 'post' и 'custom_post_type' , что является вашим пользовательским типом сообщения. Обратите внимание, что вы должны указать здесь 'post' , если вы по-прежнему хотите, чтобы на домашней странице отображались сообщения, а также ваш собственный тип сообщений. Если вы только что добавили сюда 'custom_post_type' , это переопределит значение по умолчанию и просто покажет сообщения вашего пользовательского типа. Иногда вы можете захотеть сделать это, но это не тот случай.

Более подробно об этой технике можно прочитать в этом посте.

Отображение сообщений произвольного типа на странице архива категорий

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

Загрузка сути 8e5be1c5d092f16302de232db0062b7e

Это проверяет, выполняется ли основной запрос и находимся ли мы в архиве категорий, используя is_category() . Затем он изменяет запрос для получения сообщений вашего пользовательского типа. Обратите внимание: поскольку я не включил здесь 'post' , обычные сообщения не будут отображаться ни в одном архиве категорий, и что мне не нужно использовать массив, поскольку я указываю только один тип сообщения.

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

Загрузка gist 909166b87303e282111952289934f8e0

Это изменит основной запрос только на странице архива 'category-slug' , где 'category-slug' категория.

Изменение способа упорядочения сообщений

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

Loading gist 1ee40bda3a183b849707edc69b687849

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

Класс WP_Query

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

WP_Query  содержит части:

• Аргументы запроса с использованием параметров, аналогичных тем, которые вы могли бы использовать для pre_get_posts
• Сам запрос
• Петля
• Очистка: закрытие тегов if и while и сброс данных поста.

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

Loading gist e0f4c29ae5db6c72cb942138be2dcd24

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

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

Вот как я это делаю:

Loading gist a7497e770094f350a9d3a5adf10ab462

Для запроса данных используются три аргумента:

• 'post_type' => 'post' извлекает только сообщения
• 'posts_per_page' => '4' получает только четыре сообщения
• 'post__not_in' => array( $post->ID ) гарантирует, что отображаемая в данный момент запись не будет включена.

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

Тег шаблона get_posts()

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

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

Loading gist a497a1ddefe841fbe3c0a122ee5e03e3

Самые внимательные из вас заметят, что это очень похоже на код, который я использовал с WP_Query 9 0116 выше. Однако, если вы действительно наблюдательны, вы заметите несколько отличий:

• Аргументы не обязательно должны включать тип записи
.
• Я использую переменную $posts для хранения массива, выводимого функцией get_posts()
• Вместо того, чтобы проверять, есть ли в запросе сообщения, я использую if( $posts ) , чтобы проверить, есть ли в нем что-нибудь
• Вместо стандартного цикла я использую foreach ( $posts as $post ) , который перебирает каждую строку в массиве
• Чтобы получить доступ ко всем нужным данным публикации, я включаю setup_postdat( $post ) .

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

Тег шаблона get_pages()

get_pages() очень похож на get_posts() : он использует WP_Query , но извлекает статические страницы вместо сообщений. Давайте посмотрим на пример, где вы можете его использовать.

Допустим, на вашем сайте есть набор наиболее важных страниц верхнего уровня, и вы хотите добавить их список на боковую панель, чтобы вы могли оформить их ссылки и побуждать посетителей переходить на эти страницы. В вашем файле шаблона sidebar.php вы должны добавить этот код:

Loading gist e0ed31ace9519aa9ba1b7ca3fa2055f0

Давайте посмотрим на это:

• Сначала я определяю свои аргументы – 'parent' => 0 извлекает страницы без родителя, а два других аргумента определяют способ сортировки страниц.
• Затем я использую get_pages() для заполнения массива, хранящегося как $pages
• Я проверяю, есть ли у $pages какие-либо данные, используя if( $pages )
• Если да, то я открываю список, затем для каждой страницы открываю элемент списка
• Вместо использования setup_postdata() , как я делал с get_pages() , я делаю прямую ссылку на переменную $post с другими тегами шаблона, которые выводят ссылку и заголовок. Я должен использовать их, потому что я не использовал setup_postdata() .
• Поскольку я не использовал setup_postdata() , мне не нужно использовать wp_reset_postdata() .

Приведенный выше код является более эффективным способом вывода списка страниц, чем если бы я использовал WP_Query во всей его красе.

Заключение

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

Я использую ту или иную форму пользовательского запроса почти на каждом сайте, который я создаю, и, на мой взгляд, это одна из самых интересных вещей в WordPress (но у вас могут быть свои любимые!)

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

• pre_get_posts для модификации основного запроса
• WP_Query для создания сложных пользовательских запросов
• get_posts() и get_pages() для более простых пользовательских запросов, извлекающих только сообщения или страницы.

Их комбинация поможет вам создавать продвинутые сайты WordPress и отображать данные так, как вам нужно.

Используете ли вы пользовательские запросы? Каковы ваши главные советы по созданию пользовательских запросов? Дайте нам знать в комментариях ниже.

Теги:

• разработчики

Источники из WordPress | Гэтсби

Примеры

• Использование WordPress
• Использование WordPress с ACF

Это руководство проведет вас через процесс использования Gatsby с WordPress и WPGraphQL.

WordPress — это бесплатная система управления контентом (CMS) с открытым исходным кодом. Допустим, у вас есть сайт, созданный с помощью WordPress, и вы хотите перенести существующие данные на свой статический сайт Gatsby. Вы можете сделать это с помощью gatsby-source-wordpress. Давай начнем!

Примечание. В этом руководстве используется gatsby-starter-default , чтобы предоставить вам знания, необходимые для начала работы с WordPress, но если вы застряли в каком-то месте руководства, не стесняйтесь использовать этот пример, чтобы получить дополнительные сведения.

Настройка

Быстрый старт

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

gatsby-config.js

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

Плагин Gatsby: gatsby-source-wordpress

Теперь, когда у вас есть некоторое представление о структуре проекта, давайте добавим функцию получения данных WordPress. Для этого есть плагин. gatsby-source-wordpress  – это плагин Gatsby для получения данных с сайтов WordPress с использованием API WPGraphQL. Вы можете установить его, выполнив следующую команду:

Настройка плагина

В gatsby-config.js добавьте URL вашего сайта WordPress, все остальные настройки не обязательны, но рекомендуются.

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

Использование данных WordPress

После того, как ваш исходный плагин извлечет данные, вы можете создавать страницы своего сайта, реализуя createPages API в gatsby-node. js . Когда это вызывается, ваши данные уже получены и доступны для запроса с помощью GraphQL. Gatsby использует GraphQL во время сборки; Ваш исходный плагин (в данном случае gatsby-source-wordpress ) извлекает ваши данные, и Gatsby использует эти данные для «автоматического вывода схемы GraphQL», к которой вы можете обращаться.

API createPages предоставляет функцию graphql :

Функция GraphQL позволяет нам выполнять произвольные запросы к локальной схеме WordPress GraphQL… как сайт имеет встроенную базу данных, созданную из полученных данных, которые вы можете выполнять запросы против. (Источник)

Для начала вы можете использовать gatsby-node.js из демонстрационной версии плагина. Для целей этого руководства код для создания сообщений работает из коробки. Он запрашивает вашу локальную схему WordPress GraphQL для всех сообщений, выполняет итерацию по каждому узлу сообщений и создает статическую страницу для каждого из них на основе определенного шаблона.

Например:

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

Страница Gatsby определяется как «страница сайта с путевым именем, компонентом шаблона и дополнительным запросом GraphQL и компонентом макета».

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

В интегрированной среде разработки GraphiQL по адресу http://localhost:8000/__graphql теперь вы должны увидеть запрашиваемые поля для allWpPosts в документах или на боковой панели проводника.

Завершение

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