Când să folosești WP_Query vs query_posts() vs get_posts() în WordPress?

query_posts - Nu ar trebui să folosești niciodată query_posts. Pe lângă ceea ce a menționat @Rarst, cea mai mare problemă cu query_posts este că distruge obiectul principal al interogării (stocat în $wp_query). Multe plugin-uri și cod personal se bazează pe obiectul principal al interogării, așa că distrugerea acestuia înseamnă că strici funcționalitățile plugin-urilor și ale codului personal. Doar una dintre aceste funcții este funcția extrem de importantă de paginare, deci dacă strici interogarea principală, strici paginarea.

Pentru a demonstra cât de rău este query_posts, pe orice șablon, fă următoarele și compară rezultatele

var_dump( $wp_query );
query_posts( '&posts_per_page=-1' );
var_dump( $wp_query );

get_posts și WP_Query sunt metodele corecte pentru a construi interogări secundare ( precum postări înrudite, slide-uri, conținut recomandat și conținut pe pagini frontale statice ). Trebuie menționat că nu ar trebui să folosești niciuna dintre acestea în locul interogării principale pe pagina de start, pagina single sau orice tip de pagină de arhivă, deoarece va afecta funcționalitatea paginii. Dacă trebuie să modifici interogarea principală, folosește pre_get_posts pentru a face acest lucru, și nu o interogare personalizată. (ACTUALIZARE: Pentru paginile frontale statice și paginile adevărate, vezi Folosirea pre_get_posts pe pagini adevărate și pagini frontale statice*)

În esență, WP_Query este folosit de interogarea principală și este folosit și de get_posts, dar deși get_posts() utilizează WP_Query, există câteva diferențe:

• get_posts este mai rapid decât WP_Query. Diferența depinde de numărul total de postări ale site-ului. Motivul pentru aceasta este că get_posts trece implicit 'no_found_rows' => true către WP_Query, ceea ce omite/întrerupe legal paginarea. Cu 'no_found_rows' => true, WP_Query obține numărul de postări interogate, apoi se oprește, în timp ce implicit, continuă să caute toate postările care corespund interogării pentru a calcula paginarea.

  Din acest motiv, get_posts() ar trebui folosit doar pentru interogări ne-paginate. Paginarea get_posts este o adevărată mizerie. WP_Query ar trebui folosit pentru toate interogările paginate.

• get_posts() nu sunt influențate de filtrele posts_*, în timp ce WP_Query este influențat de aceste filtre. Motivul este că get_posts, implicit, trece 'suppress_filters' => true către WP_Query.

• get_posts are câțiva parametri extra precum include, exclude, numberposts și category. Acești parametri sunt transformați în parametri valizi pentru WP_Query înainte de a fi pasați către WP_Query. include este transformat în post__in, exclude în post__not_in, category în cat și numberposts în posts_per_page. Doar o notă, toți parametrii care pot fi pasați către WP_Query funcționează și cu get_posts, poți ignora și nu folosi parametrii impliciți ai get_posts.

• get_posts returnează doar proprietatea $posts a WP_Query, în timp ce WP_Query returnează întregul obiect. Acest obiect este foarte util când vine vorba de condiționale, paginare și alte informații utile care pot fi folosite în interiorul buclei.

• get_posts nu folosește bucla, ci o buclă foreach pentru a afișa postările. De asemenea, niciun tag de șablon nu este disponibil implicit. setup_postdata( $post ) trebuie folosit pentru a face tag-urile de șablon disponibile. WP_Query folosește bucla și tag-urile de șablon sunt disponibile implicit.

• get_posts trece 'ignore_sticky_posts' => 1 către WP_Query, deci get_posts ignoră implicit postările lipicioase.

Pe baza celor de mai sus, dacă să folosești get_posts sau WP_Query depinde de tine și de ce ai nevoie de fapt din interogare. Cele de mai sus ar trebui să te ghideze în alegerea ta.

Diferența de bază este că query_posts() este destinat doar modificării buclei curente. După ce ai terminat, este necesar să resetezi bucla și să o lași să continue. Această metodă este și puțin mai ușor de înțeles, pur și simplu pentru că "interogarea" ta este practic un șir URL pe care îl transmiți funcției, astfel:

query_posts('meta_key=color&meta_value=blue');

Pe de altă parte, WP_Query este mai mult un instrument de uz general și este mai aproape de scrierea directă a interogărilor MySQL decât query_posts(). De asemenea, îl poți folosi oriunde (nu doar în buclă) și nu interferează cu nicio interogare de postări în curs.

Personal, tind să folosesc WP_Query mai des. În realitate, totul se reduce la cazul tău specific.

Nu există absolut nicio necesitate de a folosi query_posts(). Tot ce face această funcție este să instantieze un nou obiect WP_Query și să realoce acel obiect nou la global wp_query.

Pentru referință, următoarea este funcția actuală query_posts().

 function query_posts($query) {
        $GLOBALS['wp_query'] = new WP_Query();
        return $GLOBALS['wp_query']->query($query);
    }

Instanțiați-vă propriul obiect WP_Query dacă doriți să creați un script personalizat de interogare în detaliu. Sau folosiți get_posts() dacă tot ce trebuie să faceți este o ușoară manipulare aici și acolo.

În orice caz, vă recomand să vă faceți o favoare și să mergeți la wp_includes/query.php și să parcurgeți clasa WP_Query.

Asigurați-vă că utilizați wp_reset_query() după ce ați folosit query_posts() deoarece va afecta și alte rezultate ale interogării.

Dacă îmi amintesc corect, în esență "the loop" efectuează WP_Query în fișierele de bază, dar într-un mod mai ușor de înțeles.

• query_posts(): poate fi utilizat într-un singur caz și numai dacă trebuie să modifici interogarea principală. Acesta setează multe variabile globale;
• get_posts(): este foarte similar ca mecanism și acceptă aceleași argumente, dar returnează un array de postări
• WP_Query: poți crea și lucra cu propriul obiect al acestuia. Un pic mai complex, mai puține restricții, este sigur să-l folosești oriunde.