Când să folosești WP_query(), query_posts() și pre_get_posts

Există două contexte diferite pentru buclele (loops):

• bucla principală care are loc în funcție de cererea URL-ului și este procesată înainte de încărcarea șabloanelor
• bucla secundară care are loc în orice alt mod, apelată din fișierele șabloane sau altfel

Problema cu query_posts() este că este o buclă secundară care încearcă să fie cea principală și eșuează lamentabil. Prin urmare, uită că există.

Pentru a modifica bucla principală

• nu folosi query_posts()
• folosește filtrul pre_get_posts cu verificarea $query->is_main_query()
• alternativ, poți folosi filtrul request (puțin prea dur, așa că varianta anterioară este mai bună)

Pentru a rula o buclă secundară

Folosește new WP_Query sau get_posts() care sunt practic interschimbabile (ultima este un wrapper subțire pentru prima).

Pentru curățare

Folosește wp_reset_query() dacă ai folosit query_posts() sau ai modificat direct variabila globală $wp_query - deci aproape niciodată nu vei avea nevoie.

Folosește wp_reset_postdata() dacă ai folosit the_post() sau setup_postdata() sau ai modificat variabila globală $post și trebuie să restaurezi starea inițială a elementelor legate de postare.

Există scenarii legitime pentru utilizarea funcției query_posts($query), de exemplu:

1. Doriți să afișați o listă de articole sau articole de tip custom-post-type pe o pagină (folosind un șablon de pagină)

2. Doriți ca paginarea acestor articole să funcționeze

De ce ați dori să le afișați pe o pagină în loc să folosiți un șablon de arhivă?

1. Este mai intuitiv pentru un administrator (clientul dvs.) - pot vedea pagina în lista 'Pagini'

2. Este mai ușor de adăugat în meniuri (fără pagina, ar trebui să adauge URL-ul direct)

3. Dacă doriți să afișați conținut suplimentar (text, imagine reprezentativă sau orice meta-conținut personalizat) pe șablon, îl puteți obține ușor de pe pagină (și totul are mai mult sens și pentru client). Dacă ați folosit un șablon de arhivă, ați fi nevoit fie să introduceți conținutul suplimentar direct în cod, fie să folosiți opțiuni din temă/plugin (ceea ce este mai puțin intuitiv pentru client)

Iată un exemplu simplificat de cod (care ar fi în șablonul paginii - de ex. page-page-of-posts.php):

/**
 * Template Name: Pagină cu Articole
 */

while(have_posts()) { // bucla principală originală - conținutul paginii
  the_post();
  the_title(); // titlul paginii
  the_content(); // conținutul paginii
  // etc...
}

// acum afișăm lista de articole de tip custom-post-type

// mai întâi obținem parametrii de paginare
$paged = 1;
if(get_query_var('paged')) {
  $paged = get_query_var('paged');
} elseif(get_query_var('page')) {
  $paged = get_query_var('page');
}

// interogăm articolele și înlocuim interogarea principală (pagina) cu aceasta (pentru ca paginarea să funcționeze)
query_posts(array('post_type' => 'my_post_type', 'post_status' => 'publish', 'paged' => $paged));

// paginare
next_posts_link();
previous_posts_link();

// buclă
while(have_posts()) {
  the_post();
  the_title(); // titlul articolului de tip custom-post-type
  the_content(); // conținutul articolului de tip custom-post-type
}

wp_reset_query(); // resetează interogarea principală (global $wp_query) la interogarea originală a paginii (o obține din variabila globală $wp_the_query) și resetează datele postului

// Acum putem afișa din nou conținutul asociat paginii (dacă dorim)
while(have_posts()) { // bucla principală originală - conținutul paginii
  the_post();
  the_title(); // titlul paginii
  the_content(); // conținutul paginii
  // etc...
}

Pentru a fi perfect clari, am putea evita utilizarea funcției query_posts() și aici și am putea folosi WP_Query în schimb - astfel:

// ...

global $wp_query;
$wp_query = new WP_Query(array('your query vars here')); // setează noua interogare personalizată ca interogare principală

// bucla pentru articolele de tip custom-post-type aici

wp_reset_query();

// ...

Dar, de ce am face asta când avem la dispoziție o funcție atât de utilă pentru acest scop?

Modific interogarea WordPress din functions.php:

//din păcate, condiția "IS_PAGE" nu funcționează în pre_get_posts (este o comportare specifică WORDPRESS)
//deci poți folosi `add_filter('posts_where', ....);`    SAU   modifică  interogarea "PAGE" direct în fișierul template

add_action( 'pre_get_posts', 'myFunction' );
function myFunction($query) {
    if ( ! is_admin() && $query->is_main_query() )  {
        if (  $query->is_category ) {
            $query->set( 'post_type', array( 'post', 'page', 'my_postType' ) );
            add_filter( 'posts_where' , 'MyFilterFunction_1' ) && $GLOBALS['call_ok']=1; 
        }
    }
}
function MyFilterFunction_1($where) {
   return (empty($GLOBALS['call_ok']) || !($GLOBALS['call_ok']=false)  ? $where :  $where . " AND ({$GLOBALS['wpdb']->posts}.post_name NOT LIKE 'Journal%')"; 
}

Doar pentru a sublinia câteva îmbunătățiri aduse răspunsului acceptat, deoarece WordPress a evoluat de-a lungul timpului și unele lucruri sunt diferite acum (după cinci ani):

pre_get_posts este un filtru, folosit pentru a modifica orice interogare. Cel mai des este folosit pentru a modifica doar 'interogarea principală':

De fapt, este un action hook. Nu un filtru și va afecta orice interogare.

Interogarea principală apare în șabloanele tale ca:

if( have_posts() ):
    while( have_posts() ): the_post();
       //Bucla
    endwhile;
endif;

De fapt, nici acest lucru nu este adevărat. Funcția have_posts iterează obiectul global $wp_query care nu este legat doar de interogarea principală. global $wp_query; poate fi modificat și cu interogările secundare.

function have_posts() {
    global $wp_query;
    return $wp_query->have_posts();
}

get_posts()

Aceasta este în esență un wrapper pentru o instanță separată a unui obiect WP_Query.

De fapt, în prezent WP_Query este o clasă, deci avem o instanță a unei clase.

Concluzie: La momentul în care @StephenHarris a scris, cel mai probabil toate acestea erau adevărate, dar de-a lungul timpului lucrurile în WordPress s-au schimbat.