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

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

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

• WP_Query - это класс,который поддерживает оба сцены,но вы также можете создавать и работать с их собственным экземпляром. Немного сложнее,меньше ограничений,также безопасно использовать где угодно.

• query_posts() is overly simplistic and a problematic way to modify the main query of a page by replacing it with new instance of the query. It is inefficient (re-runs SQL queries) and will outright fail in some circumstances (especially often when dealing with posts pagination). Any modern WP code should use more reliable methods, like making use of the pre_get_posts hook, for this purpose. TL;DR don't use query_posts() ever.

• get_posts() is very similar in usage and accepts the same arguments (with some nuances, like different defaults), but returns an array of posts, doesn't modify global variables and is safe to use anywhere.

• WP_Query is the class that powers both behind the scenes, but you can also create and work with your own instance of it. A bit more complex, fewer restrictions, also safe to use anywhere.

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

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

  var_dump ($ wp_query);
query_posts ('& amp;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 () следует использовать только для запросов без разбивки на страницы. Пагинация get_posts - это действительно большой беспорядок. WP_Query следует использовать для всех запросов с разбивкой на страницы

На

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

• get_posts имеет несколько дополнительных параметров,таких как include ,exclude ,numberposts и категория . Эти параметры действительно меняются на допустимые параметры для 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 зависит от вас и что вам действительно нужно от запроса. Вышеизложенное должно помочь вам в выборе

query_posts - You should never ever use query_posts. Apart from what @Rarst has said, the really big issue with query_posts is, it breaks the main query object ( stored in $wp_query ). A lot of plugins and custom code relies on the main query object, so breaking the main query object means that you are breaking the functionalities of plugins and custom code. Just one such function is the all important pagination function, so if you break the main query, you break pagination.

To prove how bad query_posts is, on any template, do the following and compare the results

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

get_posts and WP_Query are the correct way to construct secondary queries ( like related posts, sliders, featured content and content on static front pages ) with. It should be noted, you should not use any of the two in favor of the main query on the home page, single page or any type of archive page as it will break page functionality. If you need to modify the main query, use pre_get_posts to do so, and not a custom query. (UPDATE: For static front pages and true pages, see Using pre_get_posts on true pages and static front pages*)

In essence, WP_Query is used by the main query and is also used by get_posts, but although get_posts() uses WP_Query, there are a few differences

• get_posts are faster than WP_Query. The margin depends on the amount of total posts of the site. The reason for this is, get_posts passes 'no_found_rows' => true by default to WP_Query which skips/legally breaks pagination. With 'no_found_rows' => true, WP_Query gets the amount of posts queried, then bails out, where by default, it further search for all posts matching the query in order to calculate pagination.

  For this reason, get_posts() should be used for non paginated queries only. Paginating get_posts is really one big mess. WP_Query should be used for all paginated queries

• get_posts() aren't influenced by the posts_* filters where WP_Query gets influenced by these filters. The reason is that get_posts, by default, passes 'suppress_filters' => true to WP_Query

• get_posts has a couple of extra parameters like include, exclude, numberposts and category. These parameters do get changed into valid parameters for WP_Query before being passed to WP_Query. include gets changed into post__in, exclude into post__not_in, category into cat and numberposts into posts_per_page. Just a note, all of the parameters that can be passed to WP_Query works with get_posts, you can ignore and not use the default parameters of get_posts

• get_posts returns just the $posts property of WP_Query while WP_Query returns the complete object. This object is quite useful when it comes to conditionals, pagination and other useful info that can be used inside the loop.

• get_posts doesn't use the loop, but a foreach loop to display posts. Also, no template tags are available by default. setup_postdata( $post ) has to be used to make the template tags available. WP_Query uses the loop and template tags are available by default

• get_posts passes 'ignore_sticky_posts' => 1 to WP_Query, so get_posts by default ignores sticky posts

Based on the above, whether to use get_posts or WP_Query is up to you and what do you actually need from the query. The above should guide you in your choice

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

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

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

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

The basic difference is that query_posts() is really only for modifying the current Loop. Once you're done it's necessary to reset the loop and send it on its merry way. This method is also a little easier to understand, simply because your "query" is basically a URL string that you pass to the function, like so:

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

On the other hand, WP_Query is more of a general purpose tool, and is more like directly writing MySQL queries than query_posts() is. You can also use it anywhere (not just in the Loop) and it doesn't interfere with any currently running post queries.

I tend to use WP_Query more often, as it happens. Really, it's going to come down to your specific case.

Нет необходимости использовать 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.

There is simply no need to use query_posts(). All it does is instantiates a new WP_Query object and reassigns that new object to global wp_query.

For reference, the following is that actual query_posts() function.

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

Instantiate your own WP_Query object if you want to create an in depth custom query script. Or use get_posts() if all you need to do is some light manipulation here and there.

In either case, I highly recommend doing yourself a favor and going to wp_includes/query.php and perusing the WP_Query class.

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

Make sure that you use wp_reset_query() after using query_posts() because it will affect other query result also.

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

If I recall reading right, essentially "the loop" is doing WP_Query in the core files, but in an easier to understand way.

• query_posts () : может использоваться в одном-единственном случае,если вам нужно изменить основнойзапрос.Он устанавливает множество глобальных переменных;
• get_posts () : он очень похож по механике и принимает те же аргументы,но возвращает массивсообщений
• WP_Query : вы можете создавать собственные объекты и работать с ними.Немного сложнее,меньше ограничений,безопасно использовать где угодно.

• query_posts(): might be used in one and only case if you need to modify main query . It sets a lot of global variables;
• get_posts(): it is very similar in mechanics and accepts same arguments, but returns array of posts
• WP_Query:  you can create and work with own object of it. Bit more complex, less restrictions, it is safe to use anywhere.