{"id":13558,"date":"2026-10-15T18:25:00","date_gmt":"2026-10-15T16:25:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13558"},"modified":"2026-10-09T23:11:50","modified_gmt":"2026-10-09T21:11:50","slug":"autoload-w-wordpressie-wartosci-kolumny-autoload-i-zapytanie-ktore-nadal-je","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/wordpress-plugins-tricks-pl\/tutorials-pl-wordpress-plugins-tricks-pl\/autoload-w-wordpressie-wartosci-kolumny-autoload-i-zapytanie-ktore-nadal-je\/","title":{"rendered":"Autoload w WordPressie: warto\u015bci kolumny autoload i zapytanie, kt\u00f3re nadal je znajduje"},"content":{"rendered":"

Ka\u017cda strona tego bloga zaczyna si\u0119 od tego samego zapytania do bazy, wys\u0142anego zanim WordPress w og\u00f3le wie, o kt\u00f3r\u0105 stron\u0119 chodzi\u0142o: czyta zestaw ustawie\u0144, kt\u00f3rych spodziewa si\u0119 potrzebowa\u0107.<\/p>\n

O tym, kt\u00f3re ustawienia nale\u017c\u0105 do tego zestawu, rozstrzyga jedna kolumna o nazwie autoload<\/code>. Kolumna ta dosta\u0142a w ostatnich wersjach nowe warto\u015bci, a zapytanie polecane przez niemal ka\u017cdy starszy poradnik nie zwraca dzi\u015b nic.<\/p>\n

\n\"Dwie
Mo\u017cliwych jest siedem warto\u015bci. Cztery z nich znacz\u0105: opcja jest czytana przed ka\u017cd\u0105 stron\u0105.<\/figcaption><\/figure>\n

Co autoload naprawd\u0119 robi<\/h2>\n

WordPress trzyma swoje ustawienia w jednej tabeli. Ka\u017cdy wiersz niesie nazw\u0119, warto\u015b\u0107 i adnotacj\u0119, czy warto\u015b\u0107 ma przyj\u015b\u0107 automatycznie.<\/p>\n

Oznaczenie pozwala ograniczy\u0107 liczb\u0119 zapyta\u0144 do bazy danych. Zamiast pobiera\u0107 ka\u017cde ustawienie osobno, gdy jest potrzebne, WordPress \u0142aduje razem wszystkie warto\u015bci oznaczone do automatycznego \u0142adowania i przechowuje je w pami\u0119ci do ko\u0144ca \u017c\u0105dania.<\/p>\n

Ta zamiana ma swoj\u0105 cen\u0119. To, co nosi oznaczenie, podr\u00f3\u017cuje przy ka\u017cdym pojedynczym wywo\u0142aniu – na stronach, kt\u00f3re nigdy go nie dotykaj\u0105, przy plikach wydawanych przez PHP, przy ka\u017cdej wizycie ka\u017cdego crawlera.<\/p>\n

Trzy warto\u015bci w kolumnie, cztery licz\u0105 si\u0119 jako \u0142adowane<\/h2>\n

Dawniej kolumna by\u0142a prosta. Sta\u0142o w niej yes<\/code> albo no<\/code> i znaczenie obu by\u0142o jednoznaczne. Od wersji 6.6 mo\u017cliwo\u015bci jest wi\u0119cej.<\/p>\n

on<\/code> i off<\/code> to odpowiedzi wyra\u017ane: co\u015b za\u017c\u0105da\u0142o, \u017ceby warto\u015b\u0107 by\u0142a \u0142adowana, albo za\u017c\u0105da\u0142o, \u017ceby nie by\u0142a.<\/p>\n

auto-on<\/code> i auto-off<\/code> znacz\u0105: nikt nie pyta\u0142, a WordPress rozstrzygn\u0105\u0142.<\/p>\n

auto<\/code> znaczy: nikt nie pyta\u0142 i WordPress te\u017c nie rozstrzygn\u0105\u0142.<\/p>\n

Kt\u00f3re warto\u015bci licz\u0105 si\u0119 jako \u0142adowane, stoi w kodzie \u017ar\u00f3d\u0142owym jako funkcja wp_autoload_values_to_autoload()<\/code> i wymienia ona cztery: yes<\/code>, on<\/code>, auto-on<\/code> i auto<\/code>. Reszta zostaje na dysku, dop\u00f3ki co\u015b nie za\u017c\u0105da jej po nazwie.<\/p>\n

Dlaczego stare zapytanie nic nie znajduje<\/h2>\n

Linijka, kt\u00f3ra pojawia si\u0119 w poradniku za poradnikiem, brzmi SELECT option_name FROM wp_options WHERE autoload = 'yes'<\/code>.<\/p>\n

Zastosowana do tej strony zwraca zero wierszy przy 1290 opcjach – podczas gdy 155 z tych opcji jest faktycznie czytanych przed ka\u017cd\u0105 stron\u0105. Kolumna prowadzi tutaj wy\u0142\u0105cznie off<\/code>, on<\/code> i auto<\/code>. Warto\u015b\u0107 yes<\/code> nie wyst\u0119puje nigdzie.<\/p>\n

Nic o tym nie ostrzega. Nie ma b\u0142\u0119du ani komunikatu, a pusty wynik wygl\u0105da dok\u0142adnie tak samo jak czysta diagnoza. Sprawdzana w ten spos\u00f3b strona przez lata sprawia wra\u017cenie, jakby w og\u00f3le nie mia\u0142a \u0142adowanych opcji.<\/p>\n

Zapytanie, kt\u00f3re nadal dzia\u0142a, wymienia wszystkie cztery warto\u015bci: WHERE autoload IN ('yes','on','auto-on','auto')<\/code>.<\/p>\n

\n\"D\u0142uga
\n<\/figure>\n

Nierozstrzygni\u0119te znaczy \u0142adowane<\/h2>\n

Warto\u015b\u0107 auto<\/code> jest t\u0105 zaskakuj\u0105c\u0105. Zapisuje, \u017ce \u017cadna decyzja nie zapad\u0142a – a opcja w tym stanie i tak zostaje za\u0142adowana.<\/p>\n

Droga przez kod jest kr\u00f3tka. Wyra\u017ane true<\/code>, on<\/code> albo yes<\/code> staje si\u0119 on<\/code>. Wyra\u017ane false<\/code>, off<\/code> albo no<\/code> staje si\u0119 off<\/code>. Tam, gdzie nie podano nic wyra\u017anego, g\u0142os dostaje filtr: true staje si\u0119 auto-on<\/code>, false auto-off<\/code>, a brak odpowiedzi auto<\/code>.<\/p>\n

Poniewa\u017c auto<\/code> stoi na li\u015bcie \u0142adowanych, milczenie ma kierunek. Opcja za\u0142o\u017cona bez s\u0142owa o autoload jest od tej chwili czytana przed ka\u017cd\u0105 stron\u0105. Na tej stronie w dok\u0142adnie takim stanie znajduje si\u0119 55 opcji.<\/p>\n

Granica przy 150 000 bajt\u00f3w<\/h2>\n

Jeden filtr przychodzi razem z WordPressem i nie robi nic poza pilnowaniem rozmiaru. Je\u015bli warto\u015b\u0107 po serializacji przekracza 150 000 bajt\u00f3w, odpowied\u017a brzmi auto-off<\/code>, a opcja zostaje na miejscu.<\/p>\n

Dwa szczeg\u00f3\u0142y warto zapami\u0119ta\u0107. Granica sama jest filtrem, wp_max_autoloaded_option_size<\/code>, wi\u0119c wtyczka mo\u017ce j\u0105 przesun\u0105\u0107. I dzia\u0142a tylko tam, gdzie nie powiedziano nic wyra\u017anego – opcja ustawiona r\u0119cznie na on<\/code> zostaje za\u0142adowana bez wzgl\u0119du na rozmiar.<\/p>\n

W liczbach tej strony regu\u0142a jest dobrze widoczna. \u017badna \u0142adowana opcja nie przekracza tutaj 150 000 bajt\u00f3w, podczas gdy najwi\u0119ksza opcja ca\u0142ej tabeli – zapisany rozmiar katalogu o wielko\u015bci 102 403 bajt\u00f3w – stoi na off<\/code> i nigdy nie podr\u00f3\u017cuje.<\/p>\n

Ile naprawd\u0119 kosztuje 155 opcji<\/h2>\n

Zmierzone 2 wrze\u015bnia 2026: 155 z 1290 opcji jest czytanych przed ka\u017cd\u0105 stron\u0105, razem 122 435 bajt\u00f3w, nieca\u0142e 120 KB.<\/p>\n

Wa\u017cniejszy od sumy jest rozk\u0142ad. 145 ze 155 jest mniejszych ni\u017c kilobajt. Trzy nios\u0105 razem 88 946 bajt\u00f3w, czyli prawie trzy czwarte ca\u0142ego ci\u0119\u017caru.<\/p>\n

Zdecydowanie najwi\u0119ksza jest cron<\/code> z 49 606 bajtami: 40 procent wszystkiego, co \u0142adowane, w jednym wierszu. Mie\u015bci 338 zaplanowanych zdarze\u0144, a 321 z nich jest jednego rodzaju – po jednym publish_future_post<\/code> dla ka\u017cdego wpisu, kt\u00f3ry wci\u0105\u017c czeka na sw\u00f3j termin.<\/p>\n

To nie jest usterka i \u017cadna wtyczka nie ponosi za to winy. W\u0142a\u015bnie po to ta opcja istnieje. Znaczy to jednak, \u017ce blog z d\u0142ugim planem redakcyjnym czyta ca\u0142y sw\u00f3j plan, zanim w og\u00f3le wyda jak\u0105kolwiek stron\u0119 – i \u017ce ten ci\u0119\u017car ro\u015bnie wraz z kalendarzem, a nie z ruchem. Dobrze o tym wiedzie\u0107, zanim poszukiwania winnego zaczn\u0105 si\u0119 w zupe\u0142nie innym miejscu.<\/p>\n

\n

Pytania i odpowiedzi<\/h2>\n

Czy trwa\u0142a pami\u0119\u0107 podr\u0119czna obiekt\u00f3w zmienia koszt \u0142adowanych opcji?<\/h3>\n

Oszcz\u0119dza zapytanie do bazy, nie ci\u0119\u017car. Przy pami\u0119ci podr\u0119cznej obiekt\u00f3w, takiej jak Redis czy Memcached, WordPress odk\u0142ada tam ca\u0142y zestaw \u0142adowanych opcji i przy ka\u017cdym wywo\u0142aniu pobiera go z powrotem w jednym kawa\u0142ku, zamiast pyta\u0107 tabel\u0119. W pami\u0119ci PHP l\u0105duje potem to samo co bez pami\u0119ci podr\u0119cznej, na tej stronie nadal 122 435 bajt\u00f3w na wywo\u0142anie, a ca\u0142y zestaw zostaje wczytany, zanim powstanie pierwsza linijka strony.<\/p>\n

Na uwag\u0119 zas\u0142uguje jeden skutek uboczny: zestaw le\u017cy w pami\u0119ci podr\u0119cznej jako pojedynczy wpis. Gdy ro\u015bnie, ro\u015bnie razem z nim ten wpis, a Memcached w ustawieniu domy\u015blnym nie przyjmuje element\u00f3w wi\u0119kszych ni\u017c 1 MB. Przy nieca\u0142ych 120 KB ta strona jest daleko od tej granicy; blog, kt\u00f3rego opcja cron ro\u015bnie razem z planem redakcyjnym, powinien jednak mie\u0107 sum\u0119 na oku.<\/p>\n

Czy da si\u0119 zmniejszy\u0107 opcj\u0119 cron, nie nara\u017caj\u0105c zaplanowanych wpis\u00f3w?<\/h3>\n

Tylko w niewielkim stopniu. 321 zdarze\u0144 publish_future_post to nie pozosta\u0142o\u015bci, lecz polecenia opublikowania czekaj\u0105cych wpis\u00f3w w ich terminach. Bez takiego zdarzenia wpis pozostaje w statusie future, nawet gdy jego termin dawno min\u0105\u0142. Na jedno zdarzenie przypada \u015brednio nieca\u0142e 147 bajt\u00f3w (49 606 bajt\u00f3w na 338 zdarze\u0144), wi\u0119c ka\u017cdy kolejny zaplanowany wpis powi\u0119ksza opcj\u0119 mniej wi\u0119cej o tyle, a ka\u017cda publikacja zn\u00f3w to odejmuje.<\/p>\n

Porz\u0105dki maj\u0105 sens w\u015br\u00f3d pozosta\u0142ych 17 zdarze\u0144. Bywaj\u0105 w\u015br\u00f3d nich cykliczne zadania wtyczek usuni\u0119tych dawno temu, bo wtyczka musi sama wyrejestrowa\u0107 swoje zdarzenia przy usuwaniu, a nie ka\u017cda to robi. Nawet gdyby wszystkie 17 okaza\u0142y si\u0119 zb\u0119dne, przy przeci\u0119tnym rozmiarze da\u0142oby to zaledwie oko\u0142o 2,5 KB.<\/p>\n

Nic si\u0119 przy tym nie zmienia, gdy WP-Cron jest uruchamiany przez systemowe zadanie cron. Zmienia si\u0119 tylko to, kto wywo\u0142uje zdarzenia, na kt\u00f3re przysz\u0142a pora; lista nadal jest zapisana w tej samej opcji i \u0142adowana przed ka\u017cd\u0105 stron\u0105.<\/p>\n

Czy WordPress przestawia opcje dezaktywowanej wtyczki na off?<\/h3>\n

Nie. Dezaktywacja nie rusza tabeli, a opcje znikaj\u0105 dopiero wtedy, gdy wtyczka sama posprz\u0105ta po sobie przy odinstalowaniu, wi\u0119c opcja za\u0142o\u017cona bez podania warto\u015bci autoload jest czytana przed ka\u017cd\u0105 stron\u0105 tak\u017ce po usuni\u0119ciu wtyczki. W\u015br\u00f3d 55 opcji w stanie auto o tym, do kt\u00f3rej wtyczki nale\u017cy dany wiersz, zwykle m\u00f3wi\u0105 przedrostki nazw.<\/p>\n<\/div>\n

\n

\u0179r\u00f3d\u0142a<\/h2>\n