Как расширить WP_Query для включения пользовательской таблицы в запрос?

Важное предупреждение: правильный способ сделать это — НЕ изменять структуру таблицы, а использовать wp_usermeta. Тогда вам не понадобится писать собственный SQL для запроса постов (хотя всё равно потребуется некоторый кастомный SQL для получения списка всех, кто подчиняется определённому руководителю — например, в разделе админки). Однако, поскольку автор вопроса спрашивал о написании кастомного SQL, вот текущие лучшие практики для вставки собственного SQL в существующий запрос WordPress.

Если вы делаете сложные JOIN-запросы, недостаточно просто использовать фильтр posts_where, потому что вам также понадобится модифицировать JOIN, SELECT и, возможно, GROUP BY или ORDER BY части запроса.

Лучший вариант — использовать фильтр 'posts_clauses'. Это очень полезный фильтр (которым не стоит злоупотреблять!), позволяющий добавлять/изменять различные части SQL-запроса, автоматически генерируемого множеством строк кода в ядре WordPress. Сигнатура функции-колбэка для этого фильтра: function posts_clauses_filter_cb( $clauses, $query_object ){ }, и она ожидает, что вы вернёте $clauses.

Части запроса (Clauses)

$clauses — это массив, содержащий следующие ключи; каждый ключ представляет собой строку SQL, которая будет напрямую использована в итоговом SQL-запросе к базе данных:

• where
• groupby
• join
• orderby
• distinct
• fields
• limits

Если вы добавляете таблицу в базу данных (делайте это только если совершенно невозможно использовать post_meta, user_meta или таксономии), вам, вероятно, понадобится изменить несколько этих частей, например, fields (часть "SELECT" в SQL), join (все ваши таблицы, кроме указанной в "FROM"), и, возможно, orderby.

Изменение частей запроса

Лучший способ сделать это — использовать ссылку на соответствующий ключ массива $clauses, полученного из фильтра:

$join = &$clauses['join'];

Теперь, если вы измените $join, вы напрямую измените $clauses['join'], поэтому изменения сохранятся в $clauses, когда вы его вернёте.

Сохранение оригинальных частей запроса

Скорее всего (нет, серьёзно, слушайте внимательно) вы захотите сохранить существующий SQL, сгенерированный WordPress. Если нет, вам, вероятно, стоит посмотреть на фильтр posts_request — это полный mySQL-запрос непосредственно перед отправкой в базу данных, так что вы можете полностью перезаписать его своим. Зачем это делать? Скорее всего, вам это не нужно.

Итак, чтобы сохранить существующий SQL в частях запроса, помните, что нужно дополнять их, а не перезаписывать (т.е. использовать $join .= ' {НОВЫЙ SQL}';, а не $join = '{ПЕРЕЗАПИСЬ SQL}';). Учитывайте, что каждый элемент массива $clauses — это строка, поэтому при дополнении лучше добавлять пробел перед другими символами, иначе вы можете получить синтаксическую ошибку SQL.

Вы можете просто предполагать, что в каждой части всегда что-то есть, и начинать каждую новую строку с пробела, например: $join .= ' my_table, или всегда добавлять пробел при необходимости:

$join = &$clauses['join'];
if (! empty( $join ) ) $join .= ' ';
$join .= "JOIN my_table... "; // <-- обратите внимание на пробел в конце
$join .= "JOIN my_other_table... ";


return $clauses;

Это скорее вопрос стиля. Главное помнить: всегда оставляйте пробел ПЕРЕД вашей строкой, если дополняете часть запроса, в которой уже есть SQL!

Собираем всё вместе

Первое правило разработки для WordPress — использовать как можно больше встроенных функций. Это лучший способ обеспечить совместимость в будущем. Предположим, команда разработчиков решит, что WordPress теперь будет использовать SQLite или Oracle или другой язык баз данных. Любой вручную написанный mySQL может стать недействительным и сломать ваш плагин или тему! Лучше позволить WordPress самому сгенерировать как можно больше SQL, а затем добавить только необходимые части.

Итак, первым делом нужно использовать WP_Query для генерации основной части вашего запроса. Точный метод зависит от того, где должен отображаться этот список постов. Если это часть страницы (не основной запрос), используйте get_posts(); если это основной запрос, можно использовать query_posts(), но правильнее перехватить основной запрос до отправки в базу данных (и потребления ресурсов сервера), используя фильтр request.

Итак, вы сгенерировали запрос, и SQL вот-вот будет создан. На самом деле, он уже создан, но ещё не отправлен в базу данных. Используя фильтр posts_clauses, вы добавите свою таблицу отношений сотрудников в запрос. Назовём эту таблицу {$wpdb->prefix} . 'user_relationship', и это таблица связей. (Кстати, я рекомендую сделать структуру этой таблицы более универсальной, превратив её в полноценную таблицу связей с полями: 'relationship_id', 'user_id', 'related_user_id', 'relationship_type'; это гораздо гибче и мощнее... но я отвлёкся).

Если я правильно понял, вы хотите передать ID лидера и затем видеть только посты его подчинённых. Надеюсь, я правильно понял. Если нет, вам придётся адаптировать сказанное под свои нужды. Я буду придерживаться вашей структуры таблицы: у нас есть leader_id и follower_id. Таким образом, JOIN будет выполняться по {$wpdb->posts}.post_author как внешнему ключу к 'follower_id' в вашей таблице 'user_relationship'.

add_filter( 'posts_clauses', 'filter_by_leader_id', 10, 2 ); // нам нужен 2, потому что мы хотим получить все аргументы

function filter_by_leader_id( $clauses, $query_object ){
  // Я не знаю, как вы планируете передавать leader_id, поэтому предположим, что это глобальная переменная
  global $leader_id;

  // В этом примере я хочу затронуть только запрос на главной странице.
  // Здесь используется $query_object, чтобы избежать влияния на ВСЕ запросы
  // (поскольку ВСЕ запросы проходят через этот фильтр)
  if ( $query_object->is_home() ){
    // Теперь добавим вашу таблицу в SQL
    $join = &$clauses['join'];
    if (! empty( $join ) ) $join .= ' '; // добавляем пробел только если нужно (для пущей важности!)
    $join .= "JOIN {$wpdb->prefix}employee_relationship EMP_R ON EMP_R.follower_id = {$wpdb->posts}.author_id";

    // И обязательно добавим это в наши критерии выборки
    $where = &$clauses['where'];
    // В любом случае, вы всегда начинаете с AND, потому что в WHERE всегда есть '1=1' в начале, добавленное WP.
    // Не забудьте ведущий пробел!
    $where .= " AND EMP_R.leader_id={$leader_id}"; // предполагаем, что $leader_id всегда (int)

    // И, предполагаю, вы хотите группировать посты по ID пользователя, так что модифицируем groupby
    $groupby = &$clauses['groupby'];
    // Нам нужно добавить в начало, так что...
    if (! empty( $groupby ) ) $groupby = ' ' . $groupby; // Для любителей выпендриваться
    $groupby = "{$wpdb->posts}.post_author" . $groupby;
  }

  // В любом случае, нам нужно вернуть наши части запроса...
  return $clauses;
}

Вы можете реализовать это полностью на SQL с помощью фильтра posts_where. Вот пример такого решения:

if( some condition ) 
    add_filter( 'posts_where', 'wpse50305_leader_where' );
    // примечание: ID вопроса одинаково читается в обе стороны

function wpse50305_leader_where( $where ) {
    $where .= $GLOBALS['wpdb']->prepare( ' AND post_author '.
        'IN ( '.
            'SELECT leader_id '.
            'FROM custom_table_name '.
            'WHERE follower_id = %s'.
        ' ) ', $follower_id );
    return $where;
}

Я думаю, что есть способ сделать это с помощью JOIN, но я пока не придумал как. Я продолжу экспериментировать и обновлю ответ, если найду решение.

Как альтернативу, как предложил @kaiser, вы можете разделить это на две части: получение лидеров и выполнение запроса. У меня есть ощущение, что это может быть менее эффективно, но определенно более понятный способ. Вам нужно будет самостоятельно проверить эффективность, чтобы определить какой метод лучше, так как вложенные SQL-запросы могут работать довольно медленно.

ИЗ КОММЕНТАРИЕВ:

Функцию следует разместить в файле functions.php, а вызов add_filter() делать непосредственно перед вызовом метода query() в WP_Query. Сразу после этого следует вызвать remove_filter(), чтобы это не повлияло на другие запросы.

Теговый шаблон

Просто поместите обе функции в ваш файл functions.php. Затем настройте первую функцию и добавьте имя вашей пользовательской таблицы. Далее вам потребуется метод проб и ошибок, чтобы исключить ID текущего пользователя из результирующего массива (см. комментарий).

/**
 * Получить "Лидеров" текущего пользователя
 * @param int $user_id ID текущего пользователя
 * @return array $query Массив лидеров
 */
function wpse50305_get_leaders( $user_id )
{
    global $wpdb;

    return $wpdb->query( $wpdb->prepare(
        "
            SELECT `leader_id`, `follower_id`
            FROM %s
                WHERE `follower_id` = %s
            ORDERBY `leader_id` ASC
        ",
        // Измените имя таблицы
        "{$wpdb->prefix}custom_table_name"
        $user_id
    ) );
}

/**
 * Получить массив постов, содержащих записи 
 * "Лидеров", на которых подписан текущий пользователь
 * @return array $posts Посты от текущих "Лидеров"
 */
function wpse50305_list_posts_by_leader()
{
    get_currentuserinfo();
    global $current_user;

    $user_id = $current_user->ID;

    $leaders = wpse5035_get_leaders( $user_id );
    // возможно, вам потребуется пройтись по массиву $leaders
    // и исключить ID подписчиков

    return get_posts( array(
        'author' => implode( ",", $leaders )
    ) );
}

Внутри шаблона

Здесь вы можете делать с результатами все, что угодно.

foreach ( wpse50305_list_posts_by_leader() as $post )
{
    // делаем что-то с $post
}

ПРИМЕЧАНИЕ У нас нет тестовых данных и т.д., поэтому приведенный выше код является в некоторой степени предположением. Убедитесь, что вы отредактируете этот ответ, указав, что сработало у вас, чтобы у нас был удовлетворительный результат для будущих читателей. Я одобрю правку, если у вас недостаточно репутации. Затем вы также можете удалить это примечание. Спасибо.

_{Примечание: Этот ответ приведен здесь, чтобы избежать длительного обсуждения в комментариях}

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

   for ( $j = 2; $j <= 52; $j++ ) 
   {
       for ( $i = ($j + 1); $i <= 47000; $i++ )
       {
           $rows_affected = $wpdb->insert( $table_name, array( 'leader_id' => $i, 'follower_id' => $j ) );
       }
   }
   

   Автор о тесте Для этого я добавил около 47K пользователей из CSV-файла. Затем запустил цикл, чтобы первые 45 пользователей подписались на всех остальных.

   • В результате в моей кастомной таблице оказалось 3,704,951 записей.
   • Изначально решение @m0r7if3r давало время запроса 95 секунд, которое сократилось до 0.020 мс после включения индексации для колонки leader_id. Общий расход памяти PHP составил около 20MB.
   • С другой стороны, ваше решение заняло от 2 до 5 секунд для запроса с включенной индексацией. Общий расход памяти PHP составил около 117MB.

2. Мой ответ на этот ↑ тест:

   более "реалистичный" тест: пусть каждый пользователь подписывается на $leader_amount = rand( 0, 5 ); лидеров, а затем добавляется количество $leader_amount x $random_ids = rand( 0, 47000 ); для каждого пользователя. Пока что мы знаем: мое решение было бы крайне плохим, если пользователь подписан на всех остальных. Кроме того: вам нужно показать, как именно вы проводили тест и где именно добавляли таймеры.

   Также должен отметить, что ↑ приведенное измерение времени нельзя считать точным, так как оно включает время выполнения цикла. Лучше было бы пройтись по результирующему набору ID во втором цикле.

дальнейший процесс здесь