Когда использовать WP_query(), query_posts() и pre_get_posts

Существует два различных контекста для циклов:

• основной цикл, который выполняется на основе URL-запроса и обрабатывается перед загрузкой шаблонов
• вторичные циклы, которые выполняются любым другим способом, вызываются из файлов шаблонов или иным образом

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

Как изменить основной цикл

• не используйте query_posts()
• используйте фильтр pre_get_posts с проверкой $query->is_main_query()
• альтернативно используйте фильтр request (слишком грубый, поэтому предыдущий вариант лучше)

Как выполнить вторичный цикл

Используйте new WP_Query или get_posts(), которые практически взаимозаменяемы (последний является тонкой обёрткой для первого).

Как очистить

Используйте wp_reset_query(), если вы использовали query_posts() или напрямую изменяли глобальную переменную $wp_query — так что вам почти никогда это не понадобится.

Используйте wp_reset_postdata(), если вы использовали the_post() или setup_postdata(), или изменяли глобальную переменную $post и вам нужно восстановить исходное состояние пост-данных.

Существуют законные сценарии использования query_posts($query), например:

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

2. Вы хотите, чтобы работала пагинация этих записей

Теперь, зачем вам может понадобиться отображать это на странице вместо использования шаблона архива?

1. Это более интуитивно понятно для администратора (вашего клиента?) — они могут видеть страницу в разделе 'Страницы'

2. Это удобнее для добавления в меню (без страницы им пришлось бы добавлять URL напрямую)

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

Вот упрощенный пример кода (который будет в вашем шаблоне страницы — например, page-page-of-posts.php):

/**
 * Название шаблона: Страница с записями
 */

while(have_posts()) { // оригинальный основной цикл - контент страницы
  the_post();
  the_title(); // заголовок страницы
  the_content(); // контент страницы
  // и т.д...
}

// теперь отображаем список записей нашего пользовательского типа поста

// сначала получаем параметры пагинации
$paged = 1;
if(get_query_var('paged')) {
  $paged = get_query_var('paged');
} elseif(get_query_var('page')) {
  $paged = get_query_var('page');
}

// запрашиваем записи и заменяем основной запрос (страницы) этим (чтобы пагинация работала)
query_posts(array('post_type' => 'my_post_type', 'post_status' => 'publish', 'paged' => $paged));

// пагинация
next_posts_link();
previous_posts_link();

// цикл
while(have_posts()) {
  the_post();
  the_title(); // заголовок вашей записи пользовательского типа поста
  the_content(); // контент вашей записи пользовательского типа поста
}

wp_reset_query(); // устанавливает основной запрос (глобальная $wp_query) в исходный запрос страницы (он получает его из глобальной переменной $wp_the_query) и сбрасывает данные поста

// Теперь мы можем снова отобразить контент, связанный со страницей (если захотим)
while(have_posts()) { // оригинальный основной цикл - контент страницы
  the_post();
  the_title(); // заголовок страницы
  the_content(); // контент страницы
  // и т.д...
}

Теперь, чтобы быть абсолютно ясным, мы могли бы избежать использования query_posts() здесь и использовать вместо этого WP_Query — вот так:

// ...

global $wp_query;
$wp_query = new WP_Query(array('ваши параметры запроса здесь')); // устанавливает новый пользовательский запрос как основной

// ваш цикл для пользовательского типа поста здесь

wp_reset_query();

// ...

Но зачем нам это делать, когда у нас есть такая удобная маленькая функция?

Я изменяю запрос WordPress из файла functions.php:

//К сожалению, условие "IS_PAGE" не работает в pre_get_posts (это поведение WORDPRESS)
//поэтому вы можете использовать `add_filter('posts_where', ....);` ИЛИ изменить запрос "PAGE" непосредственно в файле шаблона

add_action( 'pre_get_posts', 'myFunction' );
function myFunction($query) {
    if ( ! is_admin() && $query->is_main_query() )  {
        if (  $query->is_category ) {
            $query->set( 'post_type', array( 'post', 'page', 'my_postType' ) );
            add_filter( 'posts_where' , 'MyFilterFunction_1' ) && $GLOBALS['call_ok']=1; 
        }
    }
}
function MyFilterFunction_1($where) {
   return (empty($GLOBALS['call_ok']) || !($GLOBALS['call_ok']=false)  ? $where :  $where . " AND ({$GLOBALS['wpdb']->posts}.post_name NOT LIKE 'Journal%')"; 
}

Просто чтобы обозначить некоторые улучшения к принятому ответу, так как WordPress развивался со временем, и сейчас (спустя пять лет) некоторые вещи изменились:

pre_get_posts — это фильтр для изменения любого запроса. Чаще всего он используется для изменения только 'основного запроса':

На самом деле это хук действия, а не фильтр, и он влияет на любой запрос.

Основной запрос появляется в ваших шаблонах как:

if( have_posts() ):
    while( have_posts() ): the_post();
       //Цикл
    endwhile;
endif;

На самом деле, это тоже неверно. Функция have_posts итерирует объект global $wp_query, который не относится только к основному запросу. global $wp_query; может быть изменён и второстепенными запросами.

function have_posts() {
    global $wp_query;
    return $wp_query->have_posts();
}

get_posts()

По сути, это обёртка для отдельного экземпляра объекта WP_Query.

На самом деле, сейчас WP_Query — это класс, поэтому у нас есть экземпляр класса.

В заключение: во время, когда @StephenHarris писал это, скорее всего, всё было правдой, но со временем в WordPress произошли изменения.