Zgodność wtyczek z WordPress 7.0: co sprawdzić przed aktualizacją

Zgodność wtyczek z WordPress 7.0 sprawdzasz przed aktualizacją produkcji. Robisz kopię strony, porównujesz deklaracje autorów i wersję PHP, a potem testujesz całość na kopii. Tyle. Wersja 7.0 trafiła do użytkowników w maju 2026 roku, a szczegóły wydania znajdziesz w majowych ogłoszeniach projektu WordPress. Piszę ten poradnik dla właściciela albo administratora strony firmowej czy sklepu WooCommerce, który nie może sobie pozwolić na przestój (czyli w sumie dla większości z was).

Dlaczego aktualizacja do WordPress 7.0 wymaga sprawdzenia wtyczek?

Bo to wydanie główne. Zmienia się rdzeń, edytor i interfejsy API, na których stoją wtyczki. Przy wydaniach poprawkowych, które głównie łatają błędy, ryzyko konfliktu jest dużo mniejsze. Tutaj nie. Jak wygląda niezgodność w praktyce? Biały ekran, błędy w panelu, koszyk, który nie przyjmuje zamówień, padnięte płatności albo rozjechany edytor. W sklepie każda taka awaria to utracone zamówienia. Dlatego nowej wersji nie instaluje się „w ciemno” i na pewno nie w godzinach szczytu.

Jak sprawdzić zgodność wtyczek z WordPress 7.0 przed aktualizacją?

Przechodzisz po kolei przez kilka źródeł informacji o każdym dodatku. Pytanie „czy moje wtyczki działają z WordPress 7.0” brzmi groźnie, ale da się je rozbić na proste kroki:

1. Spisz aktywne wtyczki i motyw, razem z ich obecnymi wersjami.
2. Sprawdź w katalogu wordpress.org pole „Tested up to”, czyli najnowszą wersję WordPressa, na której autor testował dodatek.
3. Przeczytaj changelog i komunikaty autorów o przygotowaniach do 7.0.
4. Zwróć uwagę na datę ostatniej aktualizacji wtyczki (to też kwestia bezpieczeństwa wtyczek).

Wtyczki premium to osobny temat. Licencja wtyczki premium musi być aktywna, a ty musisz mieć dostęp do najnowszego wydania, bo inaczej poprawka zgodności po prostu do ciebie nie dotrze. Dodatki porzucone, od dawna bez aktualizacji, od razu oznaczam do zamiany. A co, jeśli kluczowej wtyczki nikt już nie rozwija? Wtedy zostaje licencja z aktualizacjami i wsparciem albo wtyczka na zamówienie, jaką przygotowuje na przykład K4.pl.

WordPress 7.0 a PHP: sprawdź wersję na serwerze

Wersję PHP odczytasz w panelu WordPressa, w zakładce Narzędzia > Zdrowie witryny, albo w panelu hostingu. Minimalnych i zalecanych wersji dla WordPress 7.0 szukaj tylko na oficjalnej stronie wymagań wordpress.org. Nie w przypadkowych poradnikach. I teraz ważna rzecz, czyli kolejność: najpierw potwierdzasz, że wtyczki obsługują nowe PHP, potem zmieniasz PHP, a rdzeń aktualizujesz na samym końcu. Po co tak? Żeby nie zmieniać dwóch rzeczy naraz. Jak coś się wysypie, od razu wiesz, co było przyczyną. No i starsze dodatki częściej psują się przy zmianie PHP niż przy samej aktualizacji WordPressa.

Kopia zapasowa i środowisko testowe staging WordPress

Przed aktualizacją potrzebujesz pełnej kopii plików i bazy danych. I pewności, że da się ją odtworzyć. Kopia, której nikt nigdy nie próbował przywrócić, to tylko założenie, nie zabezpieczenie. Drugi element to staging, czyli kopia strony pod osobnym adresem, niewidoczna dla klientów i wyszukiwarek. Wiele hostingów daje go jednym kliknięciem w panelu, więc nie ma co kombinować. Na stagingu najpierw aktualizujesz wtyczki, a dopiero potem rdzeń do 7.0. Tryb debugowania WP_DEBUG i log błędów włączasz tylko tam. Nigdy na produkcji.

Test wtyczek po aktualizacji: co kliknąć w pierwszej kolejności

Zaczynasz od scenariuszy, które bezpośrednio dotykają sprzedaży i obsługi klientów:

• logowanie i praca w panelu administracyjnym,
• edycja i zapis wpisu w edytorze,
• formularze kontaktowe,
• wyszukiwarka na stronie,
• koszyk i pełne zamówienie testowe,
• metody płatności i dostawy,
• e-maile transakcyjne.

Po każdym scenariuszu zajrzyj do logu błędów i konsoli przeglądarki. Coś nie działa? Wyłączaj wtyczki po kolei, aż trafisz na winowajcę. Potem zgłoś błąd autorowi, z opisem kroków i fragmentem logu (autorzy naprawdę szybciej reagują, kiedy dostają konkret, a nie „u mnie nie działa”). Produkcję aktualizujesz dopiero wtedy, gdy wszystkie testy przejdą. W godzinach małego ruchu.

Co zrobić, gdy wtyczka nie jest gotowa na WordPress 7.0?

Masz trzy rozsądne wyjścia i jeden plan awaryjny. Pierwsze: wstrzymujesz aktualizację rdzenia do czasu poprawki, ale wydania bezpieczeństwa dla obecnej gałęzi dalej instalujesz. Drugie: zamieniasz dodatek na odpowiednik, który ktoś aktywnie rozwija. Trzecie: zlecasz poprawkę albo dedykowaną wtyczkę na zamówienie, jeśli bez tej funkcji biznes stoi. Cokolwiek wybierzesz, przygotuj plan wycofania. Jeśli po aktualizacji produkcji wyskoczy krytyczny błąd, przywracasz sprawdzoną wcześniej kopię i tyle.

Moim zdaniem zgodność wtyczek z WordPress 7.0 to kwestia procedury, a nie szczęścia. Kolejność jest zawsze ta sama: spis dodatków, kopia zapasowa, weryfikacja PHP, staging, testy i dopiero na końcu produkcja. Wpisz aktualizację w kalendarz na konkretny dzień, zamiast ją odkładać bez końca. Bo im dłużej strona siedzi na starej wersji, tym więcej zmian trzeba będzie potem sprawdzić naraz.

Najczęstsze pytania