dangayle
  • 0
Мастер

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

  • 0

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

Все они делают похожие вещи, поэтому когда мне следует использовать один вместо других?

Share
    • @jjeaton query_posts() — это крошечная функция-оболочка для WP_Query, единственная дополнительная вещь, которую она делает (согласно блок-схеме), — это перезапись глобальных $wp_query

      • 0
    • @jjeaton Замена query_posts() на WP_Query не повлияет на производительность, запрос исходной страницы все равно будет выполняться, потому что это часть нагрузки ядра. Эти запросы будут выполняться, даже если в вашем файле шаблона вообще нет цикла.

      • 0
    • Не могу отделаться от ощущения, что это самый гениальный и самый популярный пост на WPSE. Должен быть и в Кодексе.

      • 0
    • Я просто добавлю свое самое четкое описание проблемы «производительности query_posts()»: использование query_posts() или WP_Query в файле шаблона будет иметь ту же стоимость производительности: запрос, который вы только что выполнили. Проблема, обсуждаемая в статье кодекса, заключается в том, что если вы действительно хотите заменить запрос, вы должны сделать это, отфильтровав исходный query_posts() с помощью фильтра parse_query. Таким образом, у вас будет только один исходный желаемый запрос, а не второй запрос, чтобы неуклюже заменить его. query_posts() НИ В КОЕМ СЛУЧАЕ !! НИКОГДА!

      • 0
    • В блоге developer.wordpress.com есть чертовски потрясающее объяснение query_posts, написанное Джоном Джеймсом Джейкоби (John James Jacoby), которое сводит на нет все эти ответы. Суть: query_posts вообще не изменяет основной цикл, он заменяет его после того, как он уже запущен. Лучший способ изменить основной цикл — использовать pre_get_posts фильтр. developer.wordpress.com/2012/05/14/…

      • 0
    • Хотел бы я добавить ответы в избранное. Это многое объясняет.

      • 0
    • Отличное объяснение! «get_posts () следует использовать только для запросов без разбивки на страницы. Разбивка get_posts на страницы — это действительно один большой беспорядок. WP_Query следует использовать для всех запросов с разбивкой на страницы». Это в основном все, что кому-то нужно знать imo.

      • 0
    • @ pieter-goosen, знаете ли вы, верно ли то же самое для WP User Query по сравнению с get_users? Относится к исполнительской части.

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

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

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

    • 0
  1. 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() его следует использовать только для запросов без разбивки на страницы. Пагинация 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 вам и что вам на самом деле нужно от запроса. Вышеизложенное должно помочь вам в вашем выборе

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

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

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

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

    • 0
  3. Просто нет необходимости использовать 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 класс.

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

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

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

Оставить ответ

You must login to add an answer.