pre_get_postsWP_Query-olion parametreja ennen kuin tietokantakysely suoritetaan. Oikein käytettynä se on elegantti tapa muuttaa sivuston sisältölogiikkaa. Väärin käytettynä se voi rikkoa koko sivuston käyttäytymisen, suorituskyvyn ja jopa adminin.
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 laukeaa:
-
ennen kuin WordPress suorittaa tietokantakyselyn
-
kun
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()-tarkistus puuttuu:
-
filtteri vaikuttaa kaikkiin kyselyihin
-
syntyy vaikeasti havaittavia bugeja
Oikea tapa:
if ($query->is_main_query())
is_admin()-tarkistuksen unohtaminen
pre_get_posts toimii myös adminissa. Ilman tarkistusta:
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-filtterissä lisätään usein:
-
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 vaikuttaa kaikkiin queryihin, se voi:
-
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 muutetaan väärässä kohdassa:
-
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
WP_Query-parametria -
tai REST-kontrollerin omaa logiikkaa
Yhteenveto
pre_get_posts on tehokas mutta vaarallinen työkalu. Yleisimmät virheet ovat:
-
is_main_query()-tarkistuksen puuttuminen -
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.
