Cum să extinzi WP_Query pentru a include un tabel personalizat în interogare?

Notă importantă: metoda corectă de a face acest lucru NU este modificarea structurii tabelei, ci utilizarea wp_usermeta. În acest fel, nu va fi nevoie să creați interogări SQL personalizate pentru postări (deși tot va trebui să utilizați SQL personalizat pentru a obține o listă cu toți cei care raportează unui anumit supervizor - în secțiunea Admin, de exemplu). Totuși, deoarece OP a întrebat despre scrierea de SQL personalizat, iată cea mai bună practică actuală pentru injectarea de SQL personalizat într-o interogare WordPress existentă.

Dacă faci join-uri complexe, nu poți folosi doar filtrul posts_where, deoarece va trebui să modifici secțiunile join, select și posibil group by sau order by ale interogării.

Cea mai bună opțiune este să folosești filtrul 'posts_clauses'. Acesta este un filtru extrem de util (care nu ar trebui abuzat!) care îți permite să adaugi/modifici diferite porțiuni din SQL generat automat de numeroasele linii de cod din nucleul WordPress. Semnătura funcției de callback este: function posts_clauses_filter_cb( $clauses, $query_object ){ } și se așteaptă să returnezi $clauses.

Clauzele

$clauses este un array care conține următoarele chei; fiecare cheie reprezintă un șir SQL care va fi folosit direct în interogarea finală trimisă bazei de date:

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

Dacă adaugi o tabelă în baza de date (fă asta doar dacă nu poți folosi post_meta, user_meta sau taxonomii), probabil va trebui să modifici mai multe dintre aceste clauze, de exemplu, fields (porțiunea "SELECT" din interogare), join (toate tabelele tale, în afară de cea din clauza "FROM") și poate orderby.

Modificarea clauzelor

Cea mai bună metodă este să faci o subreferință la cheia relevantă din array-ul $clauses obținut din filtru:

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

Acum, dacă modifici $join, vei modifica direct $clauses['join'], astfel încât modificările vor fi în $clauses când îl returnezi.

Păstrarea clauzelor originale

Este foarte probabil (serios, ascultă acum) să vrei să păstrezi SQL-ul generat de WordPress. Dacă nu, ar trebui să te uiți la filtrul posts_request - acesta reprezintă întreaga interogare mySQL chiar înainte de a fi trimisă la bază, așadar poți să o suprascrii complet cu a ta. De ce ai vrea asta? Probabil că nu.

Deci, pentru a păstra SQL-ul existent în clauze, amintește-ți să adaugi la clauze, nu să le suprascrii (adică: folosește $join .= ' {NOU SQL}'; nu $join = '{SQL SUPRASCRIS}';). Reține că, deoarece fiecare element din array-ul $clauses este un șir, dacă vrei să adaugi la el, probabil va trebui să inserezi un spațiu înaintea altor tokeni, altfel vei crea erori de sintaxă SQL.

Poți presupune că întotdeauna va exista ceva în fiecare clauză și să începi fiecare șir nou cu un spațiu, ca în: $join .= ' my_table, sau poți adăuga o linie care adaugă un spațiu doar dacă este necesar:

$join = &$clauses['join'];
if (! empty( $join ) ) $join .= ' ';
$join .= "JOIN my_table... "; // <-- observă spațiul la sfârșit
$join .= "JOIN my_other_table... ";


return $clauses;

Aceasta este mai degrabă o chestiune de stil. Important este să-ți amintești: lasă întotdeauna un spațiu ÎNAINTE de șirul tău dacă adaugi la o clauză care deja conține SQL!

Punând totul cap la cap

Prima regulă în dezvoltarea WordPress este să încerci să folosești cât mai mult din funcționalitățile de bază. Acesta este cel mai bun mod de a-ți viitoriza munca. Să presupunem că echipa WordPress decide să folosească SQLite sau Oracle sau alt limbaj de baze de date. Orice mySQL scris manual poate deveni invalid și poate strica plugin-ul sau tema ta! Mai bine lași WordPress să genereze cât mai mult SQL și să adaugi doar părțile necesare.

Deci, primul pas este să folosești WP_Query pentru a genera cât mai mult din interogarea ta de bază. Metoda exactă depinde de unde ar trebui să apară această listă de postări. Dacă este o sub-secțiune a paginii (nu interogarea principală), poți folosi get_posts(); dacă este interogarea principală, poți folosi query_posts(), dar metoda corectă este să interceptezi interogarea principală înainte să ajungă la bază (și să consume resurse), deci folosește filtrul request.

Deci, ai generat interogarea și SQL-ul este pe cale să fie creat. De fapt, a fost deja creat, dar nu a fost trimis la bază. Folosind filtrul posts_clauses, vei adăuga tabela de relații angajați în interogare. Să numim această tabelă {$wpdb->prefix} . 'user_relationship', și este o tabelă de intersecție. (Apropo, recomand să generalizezi structura acestei tabele și să o transformi într-o tabelă de intersecție corectă cu următoarele câmpuri: 'relationship_id', 'user_id', 'related_user_id', 'relationship_type'; este mult mai flexibil și puternic... dar mă abat).

Dacă am înțeles corect, vrei să transmiți ID-ul unui Lider și apoi să vezi doar postările Urmăritorilor acelui Lider. Sper că am înțeles corect. Dacă nu, va trebui să adaptezi ce spun eu la nevoile tale. Voi rămâne la structura ta: avem un leader_id și un follower_id. Deci JOIN-ul va fi pe {$wpdb->posts}.post_author ca cheie străină către 'follower_id' din tabela ta 'user_relationship'.

add_filter( 'posts_clauses', 'filter_by_leader_id', 10, 2 ); // avem nevoie de 2 pentru a obține toți parametrii

function filter_by_leader_id( $clauses, $query_object ){
  // Nu știu cum intenționezi să transmiți leader_id, așa că presupun că este o variabilă globală
  global $leader_id;

  // În acest exemplu, vreau să afectez doar interogarea de pe pagina principală
  // Aici folosim $query_object pentru a evita să afectăm TOATE interogările
  // (deoarece TOATE interogările trec prin acest filtru)
  if ( $query_object->is_home() ){
    // Acum, să adăugăm tabela ta în SQL
    $join = &$clauses['join'];
    if (! empty( $join ) ) $join .= ' '; // adaugă un spațiu doar dacă este necesar
    $join .= "JOIN {$wpdb->prefix}employee_relationship EMP_R ON EMP_R.follower_id = {$wpdb->posts}.author_id";

    // Și să ne asigurăm că o adăugăm la criteriile de selecție
    $where = &$clauses['where'];
    // Întotdeauna începe cu AND, deoarece există întotdeauna o declarație '1=1' ca primă declarație în clauza WHERE adăugată de WP
    // Nu uita spațiul de la început!
    $where .= " AND EMP_R.leader_id={$leader_id}"; // presupunând că $leader_id este întotdeauna (int)

    // Și presupun că vei dori să grupezi postările după ID-ul utilizatorului, deci să modificăm clauza groupby
    $groupby = &$clauses['groupby'];
    // Trebuie să adăugăm la început, deci...
    if (! empty( $groupby ) ) $groupby = ' ' . $groupby; // Pentru perfecționiști
    $groupby = "{$wpdb->posts}.post_author" . $groupby;
  }

  // În orice caz, trebuie să returnăm clauzele noastre...
  return $clauses;
}

Puteți face acest lucru cu o soluție pur SQL folosind filtrul posts_where. Iată un exemplu:

if( o anumită condiție ) 
    add_filter( 'posts_where', 'wpse50305_leader_where' );
    // lol, ID-ul întrebării este același în ambele sensuri

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

Cred că ar putea exista și o metodă de a face asta cu JOIN, dar nu reușesc să o găsesc. Voi continua să experimentez și voi actualiza răspunsul dacă reușesc.

Alternativ, așa cum a sugerat @kaiser, puteți împărți problema în două părți: obținerea liderilor și efectuarea interogării. Am senzația că această abordare ar putea fi mai puțin eficientă, dar este cu siguranță mai ușor de înțeles. Ar trebui să testați eficiența pentru a determina care metodă este mai bună, deoarece interogările SQL imbricate pot deveni foarte lente.

DIN COMENTARII:

Ar trebui să plasați funcția în fișierul functions.php și să apelați add_filter() imediat înainte de apelarea metodei query() din WP_Query. Imediat după aceea, ar trebui să folosiți remove_filter() pentru a evita afectarea altor interogări.

Tag-ul Șablon

Pur și simplu plasați ambele funcții în fișierul dumneavoastră functions.php. Apoi ajustați prima funcție și adăugați numele tabelului personalizat. Apoi aveți nevoie de câteva încercări/erori pentru a elimina ID-ul utilizatorului curent din tabloul rezultat (vezi comentariul).

/**
 * Obține "Liderii" utilizatorului curent
 * @param int $user_id ID-ul utilizatorului curent
 * @return array $query Liderii
 */
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ți numele tabelului
        "{$wpdb->prefix}custom_table_name"
        $user_id
    ) );
}

/**
 * Obține un tablou de postări care conțin postări de la 
 * "Liderii" pe care îi urmărește utilizatorul curent
 * @return array $posts Postări care sunt de la "Liderul" curent
 */
function wpse50305_list_posts_by_leader()
{
    get_currentuserinfo();
    global $current_user;

    $user_id = $current_user->ID;

    $leaders = wpse5035_get_leaders( $user_id );
    // este posibil să fie nevoie să parcurgeți $leaders
    // și să eliminați ID-urile urmăritorilor

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

În interiorul șablonului

Aici puteți face orice doriți cu rezultatele dumneavoastră.

foreach ( wpse50305_list_posts_by_leader() as $post )
{
    // faceți ceva cu $post
}

NOTĂ Nu avem date de test, etc. așa că cele de mai sus sunt un pic de ghicit. Asigurați-vă că dumneavoastră editați acest răspuns cu ceea ce a funcționat pentru dumneavoastră, astfel încât să avem un rezultat satisfăcător pentru cititorii viitori. Voi aproba editarea în cazul în care aveți prea puțină reputație. Puteți apoi șterge și această notă. Mulțumesc.

_{Notă: Acest răspuns este pentru a evita discuții extinse în comentarii}

1. Iată codul OP din comentarii, pentru a adăuga primul set de utilizatori de test. Trebuie modificat pentru un exemplu din lumea 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 Despre Test Pentru asta am adăugat aproximativ 47K de utilizatori dintr-un fișier csv. Ulterior, am rulat un for loop pentru a face primii 45 de utilizatori să îi urmărească pe toți ceilalți utilizatori.

   • Asta a rezultat în 3.704.951 de înregistrări salvate în tabela mea personalizată.
   • Inițial, soluția lui @m0r7if3r mi-a dat un timp de interogare de 95 secunde, care a scăzut la 0,020 ms după activarea indexării pe coloana leader_id. Memoria PHP totală consumată a fost de aproximativ 20MB.
   • Pe de altă parte, soluția ta a durat între 2 și 5 secunde pentru interogare cu indexarea ACTIVATĂ. Memoria PHP totală consumată a fost de aproximativ 117MB.

2. Răspunsul meu la acest ↑ test:

   un test mai "realist": Fiecare utilizator să urmărească un $leader_amount = rand( 0, 5 ); și apoi să adauge numărul de $leader_amount x $random_ids = rand( 0, 47000 ); pentru fiecare utilizator. Până acum știm următoarele: Soluția mea ar fi extrem de proastă dacă un utilizator îi urmărește pe toți ceilalți. În plus: Trebuie să arăți cum ai făcut testul și unde exact ai adăugat cronometrele.

   Trebuie să menționez și că ↑ măsurarea timpului de mai sus nu poate fi cu adevărat măsurată, deoarece ar include și timpul necesar pentru calculul buclei. Mai bine ar fi să parcurgi setul rezultat de ID-uri într-o a doua buclă.

continuare aici