Мы рассмотрели, как WordPress можно использовать в качестве основы для разработки приложений, но одна из вещей, которую нам еще предстоит охватить, которую предлагает большинство современных сред, — это запрос к базе данных для получения результатов для любого данного представления.
В частности, мы не говорили о том, как извлечь информацию из базы данных и вставить ее на наши страницы.
Если вы знакомы с другими платформами, то, скорее всего, вы знакомы с системой объектно-реляционного отображения (ORM).
Для тех, кто не знаком с ORM, по сути, это часть программного обеспечения, которая находится между приложением и базой данных и позволяет нам извлекать строки и столбцы как объекты, обрабатывать их как таковые, а затем сериализовать их изменения обратно в базу данных.
Это действительно классные вещи. Тем не менее, WordPress не предлагает такой гибкости.
Вместо этого он предлагает набор API, которые позволяют нам вносить изменения в базу данных. Существует несколько API-интерфейсов, которые мы можем использовать, каждый из которых мы рассмотрим в последнем наборе статей.
Сначала рассмотрим WP_Query . Затем мы рассмотрим WP_User_Query , а $wpdb объект $wpdb который доступен как global в WordPress.
Но об этом чуть позже. Теперь WP_Query к WP_Query .
Запросы к базе данных WordPress
Прежде чем мы начнем говорить о запросах к базе данных WordPress, я думаю, что очень важно обрисовать в общих чертах, что именно это означает, почему это важно и что это влечет за собой.
Если ничего другого, это предназначено, чтобы установить уровень ожиданий для читателей независимо от вашего уровня опыта.
1. Что это значит?
Запросы к базе данных WordPress представляют именно то, что вы ожидаете: получение информации из базы данных, в которой работает WordPress.
В этом нет ничего ужасно сложного. Однако есть несколько различных способов сделать это, и важно знать, как это сделать и чего следует избегать.
Вообще говоря, есть три API, которые доступны и рекомендованы для использования, и несколько, которые доступны, но не рекомендуются для использования.
В этой серии статей мы рассмотрим все это.
2. Почему это важно?
Если это ничто иное, это важно, чтобы мы понимали, как правильно извлекать и хранить информацию в базе данных самыми безопасными и безопасными способами.
Помните: в программировании только то, что что-то работает, не означает, что это лучший способ сделать это.
Для этого мы рассмотрим рекомендуемые способы, которые WordPress предоставляет для извлечения и сохранения данных непосредственно из базы данных и в нее.
В конце концов, мы хотим убедиться, что мы создаем не только надежные приложения, но и безопасные и эффективные приложения.
3. Что это влечет за собой?
Как и в большинстве случаев, это подразумевает изучение API. По крайней мере, так обстоит дело с двумя типами запросов.
Для заключительной статьи требуется, чтобы вы знали или имели желание изучать SQL (поскольку WordPress позволяет писать необработанные запросы к базе данных). Но об этом чуть позже.
Сейчас мы просто сосредоточимся на API, доступных параметрах и как / когда использовать их в нашей работе.
Представляем WP_Query
Хотя вы можете прочитать все о WP_Query в Кодексе WordPress, я думаю, что здесь стоит остановиться на некоторых тонкостях этой статьи, особенно если вы новичок в WordPress или серьезно задумываетесь над написанием приложений с использованием WordPress.
Кодекс определяет WP_Query следующим образом:
WP_Query — это класс, который занимается сложностями запроса постов (или страниц) в блог WordPress. Wp-blog-header.php… предоставляет информацию об объекте $ wp_query, определяющую текущий запрос, а затем $ wp_query определяет, с каким типом запроса он имеет дело (возможно, архив категории, архив с датой, фид или поиск), и извлекает запрошенные сообщения. Он сохраняет много информации по запросу, которую можно получить позже.
Невероятно технический, верно?
Вот как следует думать об этом с точки зрения потребителя:
-
WP_Queryизвлекает информацию о сообщениях, страницах, других пользовательских типах сообщений и архивных данных и делает доступной запрашиваемую информацию об этих данных.
С точки зрения развития, подумайте об этом так:
-
WP_Query— это способ получения информации о типахWP_Queryи архивных данных, а также связанных с ними метаданных и т. Д. Полученную информацию можно затем прочитать, изменить, сохранить и / или отобразить в файлах шаблонов.
Короче говоря, WP_Query предоставляет нам стандартный способ запросов к базе данных, в частности, о сообщениях, страницах, пользовательских типах сообщений и связанных с ними метаданных, чтобы нам было легче работать с информацией, хранящейся в WordPress.
Примечание. Если вам нужна информация об управлении пользователями или написании пользовательских запросов SQL, подождите до следующего набора статей, поскольку мы рассмотрим эту информацию более подробно в то время.
Как использовать WP_Query
Итак, мы рассмотрели, что такое WP_Query , почему он полезен и как его следует использовать, но это еще далеко.
WP_Query пришло время взглянуть на то, какие параметры можно передать в WP_Query и некоторые практические примеры того, как его использовать.
Во-первых, WP_Query может принимать аргументы для: авторов, категорий, тегов, таксономий, общих поисковых запросов, сообщений, страниц, пользовательских типов записей, статуса, нумерации страниц, порядка записи, дат, пользовательских полей, разрешений, кэширования и полей возврата.
Короче говоря, почти все, что связано с типами WP_Query , их тегами категорий и их метаданными, можно получить с помощью WP_Query .
Слово о петле
Если вы читали какой-либо код темы WordPress или работали с WordPress в любом качестве до прочтения этой статьи, то вполне вероятно, что вы видели такой код:
|
1
2
3
4
5
6
7
|
<?php
if ( have_posts() ) {
while ( have_posts() ) {
the_post();
// Display post data here
}
}
|
И в WordPress это то, что известно как The Loop .
Короче говоря, в цикле происходит все, что касается отображения информации, полученной из запроса.
С этой целью, если вы пишете запрос с использованием WP_Query , то, скорее всего, вы будете использовать эту же структуру для своей работы.
Но об этом мы узнаем чуть позже.
Практические примеры
WP_Query работать с WP_Query легко. Например, предположим, что мы хотим настроить шаблон, который отображает все сообщения для одного автора.
Для этого мы можем использовать идентификатор автора. Допустим, мы хотим получить все сообщения, страницы и контент, написанные автором с идентификатором «1».
|
1
2
3
4
5
6
|
<?php
$args = array(
‘author’ => 1
);
$my_query = new WP_Query( $args );
|
И тогда мы хотим повторить это:
|
01
02
03
04
05
06
07
08
09
10
|
if ( $my_query->have_posts() ) {
while ( $my_query->have_posts() ) {
// Do work with Author 1’s post
}
// We’ll talk about this next line later in the article
wp_reset_postdata();
}
|
Достаточно просто, правда?
Но давайте сделаем это немного сложнее. Допустим, мы хотим получить только сообщения от этого автора, которые подпадают под пользовательский тип записи «Фотография» и были опубликованы в 2013 году.
Для этого мы передадим эту информацию:
|
1
2
3
4
5
6
7
8
9
|
<?php
$args = array(
‘author’ => 1
‘post_type’ => ‘photography’
‘date_query’ => array( ‘2013’ )
);
$my_query = new WP_Query( $args );
|
А затем выполните итерацию запроса следующим образом:
|
01
02
03
04
05
06
07
08
09
10
|
if ( $my_query->have_posts() ) {
while ( $my_query->have_posts() ) {
// Do work with the returned posts
}
// We’ll talk about this next line later in the article
wp_reset_postdata();
}
|
Но это может быть немного сложнее в зависимости от информации, которую мы имеем под рукой в любой данный момент в течение жизненного цикла приложения.
Например, предположим, что мы хотим программно создать пользовательский тип записи с определенным заголовком и слагом, но только если он еще не существует.
Для этого есть три шага:
- Передайте необходимые аргументы классу
- Пробежаться по The Loop в поисках любых постов, которые могут существовать
- Если пост не существует, создайте его
Вот как это сделать:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
// Look for the specified post type and slug that are published or are in the trash
$args = array(
‘post_type’ => $post_type,
‘post_name’ => $slug,
‘post_status’ => array( ‘publish’, ‘trash’ )
);
$post_type_query = new WP_Query( $args );
// A post with that information already exists, then remove it from the trash
if( $post_type_query->have_posts() ) {
while( $post_type_query->have_posts() ) {
$post_type_query->the_post();
// If the post is found in the trash, restore it
if( ‘trash’ == strtolower( get_post_status( get_the_ID() ) ) ) {
$page = get_page( get_the_ID() );
$page->post_status = ‘publish’;
wp_update_post( $page );
}
}
}
// If a post doesn’t already exist with the specified title, create it
if( null == acme_get_permalink_by_slug( $slug, $post_type ) ) {
$page_id = wp_insert_post(
array(
‘comment_status’ => ‘closed’,
‘ping_status’ => ‘closed’,
‘post_author’ => 1, // Administrator is creating the page
‘post_title’ => $title,
‘post_name’ => strtolower( $slug ),
‘post_status’ => ‘publish’,
‘post_type’ => strtolower( $post_type )
)
);
// If a template is specified in the function arguments, let’s apply it
if( null != $template ) {
update_post_meta( get_the_ID(), ‘_wp_page_template’, $template );
}
}
// We’ll talk about this line later in the article
wp_reset_postdata();
|
Как вы можете сказать, вы можете сделать несколько действительно мощных запросов и по-настоящему умно работать с WordPress и WP_Query если знаете, как правильно обрабатывать параметры.
Теперь, в приведенном выше коде, когда мы ищем, существует ли запись в корзине, есть более оптимальные способы написания запроса для проверки; однако приведенный выше код призван продемонстрировать больше примера того, как сделать это с помощью WP_Query чем что-либо еще.
По мере того, как мы углубимся в эту тему написания запросов, мы увидим другие способы более быстрого извлечения информации (например, использование необработанного SQL для SELECT операторов DELETE или UPDATE ).
Для этого я настоятельно рекомендую ознакомиться со всеми параметрами, которые он принимает. Хотя существует множество вариантов (что, на мой взгляд, хорошо), существует относительно стандартный способ их передачи, при котором многие из них работают так же, как и другие.
То есть, если вы выучите несколько из них, остальные легко подобрать.
Кроме того, если вы действительно хотите лучше понять запросы, я рекомендую посмотреть, как параметры соответствуют данным в базовой базе данных.
Когда использовать WP_Query
Конечно, это поднимает вопрос о том, когда вы должны использовать WP_Query.
В конце концов, WordPress имеет свою собственную иерархию шаблонов, поэтому, если вы работаете с файлом, который вписывается в указанную иерархию, он автоматически использует запрос, связанный с этим типом шаблона.
Но при написании приложений или даже продвинутых тем WordPress вы будете создавать шаблоны, которые не вписываются в иерархию и, следовательно, нуждаются в собственном наборе запросов.
Это один из способов использования WP_Query .
Во-вторых, если вы хотите отобрать пользовательский набор информации — будь то одна часть или несколько частей — для данного сообщения, страницы, пользовательского типа сообщения, категории, таксономии и т. Д., WP_Query , вероятно, ваш лучший вариант.
Слово о сбросе запроса
Есть один большой недостаток в использовании WP_Query который является ключом к завершению вашего понимания API, и это wp_reset_postdata() .
Так же, как Кодекс описывает:
Используйте эту функцию, чтобы восстановить глобальную переменную $ post основного цикла запроса после вторичного цикла запроса с использованием нового WP_Query. Восстанавливает переменную $ post для текущей записи в основном запросе.
Из-за того, как WordPress поддерживает информацию с использованием global переменных, очень важно, чтобы после того, как вы создали, выполнили и обработали свой собственный WP_Query , вам нужно вызвать эту конкретную функцию, чтобы восстановить информацию в том состоянии, в котором она была до того, как вы запустили ваш собственный запрос.
Это делается для того, чтобы WordPress продолжал перебирать информацию по мере необходимости в иерархии шаблонов, и чтобы данные не искажались и не терялись при рендеринге контента позже на странице или на другой странице.
Далее, WP_User_Query
Если WP_Query так важен для создания эффективных, безопасных запросов для типов WP_Query и связанных с ними атрибутов, как мы можем сделать то же самое для пользователей?
В конце концов, мы уже установили, что WordPress из коробки предлагает фантастические возможности для управления учетными записями, но мы на самом деле не обсуждали способы управления пользователями посредством запросов к базе данных.
В следующей статье мы рассмотрим именно это. И если вы знакомы с WP_Query — которым вы должны быть после прочтения этой статьи — тогда вам будет очень легко следовать следующей статье.