Od WordPress 3.7 platforma automatycznie aktualizuje części siebie bez klikania czegokolwiek. Większość właścicieli witryn jest świadoma tego mgliście, ale niewielu ma jasny obraz tego, co dokładnie jest aktualizowane, kiedy i jak zmienić domyślne ustawienie. Ten przewodnik przechodzi przez cztery poziomy automatycznych aktualizacji, które core WordPress wspiera, co każdy poziom faktycznie robi i który jest właściwym wyborem w zależności od tego, czy zarządzasz pojedynczą witryną, portfolio agencji czy konfiguracją managed hostingu.
Co WordPress domyślnie aktualizuje automatycznie
Domyślnie każda instalacja WordPress w 2026 robi następujące bez pytania:
- Drobne aktualizacje core. Przejście z 6.5.1 do 6.5.2 dzieje się automatycznie, w tle, tego samego dnia, kiedy wydanie jest opublikowane. Te wydania to poprawki błędów i łatki bezpieczeństwa. Są wyraźnie zaprojektowane tak, aby były bezpieczne do zainstalowania bez testowania.
- Aktualizacje plików tłumaczeń. Pakiety językowe są automatycznie odświeżane.
- Wydania bezpieczeństwa core dla starszych gałęzi. Nawet jeśli Twoja witryna jest jeszcze na 6.4, ponieważ nie wykonałeś dużej aktualizacji, poprawki bezpieczeństwa są back-portowane i stosowane automatycznie.
Co nie dzieje się automatycznie domyślnie:
- Duże aktualizacje core. Przejście z 6.5 do 6.6 wymaga ręcznego kliknięcia. WordPress pokazuje baner w adminie, ale nie instaluje go z własnej inicjatywy.
- Aktualizacje wtyczek i motywów. Oba mogą być włączane per element przez UI admina (od WordPress 5.5), ale żadne nie jest włączone domyślnie. Są osobnym tematem i nie są kontrolowane przez
WP_AUTO_UPDATE_CORE.
Powodem tego podziału jest dobra inżynieria: drobne wydania są publikowane pod ścisłą polityką "bez breaking changes", więc po cichu aktualizujące jest naprawdę niskim ryzykiem. Duże wydania okazjonalnie wprowadzają nowe API lub zmieniają zachowanie, na którym motywy i wtyczki mogą polegać, a ciche podnoszenie głównej wersji na produkcji historycznie spowodowało wystarczająco dużo psucia, że projekt wybrał konserwatywne domyślne.
Cztery poziomy automatycznych aktualizacji core
Stała WP_AUTO_UPDATE_CORE w wp-config.php kontroluje to wszystko. Akceptuje cztery wartości:
true: Wszystkie aktualizacje core są instalowane automatycznie, zarówno drobne, jak i duże. Agresywna opcja.'minor': Domyślna, jeśli stała w ogóle nie jest zdefiniowana. Tylko drobne i wydania bezpieczeństwa są instalowane automatycznie. Duże wydania pozostają ręczne.'beta'i'rc': Używane przez witryny, które chcą buildów pre-release. Realistyczne tylko w środowisku staging lub testowym, nigdy na produkcji.false: Wszystkie automatyczne aktualizacje core są wyłączone. Witryna nic nie robi z własnej inicjatywy. Jesteś odpowiedzialny za każdą łatkę, w tym poprawki bezpieczeństwa.
Ustawienie jednego z nich to pojedyncza linia w wp-config.php, gdzieś nad komentarzem /* That's all, stop editing! Happy publishing. */:
define('WP_AUTO_UPDATE_CORE', true);lub
define('WP_AUTO_UPDATE_CORE', 'minor');Zapisz plik, nie potrzeba restartu. WordPress sprawdza aktualizacje według harmonogramu (domyślnie dwa razy dziennie) i stosuje to, na co obecne ustawienie pozwala.
Które ustawienie ma sens dla jakiego rodzaju witryny?
Szczera odpowiedź zależy od trzech rzeczy: ile testowania dzieje się przed wejściem wydania na żywo, kto zauważa, gdy coś się psuje, i jak dobra jest strategia kopii zapasowych.
Standardowa witryna produkcyjna, brak dedykowanego kontraktu utrzymaniowego
Zalecane ustawienie: true (wszystkie aktualizacje automatyczne).
Intuicja, że "automatyczne duże aktualizacje są niebezpieczne" jest w dużej mierze przestarzała. Duże aktualizacje WordPress są stabilne od lat, a realistyczną alternatywą jest "nikt nie aktualizuje witryny przez sześć miesięcy, ponieważ nie ma na to kontraktu, a znana luka bezpieczeństwa pozostaje otwarta". Nieutrzymywana witryna WordPress to gorszy wynik niż bardzo rzadka automatyczna aktualizacja, która coś psuje. Jeśli duże wydanie zepsuje witrynę, przywrócenie z kopii zapasowej jest szybsze niż czas, który w przeciwnym razie spędziłbyś goniąc ręczną aktualizację później. Automatyzacja to wygrana.
Managed hosting (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)
Zalecane ustawienie: cokolwiek robi panel hosta, zwykle 'minor' na poziomie WordPress.
Większość managed hostów uruchamia własny przepływ aktualizacji na szczycie WordPress. Najpierw robią snapshot, instalują duże wydanie na klonie staging, wykonują podstawową wizualną różnicę i dopiero wtedy stosują to do produkcji. To jest znacznie bezpieczniejsze niż waniliowe auto-aktualizacje. Jeśli jesteś na tym typie hosta, ustawianie WP_AUTO_UPDATE_CORE na coś innego niż domyślne zwykle walczy z własną logiką hosta. Zostaw to w spokoju, pozwól hostowi wykonać swoją pracę i sprawdzaj panel hosta dla historii aktualizacji.
Portfolio agencji z kontraktem utrzymaniowym
Zalecane ustawienie: 'minor' na produkcji, true na staging.
Jeśli kontrakt utrzymaniowy określa, że testujesz aktualizacje przed wejściem na żywo, agencja jest siatką bezpieczeństwa. Produkcja powinna nadal automatycznie otrzymywać drobne i wydania bezpieczeństwa (nie są one opcjonalne z perspektywy bezpieczeństwa), ale duże aktualizacje przechodzą przez przepływ testowy agencji. Środowiska staging są właściwym miejscem do ustawienia bardziej agresywnej wartości, aby testerzy wcześnie wychwytywali psucie.
Niestandardowa kompilacja WordPress z ciężkimi dostosowaniami motywu lub wtyczek
Zalecane ustawienie: 'minor', plus prawdziwy proces testowania dla dużych aktualizacji.
Witryny, które są mocno dostosowane (przebudowany nagłówek, niestandardowe bloki Gutenberga, dziwne integracje pagebuilderów, niestandardowe endpointy REST), są dokładnie przypadkiem, w którym duża aktualizacja może coś subtelnie zepsuć. Domyślne ustawienie 'minor' jest właściwą dolną granicą: nie rezygnuj z łatek bezpieczeństwa, ale traktuj duże wydania jako osobne zadanie z prawdziwą rundą testów.
Witryna o wysokiej dostępności, która absolutnie nie może się zepsuć
Zalecane ustawienie: false dla core, plus prawdziwy proces wydawniczy.
To jedyny przypadek, w którym całkowite wyłączenie automatycznych aktualizacji core ma sens. Bankowość, opieka zdrowotna, środowiska regulowane, w których każda zmiana przechodzi przez proces wydawniczy. Zauważ, że akceptujesz pełną odpowiedzialność za ręczne stosowanie łatek bezpieczeństwa w ciągu godzin po wydaniu, na każdej witrynie. Większość zespołów wybierających to ustawienie ma również monitoring listy mailingowej bezpieczeństwa WordPress i pipeline deploya, który może wysyłać łatki tego samego dnia.
Jak zweryfikować, że Twoje ustawienie jest aktywne
- W adminie WordPress przejdź do Narzędzia, Stan witryny, Info.
- Rozwiń sekcję Stałe WordPress.
- Wyszukaj
WP_AUTO_UPDATE_CORE. Jeśli pokazuje Twoją wartość, stała jest odczytywana. - Dla głębszej kontroli spójrz na Aktualizacje w pasku bocznym admina. Niedawne automatyczne aktualizacje pojawiają się tam ze znacznikami czasu.
Jeśli wartość stałej nie pojawia się w Stanie witryny, najbardziej prawdopodobną przyczyną jest, że została ustawiona później, po tym jak plik już ją wcześniej zdefiniował (pierwsza define wygrywa, a PHP generuje powiadomienie, którego możesz nie widzieć), lub że edytowałeś niewłaściwy wp-config.php.
Co może pójść nie tak z automatycznymi aktualizacjami core
Trzy tryby awarii są realistyczne i warto je znać:
- Aktualizacja zawodzi częściowo. Pobieranie lub rozpakowywanie łamie się w połowie, często ponieważ host nie ma wystarczająco miejsca na dysku, osiągnął limit inode lub z powodu tymczasowego problemu sieciowego. WordPress zostawia plik
.maintenancew katalogu głównym, a witryna pokazuje na zawsze "Tymczasowo niedostępne z powodu zaplanowanej konserwacji". Naprawa: SFTP do katalogu głównego i usuń plik.maintenance, następnie uruchom aktualizację ponownie z admina. - Aktualizacja się powodzi, ale wtyczka zaczyna generować błędy. Szczególnie po dużej aktualizacji utrzymywana wtyczka może się zepsuć przeciwko nowym API core. Naprawa: miej kopię zapasową, zidentyfikuj zepsutą wtyczkę z logu błędów (lub przez dezaktywację wtyczek pojedynczo) i zaktualizuj wtyczkę lub zastąp ją.
- Aktualizacja jest po cichu pomijana. Częste powody:
DISALLOW_FILE_MODSjest ustawiony wwp-config.php(co blokuje wszystkie aktualizacje, automatyczne lub nie), uprawnienia plików na folderze WordPress uniemożliwiają PHP zapisywanie, lub witryna używa Git dla kontroli wersji i WordPress wykrywa folder.giti wyłącza aktualizacje jako środek bezpieczeństwa. Strona Stan witryny zwykle oznacza te przypadki.
Auto-aktualizacje i DISALLOW_FILE_MODS
Dwie stałe wchodzą w interakcję w sposób, który zaskakuje ludzi. DISALLOW_FILE_MODS (omawiany w naszej bazie wiedzy pod tematem edytora plików) blokuje wszystkie modyfikacje plików ze strony WordPress, w tym automatyczne aktualizacje core. Jeśli obie stałe są ustawione:
define('DISALLOW_FILE_MODS', true);
define('WP_AUTO_UPDATE_CORE', true);Wynikiem jest, że DISALLOW_FILE_MODS wygrywa. WordPress niczego nie zaktualizuje automatycznie. To rzadko jest tym, co ludzie mają na myśli. Albo chcesz zablokowanej witryny, która jest aktualizowana z zewnątrz (pipeline deploya, WP CLI), w którym to przypadku DISALLOW_FILE_MODS = true jest prawidłowe, a WP_AUTO_UPDATE_CORE nieistotne. Albo chcesz, aby witryna aktualizowała się sama, w którym to przypadku DISALLOW_FILE_MODS nie powinien być ustawiony.
Co z automatycznymi aktualizacjami wtyczek i motywów?
Automatyczne aktualizacje wtyczek i motywów to osobny mechanizm, który wylądował w WordPress 5.5. Są konfigurowane per element w adminie (lista Wtyczki, link "Włącz auto-aktualizacje" w każdym wierszu) lub globalnie przez filtry. Ogólne zalecenie: włącz auto-aktualizacje dla każdej wtyczki, której ufasz dyscyplinie wydawniczej opiekuna, zostaw wyłączone dla wtyczek, które regularnie wydają breaking changes. Szczególnie duże wydania WooCommerce są często warte wstrzymania dla ręcznej aktualizacji z szybkim testem.
Jeśli chcesz programowo włączyć automatyczne aktualizacje wtyczek dla każdej wtyczki, ten filtr to robi:
add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');Umieść to w małej wtyczce must-use pod wp-content/mu-plugins/ zamiast w functions.php, aby zmiana motywu tego nie wyłączyła.
Podsumowanie dla aktualizacji core: dla większości witryn w 2026 domyślne ustawienie 'minor' jest konserwatywne w niewłaściwym kierunku. Ustaw WP_AUTO_UPDATE_CORE na true i pozwól platformie utrzymywać się na bieżąco, lub zobowiąż się do prawdziwego procesu utrzymania, który ręcznie obsługuje duże wydania w rozsądnym czasie. Środek "domyślne ustawienia plus nikt nie patrzy" jest tym, co produkuje niezabezpieczone witryny WordPress, które są dwie wersje za, i to jest faktyczny stan wysokiego ryzyka.