Come estendere WP_Query per includere una tabella personalizzata nella query?

Importante avviso: il modo corretto per farlo NON è modificare la struttura della tabella, ma utilizzare wp_usermeta. In questo modo non sarà necessario creare SQL personalizzati per interrogare i post (anche se potrebbe servire comunque un SQL personalizzato per ottenere un elenco di tutti coloro che rispondono a un determinato supervisore - nella sezione Admin, ad esempio). Tuttavia, visto che l'OP ha chiesto come scrivere SQL personalizzati, ecco le migliori pratiche attuali per iniettare SQL personalizzati in una query esistente di WordPress.

Se stai facendo join complessi, non puoi semplicemente usare il filtro posts_where, perché dovrai modificare anche il join, il select e possibilmente le sezioni group by o order by della query.

La soluzione migliore è usare il filtro 'posts_clauses'. Questo è un filtro estremamente utile (che non dovrebbe essere abusato!) che ti permette di aggiungere/modificare le varie parti dell'SQL generato automaticamente dalle moltissime righe di codice nel core di WordPress. La firma del callback del filtro è: function posts_clauses_filter_cb( $clauses, $query_object ){ } e si aspetta che tu restituisca $clauses.

Le Clausole

$clauses è un array che contiene le seguenti chiavi; ogni chiave è una stringa SQL che verrà usata direttamente nell'istruzione SQL finale inviata al database:

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

Se stai aggiungendo una tabella al database (fallo solo se assolutamente non puoi usare post_meta, user_meta o tassonomie) probabilmente dovrai toccare più di una di queste clausole, ad esempio fields (la parte "SELECT" dell'istruzione SQL), join (tutte le tue tabelle, oltre a quella nella clausola "FROM"), e forse orderby.

Modificare le Clausole

Il modo migliore per farlo è fare riferimento alla chiave rilevante dall'array $clauses che hai ottenuto dal filtro:

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

Ora, se modifichi $join, modificherai direttamente $clauses['join'] quindi le modifiche saranno presenti in $clauses quando lo restituirai.

Preservare le Clausole Originali

È probabile (no, sul serio, ascolta) che tu voglia preservare l'SQL esistente generato da WordPress. Altrimenti, dovresti probabilmente guardare il filtro posts_request invece - che è la query mySQL completa appena prima che venga inviata al database, quindi puoi completamente sovrascriverla con la tua. Perché vorresti farlo? Probabilmente non vorresti.

Quindi, per preservare l'SQL esistente nelle clausole, ricordati di aggiungere alle clausole, non di assegnarle (es: usa $join .= ' {NUOVO SQL}'; non $join = '{SOVRASCRIVI SQL}';. Nota che poiché ogni elemento dell'array $clauses è una stringa, se vuoi aggiungere, probabilmente dovrai inserire uno spazio prima di qualsiasi altro token di caratteri, altrimenti potresti creare qualche errore di sintassi SQL.

Puoi semplicemente assumere che ci sarà sempre qualcosa in ognuna delle clausole, e quindi ricordati di iniziare ogni nuova stringa con uno spazio, come in: $join .= ' my_table, oppure puoi sempre aggiungere una piccola riga che aggiunge uno spazio solo se necessario:

$join = &$clauses['join'];
if (! empty( $join ) ) $join .= ' ';
$join .= "JOIN my_table... "; // <-- nota lo spazio alla fine
$join .= "JOIN my_other_table... ";


return $clauses;

Questa è più una questione di stile che altro. La cosa importante da ricordare è: lascia sempre uno spazio PRIMA della tua stringa se stai aggiungendo a una clausola che ha già dell'SQL!

Mettendo tutto insieme

La prima regola dello sviluppo WordPress è cercare di usare il più possibile le funzionalità del core. Questo è il modo migliore per rendere il tuo lavoro futuro-proof. Supponiamo che il core team decida che WordPress utilizzerà ora SQLite o Oracle o qualche altro linguaggio di database. Qualsiasi mySQL scritto a mano potrebbe diventare invalido e rompere il tuo plugin o tema! Meglio lasciare che WP generi da solo più SQL possibile, e aggiungere solo i pezzi che ti servono.

Quindi il primo ordine di business è sfruttare WP_Query per generare più possibile della tua query base. Il metodo esatto che usiamo per farlo dipende in gran parte da dove questa lista di post dovrebbe apparire. Se è una sotto-sezione della pagina (non la tua query principale) useresti get_posts(); se è la query principale, suppongo che potresti usare query_posts() e finirla lì, ma il modo corretto per farlo è intercettare la query principale prima che arrivi al database (e consumi cicli del server) quindi usa il filtro request.

Ok, quindi hai generato la tua query e l'SQL sta per essere creato. Beh, in realtà, è già stato creato, solo non inviato al database. Usando il filtro posts_clauses, aggiungerai la tua tabella delle relazioni dei dipendenti nel mix. Chiamiamo questa tabella {$wpdb->prefix} . 'user_relationship', ed è una tabella di intersezione. (A proposito, ti consiglio di generalizzare questa struttura di tabella e trasformarla in una vera tabella di intersezione con i seguenti campi: 'relationship_id', 'user_id', 'related_user_id', 'relationship_type'; questo è molto più flessibile e potente... ma sto divagando).

Se ho capito bene quello che vuoi fare, vuoi passare l'ID di un Leader e poi vedere solo i post dei Follower di quel Leader. Spero di aver capito bene. Se non è corretto, dovrai adattare quello che dico alle tue esigenze. Mi atterrò alla tua struttura di tabella: abbiamo un leader_id e un follower_id. Quindi il JOIN sarà su {$wpdb->posts}.post_author come chiave esterna al 'follower_id' sulla tua tabella 'user_relationship'.

add_filter( 'posts_clauses', 'filter_by_leader_id', 10, 2 ); // abbiamo bisogno del 2 perché vogliamo ottenere tutti gli argomenti

function filter_by_leader_id( $clauses, $query_object ){
  // Non so come intendi passare il leader_id, quindi supponiamo sia un globale
  global $leader_id;

  // In questo esempio voglio influenzare solo una query nella home page.
  // Qui viene usato $query_object, per aiutarci a evitare di influenzare
  // TUTTE le query (poiché TUTTE le query passano attraverso questo filtro)
  if ( $query_object->is_home() ){
    // Ora, aggiungiamo la tua tabella nell'SQL
    $join = &$clauses['join'];
    if (! empty( $join ) ) $join .= ' '; // aggiungi uno spazio solo se necessario (per i punti bonus!)
    $join .= "JOIN {$wpdb->prefix}employee_relationship EMP_R ON EMP_R.follower_id = {$wpdb->posts}.author_id";

    // E assicuriamoci di aggiungerlo ai nostri criteri di selezione
    $where = &$clauses['where'];
    // In ogni caso, inizi sempre con AND, perché c'è sempre un'istruzione '1=1' come prima istruzione della clausola WHERE che viene aggiunta da WP/
    // Solo non dimenticare lo spazio iniziale!
    $where .= " AND EMP_R.leader_id={$leader_id}"; // assumendo che $leader_id sia sempre (int)

    // E suppongo che vorrai i post "raggruppati" per id utente, quindi modifichiamo la clausola groupby
    $groupby = &$clauses['groupby'];
    // Dobbiamo prependere, quindi...
    if (! empty( $groupby ) ) $groupby = ' ' . $groupby; // Per i gradassi
    $groupby = "{$wpdb->posts}.post_author" . $groupby;
  }

  // In ogni caso, dobbiamo restituire le nostre clausole...
  return $clauses;
}

Puoi farlo con una soluzione interamente SQL utilizzando il filtro posts_where. Ecco un esempio:

if( qualche condizione ) 
    add_filter( 'posts_where', 'wpse50305_leader_where' );
    // lol, l'ID della domanda è lo stesso avanti e indietro

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

Penso che ci possa essere un modo per farlo anche con JOIN, ma non riesco a trovare una soluzione. Continuerò a sperimentare e aggiornerò la risposta se ci riuscirò.

In alternativa, come suggerito da @kaiser, puoi dividerlo in due parti: ottenere i leader e fare la query. Ho la sensazione che questo potrebbe essere meno efficiente, ma è sicuramente il modo più comprensibile. Dovresti testare l'efficienza per determinare quale metodo è migliore, poiché le query SQL annidate possono diventare piuttosto lente.

DAL COMMENTI:

Dovresti inserire la funzione nel tuo functions.php e fare l'add_filter() subito prima che venga chiamato il metodo query() di WP_Query. Subito dopo, dovresti usare remove_filter() in modo che non influisca sulle altre query.

Tag del Template

Inserisci entrambe le funzioni nel tuo file functions.php. Poi modifica la prima funzione e aggiungi il nome della tua tabella personalizzata. Dovrai fare qualche prova/errore per eliminare l'ID dell'utente corrente dall'array risultante (vedi commento).

/**
 * Ottieni i "Leader" dell'utente corrente
 * @param int $user_id L'ID dell'utente corrente
 * @return array $query I leader
 */
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
        ",
        // Modifica il nome della tabella
        "{$wpdb->prefix}custom_table_name"
        $user_id
    ) );
}

/**
 * Ottieni un array di post che contengono articoli scritti dai
 * "Leader" seguiti dall'utente corrente
 * @return array $posts Post scritti dal "Leader" corrente
 */
function wpse50305_list_posts_by_leader()
{
    get_currentuserinfo();
    global $current_user;

    $user_id = $current_user->ID;

    $leaders = wpse5035_get_leaders( $user_id );
    // potrebbe essere necessario ciclare su $leaders
    // per rimuovere gli ID dei follower

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

All'interno del template

Qui puoi fare ciò che vuoi con i risultati ottenuti.

foreach ( wpse50305_list_posts_by_leader() as $post )
{
    // fai qualcosa con $post
}

NOTA Non abbiamo dati di test, ecc. quindi quanto sopra è un po' un'ipotesi. Assicurati di modificare questa risposta con ciò che ha funzionato per te, così avremo un risultato soddisfacente per i lettori futuri. Approverò la modifica nel caso tu abbia un reputation troppo bassa. Potrai poi anche cancellare questa nota. Grazie.

_{Nota: Questa risposta è qui per evitare discussioni prolungate nei commenti}

1. Ecco il codice dell'OP dai commenti, per aggiungere il primo set di utenti di test. Deve essere modificato per un esempio reale.

   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 Sul Test Per questo ho aggiunto circa 47K utenti da un file csv. Poi, ho eseguito un ciclo for per far sì che i primi 45 utenti seguissero tutti gli altri utenti.

   • Questo ha portato a 3.704.951 record salvati nella mia tabella personalizzata.
   • Inizialmente, la soluzione di @m0r7if3r mi dava un tempo di query di 95 sec, sceso a 0.020 ms dopo aver attivato l'indicizzazione sulla colonna leader_id. La memoria PHP totale consumata era di circa 20MB.
   • D'altra parte, la tua soluzione ha impiegato circa 2-5 sec per la query con l'indicizzazione attiva. La memoria PHP totale consumata era di circa 117MB.

2. La mia risposta a questo ↑ test:

   un test più "realistico": Fai sì che ogni utente segua un $leader_amount = rand( 0, 5 ); e poi aggiungi il numero di $leader_amount x $random_ids = rand( 0, 47000 ); a ogni utente. Finora sappiamo che: La mia soluzione sarebbe estremamente pessima se un utente seguisse tutti gli altri utenti. Inoltre: Dovresti mostrare come hai fatto il test e dove esattamente hai aggiunto i timer.

   Devo anche precisare che il ↑ tracking del tempo sopra non può essere realmente misurato, poiché includerebbe anche il tempo per calcolare il ciclo. Sarebbe meglio scorrere il set risultante di ID in un secondo ciclo.

ulteriore processo qui