Существуют ли сценарии, в которых могут использоваться query_posts?

Я чувствую, что есть красная кнопка с надписью «Не нажимать» ниже query_posts() . В течение некоторого времени я пытаюсь демистифицировать это явление с очень низким успехом, чтобы быть честным.

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

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

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

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

 File: /wp-includes/query.php 79: /** 80: * Set up The Loop with query parameters. 81: * 82: * This will override the current WordPress Loop and shouldn't be used more than 83: * once. This must not be used within the WordPress Loop. 84: * 85: * @since 1.5.0 86: * 87: * @global WP_Query $wp_query Global WP_Query instance. 88: * 89: * @param string $query 90: * @return array List of posts 91: */ 92: function query_posts($query) { 93: $GLOBALS['wp_query'] = new WP_Query(); 94: return $GLOBALS['wp_query']->query($query); 95: } 

Вы можете видеть, что This must not be used within the WordPress Loop. , что означает не в пределах цикла WordPress, подразумевая, что до того, как цикл WordPress не будет запрещен.

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

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

Некоторые хорошие мысли на query_posts могут быть:

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

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


Нет

query_posts() полезен в случаях, когда нет основного запроса : например, вызовы wp-admin/admin-ajax.php , wp-admin/admin-post.php или wp-login.php .

Да, вы можете добиться тех же результатов там без query_posts() и чуть менее компактного кода. Но если вам не нужно заботиться о побочных эффектах, использование query_posts() допустимо.

Всякий раз, когда доступен основной запрос, который предназначен для каждой загрузки на первой странице независимо от того, какая страница / архив загружается, вы должны использовать pre_get_posts для изменения pre_get_posts запроса основного запроса до того, как SQL-запрос будет создан и выполнен. Это касается каждой страницы, где вам нужно изменить основной запрос. Это РЕКОМЕНДУЕМЫЙ способ изменить основной запрос. Выполнение этого способа не приведет к каким-либо дополнительным запросам db, периоду. Для настоящих страниц и статических фронтовых страниц вы всегда можете использовать мой класс PreGetPostsForPages или даже метод pre_get_posts описанный здесь @birgire .

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

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

query_posts прежнему остается очень проблематичным способом запуска пользовательских запросов, поскольку он изменяет основной объект запроса, хранящийся в $wp_query ( $ GLOBALS ['wp_query'] ), потому что так много функций и плагинов полагается на основной объект запроса, чтобы запускать такие вещи, как разбиение на страницы и связанные с ними сообщения и панировочные сухари

Как уже упоминалось @toscho, используйте только query_posts когда нет основного запроса, который предназначен для вызовов ajax, и некоторых страниц на стороне администратора. Кроме того, вы действительно должны избегать его использования, принимает, когда вам действительно нужно что-то сломать на лицевой стороне.

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

РЕДАКТИРОВАТЬ

В качестве окончательного замечания и доказательства загрузите и установите плагин Query Monitor. Таким образом, вы можете увидеть резкое увеличение времени загрузки страницы и вызовов db при замене основного запроса на любой пользовательский запрос и как нет разницы при использовании pre_get_posts

Напротив обычного полагает, что query_posts безвреден, если вы знаете, как его использовать. Я попробовал здесь предоставить больше аргументов.

Здесь я добавлю простой план, на который вы никогда не должны полагаться: $GLOBALS['wp_query'] .

Вы должны полагаться на $GLOBALS['wp_the_query'] который должен быть заморожен. Если вы хотите сбросить $GLOBALS['wp_query'] просто используйте wp_reset_query .

Случай использования

введите описание изображения здесь

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