¿Cómo extender WP_Query para incluir una tabla personalizada en la consulta?

Descargo de responsabilidad importante: la forma correcta de hacer esto NO es modificando la estructura de tu tabla, sino usando wp_usermeta. Así no necesitarás crear consultas SQL personalizadas para consultar tus posts (aunque aún necesitarás algo de SQL personalizado para obtener una lista de todos los que reportan a un supervisor particular - en la sección de Administración, por ejemplo). Sin embargo, dado que el OP preguntó sobre escribir SQL personalizado, aquí está la mejor práctica actual para inyectar SQL personalizado en una consulta existente de WordPress.

Si estás haciendo joins complejos, no puedes simplemente usar el filtro posts_where, porque necesitarás modificar el join, el select, y posiblemente las secciones group by u order by de la consulta también.

Tu mejor opción es usar el filtro 'posts_clauses'. Este es un filtro muy útil (¡que no debe ser abusado!) que te permite añadir/modificar las diversas partes del SQL que es generado automáticamente por las muchas líneas de código en el núcleo de WordPress. La firma del callback del filtro es: function posts_clauses_filter_cb( $clauses, $query_object ){ } y espera que devuelvas $clauses.

Las Cláusulas

$clauses es un array que contiene las siguientes claves; cada clave es una cadena SQL que será usada directamente en la sentencia SQL final enviada a la base de datos:

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

Si estás añadiendo una tabla a la base de datos (solo haz esto si absolutamente no puedes aprovechar post_meta, user_meta o taxonomías) probablemente necesitarás tocar más de una de estas cláusulas, por ejemplo, fields (la parte "SELECT" de la sentencia SQL), join (todas tus tablas, además de la de tu cláusula "FROM"), y quizás orderby.

Modificando las Cláusulas

La mejor manera de hacer esto es hacer una subreferencia de la clave relevante del array $clauses que obtuviste del filtro:

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

Ahora, si modificas $join, en realidad estarás modificando directamente $clauses['join'] así que los cambios estarán en $clauses cuando lo devuelvas.

Preservando las Cláusulas Originales

Es probable (no, en serio, presta atención) que quieras preservar el SQL existente que WordPress generó para ti. Si no, probablemente deberías mirar el filtro posts_request en su lugar - esa es la consulta mySQL completa justo antes de ser enviada a la base de datos, así que puedes sobrescribirla completamente con la tuya. ¿Por qué querrías hacer esto? Probablemente no quieras.

Así que, para preservar el SQL existente en las cláusulas, recuerda añadir a las cláusulas, no asignarles (es decir: usa $join .= ' {NUEVAS COSAS SQL}'; no $join = '{SOBRESCRIBIR COSAS SQL}';. Nota que como cada elemento del array $clauses es una cadena, si quieres añadirle, probablemente querrás insertar un espacio antes de cualquier otro token de caracteres, de lo contrario probablemente crearás algún error de sintaxis SQL.

Puedes asumir que siempre habrá algo en cada una de las cláusulas, y así recordar empezar cada nueva cadena con un espacio, como en: $join .= ' my_table, o, siempre puedes añadir una pequeña línea que solo añada un espacio si lo necesitas:

$join = &$clauses['join'];
if (! empty( $join ) ) $join .= ' ';
$join .= "JOIN my_table... "; // <-- nota el espacio al final
$join .= "JOIN my_other_table... ";

return $clauses;

Eso es más una cuestión de estilo que otra cosa. Lo importante es recordar: ¡siempre deja un espacio ANTES de tu cadena si estás añadiendo a una cláusula que ya tiene algo de SQL!

Uniendo todo

La primera regla del desarrollo en WordPress es intentar usar tanta funcionalidad del núcleo como puedas. Esta es la mejor manera de asegurar que tu trabajo siga funcionando en el futuro. Supón que el equipo del núcleo decide que WordPress ahora usará SQLite u Oracle u otro lenguaje de base de datos. ¡Cualquier mySQL escrito a mano puede volverse inválido y romper tu plugin o tema! Mejor dejar que WP genere tanto SQL como sea posible por sí mismo, y solo añadir los bits que necesitas.

Así que lo primero es aprovechar WP_Query para generar tanto de tu consulta base como sea posible. El método exacto que usamos para hacer esto depende en gran medida de dónde se supone que aparece esta lista de posts. Si es una subsección de la página (no tu consulta principal) usarías get_posts(); si es la consulta principal, supongo que podrías usar query_posts() y terminarlo, pero la forma correcta de hacerlo es interceptar la consulta principal antes de que llegue a la base de datos (y consuma ciclos del servidor) así que usa el filtro request.

Bien, así que has generado tu consulta y el SQL está a punto de ser creado. Bueno, de hecho, ya ha sido creado, solo no enviado a la base de datos. Al usar el filtro posts_clauses, vas a añadir tu tabla de relaciones de empleados a la mezcla. Llamemos a esta tabla {$wpdb->prefix} . 'user_relationship', y es una tabla de intersección. (Por cierto, recomiendo que generalices esta estructura de tabla y la conviertas en una tabla de intersección adecuada con los siguientes campos: 'relationship_id', 'user_id', 'related_user_id', 'relationship_type'; esto es mucho más flexible y potente... pero me desvío).

Si entiendo lo que quieres hacer, quieres pasar un ID de Líder y luego ver solo los posts de los Seguidores de ese Líder. Espero haber entendido bien. Si no es correcto, tendrás que tomar lo que digo y adaptarlo a tus necesidades. Seguiré con tu estructura de tabla: tenemos un leader_id y un follower_id. Así que el JOIN será en {$wpdb->posts}.post_author como clave foránea al 'follower_id' en tu tabla 'user_relationship'.

add_filter( 'posts_clauses', 'filter_by_leader_id', 10, 2 ); // necesitamos el 2 porque queremos obtener todos los argumentos

function filter_by_leader_id( $clauses, $query_object ){
  // No sé cómo pretendes pasar el leader_id, así que asumamos que es un global
  global $leader_id;

  // En este ejemplo solo quiero afectar una consulta en la página de inicio.
  // Aquí es donde se usa $query_object, para ayudarnos a evitar afectar
  // TODAS las consultas (ya que TODAS las consultas pasan por este filtro)
  if ( $query_object->is_home() ){
    // Ahora, añadamos tu tabla al SQL
    $join = &$clauses['join'];
    if (! empty( $join ) ) $join .= ' '; // añade un espacio solo si es necesario (¡para nota!)
    $join .= "JOIN {$wpdb->prefix}employee_relationship EMP_R ON EMP_R.follower_id = {$wpdb->posts}.author_id";

    // Y asegurémonos de añadirlo a nuestros criterios de selección
    $where = &$clauses['where'];
    // En cualquier caso, siempre empiezas con AND, porque siempre hay una declaración '1=1' como la primera declaración de la cláusula WHERE que WP añade.
    // ¡Solo no olvides el espacio inicial!
    $where .= " AND EMP_R.leader_id={$leader_id}"; // asumiendo que $leader_id es siempre (int)

    // Y asumo que querrás los posts "agrupados" por id de usuario, así que modifiquemos la cláusula groupby
    $groupby = &$clauses['groupby'];
    // Necesitamos anteponer, así que...
    if (! empty( $groupby ) ) $groupby = ' ' . $groupby; // Para los presumidos
    $groupby = "{$wpdb->posts}.post_author" . $groupby;
  }

  // En cualquier caso, necesitamos devolver nuestras cláusulas...
  return $clauses;
}

Puedes hacer esto con una solución completamente en SQL usando el filtro posts_where. Aquí tienes un ejemplo de cómo hacerlo:

if( alguna condición ) 
    add_filter( 'posts_where', 'wpse50305_leader_where' );
    // lol, el ID de la pregunta es el mismo hacia adelante y hacia atrás

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;
}

Creo que también puede haber una forma de hacer esto con un JOIN, pero no se me ocurre cómo. Seguiré probando y actualizaré la respuesta si lo consigo.

Alternativamente, como sugirió @kaiser, puedes dividirlo en dos partes: obtener los líderes y hacer la consulta. Tengo la sensación de que esto podría ser menos eficiente, pero sin duda es la forma más comprensible de hacerlo. Tendrías que probar la eficiencia por ti mismo para determinar qué método es mejor, ya que las consultas SQL anidadas pueden volverse bastante lentas.

DE LOS COMENTARIOS:

Deberías colocar la función en tu functions.php y hacer el add_filter() justo antes de que se llame al método query() de WP_Query. Inmediatamente después, deberías hacer un remove_filter() para que no afecte a las demás consultas.

Etiqueta de Plantilla

Simplemente coloca ambas funciones en tu archivo functions.php. Luego ajusta la primera función y añade el nombre de tu tabla personalizada. Necesitarás algo de prueba/error para eliminar el ID del usuario actual dentro del array resultante (ver comentario).

/**
 * Obtener los "Líderes" del usuario actual
 * @param int $user_id El ID del usuario actual
 * @return array $query Los líderes
 */
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
        ",
        // Edita el nombre de la tabla
        "{$wpdb->prefix}nombre_tabla_personalizada",
        $user_id
    ) );
}

/**
 * Obtener un array de posts que contienen publicaciones  
 * de los "Líderes" que el usuario actual sigue
 * @return array $posts Posts que son del "Líder" actual
 */
function wpse50305_list_posts_by_leader()
{
    get_currentuserinfo();
    global $current_user;

    $user_id = $current_user->ID;

    $leaders = wpse50305_get_leaders( $user_id );
    // podría ser que necesites iterar sobre $leaders
    // y eliminar los IDs de seguidores

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

Dentro de la plantilla

Aquí puedes hacer lo que quieras con tus resultados.

foreach ( wpse50305_list_posts_by_leader() as $post )
{
    // haz algo con $post
}

NOTA No tenemos datos de prueba, etc. así que lo anterior es un poco de adivinanza. Asegúrate de que tú edites esta respuesta con lo que te funcionó, para tener un resultado satisfactorio para futuros lectores. Aprobaré la edición en caso de que tengas muy baja reputación. También puedes borrar esta nota después. Gracias.

_{Nota: Esta respuesta es para evitar discusiones extendidas en los comentarios}

1. Aquí está el código del OP de los comentarios, para agregar el primer conjunto de usuarios de prueba. Debe modificarse a un ejemplo del mundo real.

   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 ) );
       }
   }
   

   OP Sobre la Prueba Para esto agregué alrededor de 47K usuarios desde un archivo csv. Luego, ejecuté un bucle for para que los primeros 45 usuarios siguieran a todos los demás usuarios.

   • Esto resultó en 3,704,951 registros guardados en mi tabla personalizada.
   • Inicialmente, la solución de @m0r7if3r me dio un tiempo de consulta de 95 segs, que bajó a 0.020 ms después de activar la indexación en la columna leader_id. La memoria total de PHP consumida fue alrededor de 20MB.
   • Por otro lado, tu solución tomó entre 2 a 5 segs para la consulta con indexación activada. La memoria total de PHP consumida fue alrededor de 117MB.

2. Mi respuesta a esta ↑ prueba:

   una prueba más "realista": Que cada usuario siga a $leader_amount = rand( 0, 5 ); y luego agregar el número de $leader_amount x $random_ids = rand( 0, 47000 ); a cada usuario. Hasta ahora lo que sabemos es: Mi solución sería extremadamente mala si un usuario sigue a todos los demás. Además: Debes mostrar cómo hiciste la prueba y dónde exactamente agregaste los temporizadores.

   También debo mencionar que el ↑ seguimiento de tiempos anterior no se puede medir realmente, ya que también tomaría el tiempo para calcular el bucle. Sería mejor recorrer el conjunto resultante de IDs en un segundo bucle.

proceso adicional aquí