Intereting Posts
Как массовое удаление встроенных стилей в пользовательском типе WordPress автоматически? Сортировка настраиваемых значений полей из всех сообщений в шаблоне страницы Общий контент, но «Обновляемый» через основной сайт Выпадающий список настраиваемого типа сообщения Использование jQuery. После цикла внутри Изменить страницу профиля администратора Buddypress Постоянная ссылка Измените формулировку стандартного метаконтакта эскиза Static Frontpage Pagination – Пользовательский цикл добавить миниатюру youtube в индекс и single.php добавить видео Выполнение действия POST на главной странице отправляется на страницу сообщений Изменить / Удалить тип и категорию по умолчанию? Доменное имя в сети WordPress Создание различных размерных изображений при загрузке файла изображения с пользовательской страницы плагина Где появляются значки для медиафайлов Как добавить фильтр таксономии по запросу?

WP_Query – фильтр или напрямую?

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

Я старался держать все организованным:

  • Нет тегов <script> в шаблонах
  • Встроенный CSS только в том случае, если переменная PHP динамически изменяется из параметров администратора
  • Отдельные большие файлы JS и CSS для минимизации запросов и т. Д.

Теперь пришло время организовать мои запросы, потому что у меня есть как минимум 10 из них, и он продолжает расти.

  1. Первый вариант: используйте пользовательский add_filter() с каждым запросом

    • Мне не нужно искать запросы, потому что все они находятся в одном файле или каталоге
    • Если мне нужно изменить его, мне нужно только изменить его в одном месте, а не во всех моих разных шаблонах
  2. Второй вариант: писать все запросы в шаблоны, как обычно делается

    • В основном каждая точка напротив первого варианта

Вопрос:

Есть ли недостатки в использовании фильтра для аргументов запроса? Представление? Что-то другое?


Пример:

  1. Обычный:

     $args = array( 'post_type' => 'my-post', 'posts_per_page' => 8, 'orderby' => 'rand', ); } $results = new WP_Query( $args ); 
  2. Фильтр:

     //In one file -> easy to find and change add_filter( 'some_args', 'some_search_args' ); function some_search_args( $search_args ) { $search_args['post_type'] = 'property'; $search_args['posts_per_page'] = 8; $search_args['orderby'] = 'rand'; //All kinds of logic and conditional code to here return $search_args; } //And //Just include like this to any template you want and as many as you want //To change the query, you'll just have to change to code above $search_args = array(); $search_args = apply_filters( 'some_args', $search_args ); $results = new WP_Query( $search_args ); 

Solutions Collecting From Web of "WP_Query – фильтр или напрямую?"

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

Мне нужен пользовательский запрос

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

  • Избегайте ( где вы можете ) сложных операций упорядочивания, таких как упорядочение по метазначениям. SQL не самый лучший при заказе, а PHP иногда быстрее. Я предпочитаю usort() для сложного упорядочивания, чтобы экономить на ресурсах. Случайное упорядочение также очень сложно в отношении ресурсов

  • Избегайте ( где можете ) строить сложные запросы с сильно вложенными мета и налоговыми запросами, особенно с большим количеством операторов OR . Они довольно жесткие по ресурсам.

  • Избегайте ( где вы можете ) использования LIKE операторов в вашем сгенерированном SQL. Они также дороги

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

  • Всегда избегайте типичного цикла foreach котором вы получаете список терминов, а затем выполняете собственный запрос для каждого термина, они действительно дороги. Скорее запросите все сообщения и один раз, а затем используйте usort() для сортировки результатов

  • Создайте запрос в соответствии с тем, что вам нужно. В большинстве случаев нам нужно только запрашивать сообщения, чтобы их идентификаторы могли перейти к другой функции. В подобных случаях запрашивают только идентификаторы сообщений. Это действительно экономит ресурсы. Просто добавьте 'fields'=>'ids', к вашим аргументам запроса

  • Чтобы ускорить запросы без get_posts() страницы, используйте get_posts() или просто передайте 'no_found_rows'=>true для WP_Query ( это именно то, что делают get_posts ). Это пропускает процесс разбивки на страницы и экономит ресурсы на огромных db's

Это просто подразумевается как некоторый ориентир для ускорения запроса. Есть еще кое-что для ускорения запросов.

Есть ли недостатки в использовании фильтра для аргументов запроса? Представление? Что-то другое?

Я не понимаю, почему могут быть проблемы. Если вы создаете коммерческую тему, вы определенно делаете это правильно. Создание чего-то фильтруемого облегчает жизнь авторов детской темы. Это может стоить милли милли милли секунд, но это определенно время хорошо используется. Это похоже на санитарию. Санитария требует времени и ресурсов ( хотя это очень мало ), но расходы на миллисекунду больше на что-то могут спасти ваш сайт от взлома и уничтожения

ИМХО, вам нужно будет изучить другие способы ускорения запроса, а не компрометать удобство и удобство обслуживания. Вариант 2 – это то, что вы должны делать для коммерческих тем

IDEA ( может быть немного за борт 😉 )

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

В следующем примере мы будем использовать настраиваемый параметр query_no который мы дадим численные значения

Запросы

 $q1 = new WP_Query( ['query_no' => 1] ); $q2 = new WP_Query( ['query_no' => 2] ); $q3 = new WP_Query( ['query_no' => 3] ); 

pre_get_posts

 add_action( 'pre_get_posts', function( $q ) { if ( $q->get( 'query_no' ) == 1 ) { $q->set( 'posts_per_page', -1 ); // Add any other extra arguments to set } if ( $q->get( 'query_no' ) == 2 ) { $q->set( 'post_type', ['post', 'page'] ); // Add any other extra arguments to set } if ( $q->get( 'query_no' ) == 3 ) { $q->set( 'post_status', 'trash' ); // Add any other extra arguments to set } } ); 

Пользователь теперь может добавлять дополнительные аргументы или изменять прошедшие

 add_action( 'pre_get_posts', function( $q ) { if ( $q->get( 'query_no' ) == 2 ) { // Lets add another post type $post_types = $q->get( 'post_type' ); $post_types = array_merge( $post_types, ['my_post_type'] ); $q->set( 'post_type' , $post_types ); $q->set( 'posts_per_page', -1 ); // Add any other extra arguments to set } }, 11 // Make sure this runs after the default action );