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

Кажется, что половина учебников в Codex и вокруг блогосферы использует query_posts() и наполовину использовать WP_Query . Какая сделка?

379 голосов | спросил Dan Gayle 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 13 Sep 2010 19:58:39 +0400 2010, 19:58:39

8 ответов


612
  • query_posts() является чрезмерно упрощенным и проблематичным способ изменить основной запрос страницы, заменив его новым экземпляром запроса. Он неэффективен (повторно запускает SQL-запросы), и в некоторых случаях он будет неудачным (особенно часто при работе с разбивкой по страницам). Любой современный WP-код должен использовать более надежные методы, например, использовать pre_get_posts , для этой цели. TL; DR не использовать query_posts () когда-либо ;

  • get_posts() очень похож на использование и принимает те же аргументы (с некоторыми нюансами, как и разные значения по умолчанию), но возвращает массив сообщений, не изменяет глобальные переменные и безопасен в любом месте;

  • WP_Query класс действует как за кулисами, но вы также можете создавать и работать с собственным объектом. Бит более сложный, меньше ограничений, также безопасный для использования в любом месте.

ответил Rarst 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 13 Sep 2010 20:10:20 +0400 2010, 20:10:20
48

query_posts - никогда не следует использовать query_posts. Помимо того, что сказал @Rarst, действительно большая проблема с query_posts заключается в том, что он разбивает основной объект запроса (хранится в $wp_query). Многие плагины и настраиваемый код зависят от основного объекта запроса, поэтому разбиение основного объекта запроса означает, что вы нарушаете функциональность плагинов и пользовательский код. Одной из таких функций является вся важная функция разбиения на страницы, поэтому, если вы нарушаете основной запрос, вы разбиваете разбивку на страницы.

Чтобы доказать, насколько плохим query_posts является, на любом шаблоне, выполните следующие действия и сравните результаты

var_dump( $wp_query );
query_posts( '&posts_per_page=-1' );
var_dump( $wp_query );

get_posts и WP_Query - это правильный способ создания вторичных запросов (, таких как связанные записи, слайдеры, отображаемый контент и содержимое на статических передних страницах ) с. Следует отметить, что вы не должны использовать ни одного из двух в пользу основного запроса на главной странице, отдельной странице или странице любого типа архива, так как это нарушит функциональность страницы. Если вам нужно изменить основной запрос, используйте pre_get_posts, чтобы сделать это, а не пользовательский запрос. ( ОБНОВЛЕНИЕ: . Для статических титульных страниц и настоящих страниц см. Использование pre_get_posts на настоящих страницах и статических передних страницах *)

По сути, WP_Query используется основным запросом и также используется get_posts, но хотя get_posts() использует WP_Query, есть несколько отличий

  • get_posts быстрее, чем WP_Query. Маржа зависит от количества общих постов сайта. Причина этого в том, что get_posts проходит 'no_found_rows' => true по умолчанию WP_Query, который пропускает /легально разбивает разбивку на страницы. С помощью 'no_found_rows' => true, WP_Query получает количество сообщений, запрашиваемых, затем выдает ответ, где по умолчанию он ищет все сообщения, соответствующие запросу, чтобы рассчитать разбиение на страницы.

    По этой причине, get_posts() должен использоваться только для не связанных с paqqqqq запросов. Paginating get_posts - это действительно один большой беспорядок. WP_Query должен использоваться для всех разбитых на страницы запросов

  • get_posts() не подвержены влиянию фильтров posts_*, где на них влияют WP_Query. Причина в том, что get_posts, по умолчанию, передает 'suppress_filters' => true в WP_Query

  • get_posts содержит несколько дополнительных параметров, таких как include, exclude, numberposts и category. Эти параметры преобразуются в действительные параметры для WP_Query перед передачей в WP_Query. include получает значение post__in, exclude в post__not_in, category в cat и numberposts в posts_per_page. Просто заметьте, все параметров, которые могут быть переданы в WP_Query, работает с get_posts, вы можете игнорировать и не использовать параметры по умолчанию get_posts

  • get_posts возвращает только $posts свойство WP_Query, а WP_Query возвращает полный объект. Этот объект весьма полезен, когда речь идет об условных выражениях, разбиении на страницы и другой полезной информации, которые могут использоваться внутри цикла.

  • get_posts не использует цикл, а цикл foreach для отображения сообщений. Кроме того, по умолчанию не доступны теги шаблонов. setup_postdata( $post ) должен использоваться, чтобы сделать теги шаблона доступными. WP_Query использует теги цикла и шаблона по умолчанию

  • get_posts проходит 'ignore_sticky_posts' => 1 в WP_Query, поэтому get_posts по умолчанию игнорирует липкие сообщения

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

ответил Pieter Goosen 18 J0000006Europe/Moscow 2015, 20:46:01
29

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

query_posts('meta_key=color&meta_value=blue'); 

С другой стороны, WP_Query больше похож на инструмент общего назначения и больше похож на прямое выполнение запросов MySQL, чем query_posts(). Вы также можете использовать его в любом месте (не только в Loop), и это не мешает текущим работающим почтовым запросам.

Я чаще использую WP_Query чаще, как это бывает. На самом деле, это сойдет на ваш конкретный случай.

ответил nickmjones 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 13 Sep 2010 20:09:13 +0400 2010, 20:09:13
12

Просто не нужно использовать query_posts(). Все это создает экземпляр нового объекта WP_Query и переназначает этот новый объект на global wp_query.

Для справки следующее: фактическая функция query_posts().

 function query_posts($query) {
        $GLOBALS['wp_query'] = new WP_Query();
        return $GLOBALS['wp_query']->query($query);
    }

Создайте собственный объект WP_Query, если вы хотите создать встроенный скрипт пользовательского запроса. Или используйте get_posts(), если все, что вам нужно сделать, это некоторые легкие манипуляции здесь и там.

В любом случае, я настоятельно рекомендую сделать одолжение и перейти в wp_includes/query.php и изучить класс WP_Query.

ответил RebelPhoenix 13 J000000Saturday13 2013, 20:38:02
11

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

ответил Bindiya Patoliya 8 J000000Monday13 2013, 08:50:45
7

Если я вернусь правильно прочитать, по существу «цикл» делает WP_Query в основных файлах, но более понятным образом.

ответил tw2113 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 24 Sep 2010 00:21:34 +0400 2010, 00:21:34
4
  • query_posts () : может использоваться в одном и только случае, если вам нужно изменить основной запрос , Он устанавливает множество глобальных переменных;
  •   
  • get_posts () : он очень похож в механике и принимает те же аргументы, но возвращает массив из сообщения
  •   
  • WP_Query : вы можете создавать и работать с собственным объектом. Бит более сложный, меньше ограничений, он безопасен в любом месте.
ответил dalveer 19 J000000Wednesday17 2017, 17:28:38
-5

Я бы сказал, не используйте get_posts() в плагине. В некоторых случаях он накладывает очень ограничительные фильтры (set suppress_filters, ignore_sticky_posts и т. Д.) И, вероятно, должен использоваться только в теме, если вам нужно что-то сделать быстро.

ответил m4olivei 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 25 Sep 2013 20:03:43 +0400 2013, 20:03:43

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132