WordPressin pre_get_posts-filtterin väärinkäyttö

pre_get_posts

WP_Query

Tämä filtteri on kuin ydinreaktorin säätösauva: pieni muutos oikeassa kohdassa on hyödyllinen, mutta satunnainen heiluttelu väärässä vaiheessa voi sammuttaa koko järjestelmän.

Miten pre_get_posts toimii

pre_get_posts

• ennen kuin WordPress suorittaa tietokantakyselyn

• kun

  Kopioi

  WP_Query

  -olio on rakennettu

• mutta ennen SQL:n generointia

Tyypillinen käyttö:

add_action('pre_get_posts', function($query) {
if (!is_admin() && $query->is_main_query()) {
$query->set('posts_per_page', 5);
}
});

Tämä muuttaa pääkyselyn postausmäärän.

Miksi filtteriä käytetään

Yleisiä käyttötarkoituksia:

• muuttaa etusivun postausmäärää

• rajata arkiston sisältöä

• lisätä meta_query tai taxonomy-suodatus

• piilottaa tiettyjä post typeja

Se on usein parempi ratkaisu kuin:

• suorat SQL-muutokset

• teemaan kovakoodatut queryt

Yleisin väärinkäyttö: ei tarkisteta queryn tyyppiä

Monet koodit näyttävät tältä:

add_action('pre_get_posts', function($query) {
$query->set('posts_per_page', 3);
});

Tämä vaikuttaa:

• etusivuun

• arkistoihin

• hakutuloksiin

• widget-kyselyihin

• REST API -kyselyihin

• adminin listoihin

Seuraukset:

• admin näyttää vain 3 postausta

• REST API palauttaa väärän datan

• widgetit rikkoutuvat

is_main_query()-tarkistuksen puuttuminen

WordPress käyttää useita queryjä:

• pääkysely (main query)

• widget-kyselyt

• shortcode-kyselyt

• REST-kyselyt

Jos

is_main_query()

• filtteri vaikuttaa kaikkiin kyselyihin

• syntyy vaikeasti havaittavia bugeja

Oikea tapa:

if ($query->is_main_query())

is_admin()-tarkistuksen unohtaminen

pre_get_posts

if (!is_admin())

muutokset vaikuttavat:

• postauslistaan

• käyttäjälistaan

• mediakirjastoon

Tämä on yksi yleisimmistä syistä outoihin admin-ongelmiin.

Suorituskykyongelmat meta_queryjen kanssa

pre_get_posts

• monimutkaisia meta_queryjä

• useita JOIN-operaatioita

• OR-logiikkaa

Esimerkki:

$query->set('meta_query', [
[
'key' => 'price',
'value' => 100,
'compare' => '>'
]
]);

Jos tämä ajetaan:

• jokaisessa kyselyssä

• suurissa meta-tauluissa

se voi:

• hidastaa koko sivustoa

• aiheuttaa slow query -tilanteita

REST API ja headless-ongelmat

Koska

pre_get_posts

• muuttaa REST API:n tuloksia

• rikkoa headless-frontendin

• aiheuttaa väärää dataa ulkoisiin integraatioihin

Esimerkiksi:

• mobiilisovellus saa väärän määrän posteja

• API-suodatus ei toimi

Sivunavigaation rikkoutuminen

Jos

posts_per_page

• sivunavigaatio voi mennä rikki

• pagination ei vastaa todellista postimäärää

Tämä tapahtuu usein, kun:

• querya muokataan ilman kontekstia

• arkistot ja hakutulokset sekoittuvat

Turvallinen käyttömalli

Hyvä perusrakenne:

add_action('pre_get_posts', function($query) {

if (is_admin()) {
return;
}

if (!$query->is_main_query()) {
return;
}

if ($query->is_home()) {
$query->set(’posts_per_page’, 5);
}

});

Tämä varmistaa, että:

• admin pysyy koskemattomana

• vain pääkysely muuttuu

• muutos kohdistuu oikeaan näkymään

Milloin pre_get_posts ei ole oikea työkalu

Filtteriä ei pitäisi käyttää:

• yksittäisen custom-queryn muokkaukseen

• shortcodejen sisäisiin kyselyihin

• REST-endpointin logiikkaan

Näissä tapauksissa:

• käytä suoraa

  Kopioi

  WP_Query

  -parametria

• tai REST-kontrollerin omaa logiikkaa

Yhteenveto

pre_get_posts

• Kopioi

  is_main_query()

  -tarkistuksen puuttuminen

• Kopioi

  is_admin()

  -tarkistuksen unohtaminen

• raskaat meta_queryt

• REST API:n tahaton muokkaus

Oikein käytettynä se on elegantti tapa muokata sisältölogiikkaa. Väärin käytettynä se on näkymätön vipu, joka siirtää koko WordPressin käyttäytymistä ilman, että kukaan muistaa, mistä muutos alun perin tuli. Ja silloin debuggaus muuttuu arkeologiseksi kaivaukseksi hookien kerrostumissa.