WP Multitool
Autoloader Optimizer

Jak działa Autoloader Optimizer

Autoloader Optimizer analizuje opcje autoload na stronie i poleca bezpieczne optymalizacje. Klasyfikuje każdą opcję, wskazuje kandydatów i daje mechanizm przywracania, gdy coś pójdzie nie tak.

1. Health Check — Skanuje każdą opcję autoload i wrzuca ją do jednej z sześciu kategorii
2. Wykrywanie wtyczek — Używa metadanych WordPress (TextDomain + nazwa folderu), żeby z dużą celnością dopasować opcje do wtyczek
3. Learning Mode — Opcjonalny okres obserwacji śledzi, które opcje są naprawdę czytane, zanim cokolwiek zmienisz
4. Optymalizacja — Robi kopię, potem wyłącza autoload na oflagowanych kandydatach. Żadnych danych się nie kasuje.

Krok 2: wykrywanie wtyczek — jak działają prefiksy

Najtrudniejsza część analizy opcji to poprawne ustalenie, która wtyczka stworzyła którą opcję. Moduł używa API get_plugins() WordPress, żeby wziąć wszystkie zainstalowane wtyczki z pełnymi metadanymi, w tym TextDomain.

Generowanie prefiksów

Dla każdej wtyczki generujemy kilka możliwych prefiksów:

1. Prefiks z folderu — Nazwa folderu wtyczki z podkreśleniami (np. advanced-caching staje się advanced_caching_)
2. Prefiks TextDomain — Zadeklarowany TextDomain wtyczki, jeśli różni się od nazwy folderu

To podwójne podejście ogarnia częste wzorce nazw WordPress, gdzie folder ma myślniki, a TextDomain podkreślenia, albo odwrotnie.

Przed v1.1.18: problem prefiksów

Po v1.1.18: wykrywanie po TextDomain

Obecna implementacja rozwiązuje to przez:

1. Odczyt pełnych metadanych wtyczki, w tym zadeklarowanego TextDomain z nagłówka
2. Użycie i nazwy folderu, i TextDomain do generowania prefiksów
3. Weryfikację statusu aktywności względem oficjalnej listy active_plugins WordPress
4. Klasyfikację jako „nieaktywna wtyczka” tylko wtedy, gdy jesteśmy pewni, że wtyczka naprawdę nie działa

To mocno obcina fałszywe trafienia. Teraz poprawnie widzimy, że Yoast SEO (folder: wordpress-seo, TextDomain: wordpress-seo) pasuje do wariantów wordpress_seo_, wordpress-seo_ i wpseo_ przez nagłówki wtyczki. Efekt: prawie nigdy przypadkiem nie oflagujemy opcji aktywnej wtyczki jako osieroconych.

Krok 4: optymalizacja

Jak przejrzysz analizę i wskażesz kandydatów, moduł aplikuje optymalizację:

1. Tworzenie kopii — Pełna kopia tabeli opcji jest tworzona i zapisywana jako opcja w bazie
2. Aktualizacja flagi autoload — Dla każdego wybranego kandydata kolumna autoload idzie z 'yes' na 'no'
3. Weryfikacja — Moduł pokazuje podsumowanie zmian
4. Monitoring — Po optymalizacji sprawdzasz, czy strona nadal działa poprawnie

Zabezpieczenia

Autoloader Optimizer ma kilka warstw bezpieczeństwa:

Lista bezpiecznych opcji

Curated lista opcji rdzenia WordPress, które nigdy nie są flagowane do optymalizacji. Chroni kluczową funkcjonalność WordPress niezależnie od rozmiaru i pochodzenia.

Dopasowanie wtyczek po prefiksie

Używa oficjalnych metadanych wtyczek WordPress (TextDomain, nazwa folderu), żeby ustalić, która wtyczka trzyma którą opcję. Zestawiane z oficjalną listą active_plugins, żeby uniknąć fałszywych trafień.

Konserwatywna kategoryzacja

Jeśli jest jakakolwiek wątpliwość co do pochodzenia albo bezpieczeństwa opcji, ląduje w kategorii „Nierozpoznane” zamiast iść do automatycznej optymalizacji.

Kopia przed optymalizacją

Pełny snapshot wszystkich opcji autoload jest tworzony i zapisywany w bazie, zanim cokolwiek się zmieni.

Przywracanie jednym kliknięciem

Jeśli coś pójdzie nie tak, przywracasz kopię jednym kliknięciem. Wszystkie ustawienia autoload wracają do poprzedniego stanu.

Hook filtra dla deweloperów

Deweloperzy mogą zarejestrować własne opcje, których nigdy nie wolno wyłączać z autoload. Filtr wpmultitool_autoload_candidates zmienia listę kandydatów przed optymalizacją:

add_filter('wpmultitool_autoload_candidates', function($analysis) {
    // Protect specific options from being optimized
    $analysis['candidates'] = array_diff($analysis['candidates'], [
        'my_critical_option',
        'another_important_one',
    ]);
    return $analysis;
});

Nawet jeśli opcja pasuje do wzorca rozdęcia albo pochodzi z nieaktywnej wtyczki, filtr pozwala ją wyłączyć z optymalizacji.

Zachowanie danych

Opcje nigdy nie są kasowane. Zmienia się tylko flaga autoload. Dane zostają w pełni dostępne dla wtyczek i kodu, który o nie prosi.

Monitoring i diagnostyka

Po optymalizacji: co obserwować

1. Czasy ładowania strony — Zmierz przed/po w Google PageSpeed albo WebPageTest
2. Zapytania do bazy — Sprawdź log wolnych zapytań pod kątem nowych
3. Funkcjonalność — Przetestuj krytyczne ścieżki (checkout, formularze, operacje w adminie)
4. Logi błędów — Pilnuj wp-content/debug.log pod kątem nowych ostrzeżeń albo błędów

Jeśli coś padnie

1. Idź do WP Multitool → Autoloader Optimizer → Status
2. Kliknij „Restore Backup”
3. Wszystkie flagi autoload wracają do poprzedniego stanu
4. Sprawdź, która optymalizacja zrobiła problem
5. Użyj hooka filtra dla deweloperów, żeby ochronić tę konkretną opcję
6. Wdróż optymalizacje ponownie bez problematycznej opcji

Pomiar rozmiaru autoloadu

-- Before optimization (check current autoloaded size)
SELECT SUM(CHAR_LENGTH(option_value)) AS autoload_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

-- After optimization (verify the reduction)
SELECT SUM(CHAR_LENGTH(option_value)) AS autoload_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

FAQ

Czym są autoloadowane dane w WordPress?

Autoloadowane dane to każdy wiersz w tabeli wp_options oflagowany do automatycznego ładowania — 'yes' na starszych instalacjach, a od WordPress 6.6 także 'on', 'auto' albo 'auto-on'. WordPress ładuje to wszystko do pamięci przy każdym żądaniu — frontend, admin, REST, cron — niezależnie, czy bieżąca strona tego używa. Zdrowa suma to ok. poniżej 800KB–1MB; wtyczki, które nie sprzątają po sobie, to zwykle powód, że to przekracza. To nie jest autoloader klas PHP (Composer / SPL).

Czy bezpiecznie ustawić autoload na 'no'?

Dla właściwych opcji tak — i to dużo bezpieczniejsze niż kasowanie. Ustawienie autoload na 'no' zostawia dane w bazie; WordPress ładuje je na żądanie zamiast przy każdym requeście, a zmianę da się w pełni cofnąć. Ryzyko to przełączenie opcji, które aktywna wtyczka czyta wcześnie (konfiguracja firewalla, rewrite_rules, cron), więc audytuj przynależność każdej, zanim ruszysz — osierocone opcje po usuniętych wtyczkach to bezpieczne wygrane.

Co znaczy ostrzeżenie WP Engine o autoloaded data?

User Portal WP Engine flaguje stronę, gdy łączny rozmiar opcji autoload w wp_options urośnie — polecają trzymać to z grubsza poniżej 1MB, bo wszystko powyżej ładuje się przy każdym żądaniu. Ostrzeżenie jest tylko diagnostyczne: WP Engine podaje liczbę, a audyt i naprawa sprawców są twoje. Ten sam koszt jest na każdym hostingu — WP Engine jest po prostu jednym z nielicznych, które pokazują to w panelu.

Czy to zepsuje stronę?

Nie. Autoloader Optimizer zmienia tylko flagę autoload, nigdy nie kasuje danych. Gdy wtyczka albo rdzeń WordPress poprosi o opcję, która już nie jest w autoload, WordPress i tak wczyta ją z bazy — po prostu nie przy każdym żądaniu. Dodatkowo przed optymalizacją powstaje pełna kopia i przywrócisz ją jednym kliknięciem, jeśli wydarzy się coś niespodziewanego.

Dlaczego nierozpoznane opcje nie są optymalizowane automatycznie?

Bo nie umiemy zweryfikować źródła. To mogą być opcje aktywnego motywu (nietypowe prefiksy), must-use w /wp-content/mu-plugins/, własne opcje z twojego kodu albo wtyczki z nietypowymi nazwami. Automatyczna optymalizacja nierozpoznanych ryzykowałaby zepsucie czegoś, czego nie rozumiemy do końca. Zamiast tego pokazujemy je do przeglądu.

A wtyczki z nietypowymi prefiksami?

Od v1.1.18 bierzemy TextDomain z nagłówka wtyczki do dodatkowych prefiksów, co łapie większość nietypowych nazw. Część wtyczek ma jednak prefiksy bez związku z nazwą (np. własne skróty w starym kodzie). Wtedy chronisz je hookiem filtra dla deweloperów albo ręcznie oglądasz opcję i decydujesz sam.

Dlaczego wtyczka i tak tworzy opcje dla funkcji, których nie używam?

Większość wtyczek WordPress tworzy wszystkie klucze opcji przy instalacji, niezależnie od włączonych funkcji. To prostsze niż dynamiczne sprawdzanie aktywacji. Autoloader Optimizer to łagodzi, nie ładując w autoload opcji z wyłączonych wtyczek albo funkcji, których teraz nie używasz.

Ile realnie da się zaoszczędzić?

Zależy od ekosystemu wtyczek. Typowa strona z 8–12 wtyczkami może liczyć na 100–300KB mniej na żądanie. Strona WooCommerce z 15–20 wtyczkami bywa 500KB–2MB. Mocno rozdęta z 30+ wtyczkami i latami historii: 2–5MB+ na żądanie.

Co, jeśli wtyczkę włączę z powrotem, a autoload jej opcji już wyłączyłem?

Opcje nadal działają normalnie. WordPress wczyta je na żądanie, gdy wtyczka poprosi. Jeśli chcesz je z powrotem w autoload, Restore Backup cofa wszystkie zmiany, albo ręcznie włączysz autoload dla konkretnych opcji w bazie.

Czy to rusza transjenty albo zdarzenia cron?

Transjenty i harmonogramy cron w wp_options są kandydatami do optymalizacji, ale zwykle czyta się je tylko gdy trzeba. Moduł flaguje duże do przeglądu. Możesz je chronić hookiem filtra dla deweloperów, jeśli wolisz, żeby zostały nietknięte.