query_posts () следует избегать?

Я сделал очень подробное объяснение по этой теме на WPSE, и ради ценности и пользы, которые это может иметь для пользователей SO, вот полный пост, скопированный из этого вопроса на WPSE. Для интереса, вот ссылка на полный пост на WPSE: Некоторые сомнения в том, как основной запрос и пользовательский запрос работают в этой настраиваемой теме?

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

ПЕРВАЯ ЧАСТЬ

Когда запускать пользовательский запрос (это не окончательный список)

• Чтобы создать пользовательские слайдеры контента

• Чтобы создать отображаемую область содержимого на странице

• На шаблонах page.php, если вам нужно отображать сообщения

• Если вам нужен пользовательский контент на статической главной странице

• Отображать связанные, популярные или информационные сообщения

• Любое другое вторичное или дополнительное содержимое выходит за рамки основного запроса

Когда использовать основной запрос.

Чтобы отобразить основное содержимое на

• На домашней странице и странице, заданной как страница блога в бэкэнд

• Все архивные страницы, содержащие шаблоны, такие как archive.php, category.php, author.php, taxonomy.php, tag.php и date.php

ЧАСТЬ ВТОРАЯ

Чтобы выбрать все назначенные записи, я использую эту строку, которые создают новый объект WP_Query, который определяет запрос с определенным тегом:

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

Верный. Это выходит за рамки основного запроса. Это дополнительный или дополнительный контент, который не может быть создан с помощью основного запроса. Вы должны ВСЕГДА использовать WP_Query или get_posts для создания ваших пользовательских запросов.

НИКОГДА НЕ ИСПОЛЬЗУЙТЕ query_posts для создания пользовательских запросов или даже любого другого запроса. Мой акцент.

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

Перемещение

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

 query_posts( array( 'tag__not_in' => array ( $term->term_id ))); 

Поэтому я думаю, что это довольно ужасно. Это правда?

Это все неправильно, и ваше заявление, к сожалению, верно. Как говорилось ранее, НИКОГДА не используйте query_posts . Он выполняет полный новый запрос, что плохо для производительности, и в большинстве случаев разбивает разбиение на страницы, что является неотъемлемой частью основного запроса на правильность работы страницы.

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

 <?php if (have_posts()) : // Start the Loop. while (have_posts()) : the_post(); get_template_part('content', get_post_format()); endwhile; else : // If no content, include the "No posts found" template. get_template_part('content', 'none'); endif; ?> 

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

 <? // get the term using the slug and the tag taxonomy $term = get_term_by( 'slug', 'featured', 'post_tag' ); // pass the term_id to tag__not_in query_posts( array( 'tag__not_in' => array ( $term->term_id ))); ?> 

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

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

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

 function exclude_featured_tag( $query ) { if ( !is_admin() && $query->is_home() && $query->is_main_query() ) { $query->set( 'tag__not_in', 'array(ID OF THE FEATURED TAG)' ); } } add_action( 'pre_get_posts', 'exclude_featured_tag' ); 

ЧАСТЬ ТРЕТЬЯ

Дополнительные материалы для чтения, которые будут полезны в будущем

• Условные теги

• Когда следует использовать WP_Query vs query_posts () vs get_posts ()?

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

• Обзор запросов

• Руководство с петлей для CMS

Создание нового объекта WP_Query () всегда прекрасное.

 $sort= $_GET['sort']; if($sort == "pricelow"){ $sort_args = array('meta_key' => 'price', 'orderby' => 'meta_value_num', 'order', 'ASC'); $new_query = new WP_Query($sort_args); } blah blah blah... 

Нет, не жалейся об этом. Я не видел крюк pre_get_posts.

Код в вашем вопросе хорош для подключения запросов. Как описано в WordPress Plugin API / Action Reference / pre_get_posts :

pre_get_posts запускается до установки WP_Query.

Таким образом, он перехватывает по умолчанию WP_Query (), где вы хотите (в вашем коде он изменяет WP_Query в запросе GET).

В файлах шаблонов используйте новый WP_Query ($ args).