WordPress 7.2: jak przygotować stronę do aktualizacji (i co psuje edytor w iframe od 7.1)

Autor: Grzegorz Wojterzak. Aktualizacja: 16 listopada 2026. Czas czytania: około 11 minut.

Duże wersje WordPressa wychodzą dziś trzy razy w roku. W 2026 roku były to 7.0 w maju i 7.1 w sierpniu, a 7.2 ma się ukazać w grudniu. Dla właściciela strony to dobra wiadomość, bo poprawki przychodzą szybciej. Zła jest taka, że każda duża wersja to okazja, żeby przestała działać jakaś wtyczka, a w sklepie: kasa albo formularz zamówienia.

Ten poradnik nie jest listą nowych funkcji. Opisuję tylko te zmiany, które mogą coś zepsuć albo wymagają Twojej decyzji, i pokazuję, jak przejść przez aktualizację spokojnie. Stan na połowę listopada 2026: wersja 7.2 jest w fazie testów (beta, tuż przed RC1), więc listę zmian uzupełnię po premierze.

Co zmieniło się od 7.0 do 7.2 i co to znaczy dla Ciebie

Jeśli Twoja strona jest nadal na 6.9 albo na 7.0, przy przejściu na 7.2 dostaniesz wszystkie zmiany naraz. Dlatego zestawiam trzy wersje razem.

Wymagania serwera się nie zmieniły: WordPress zaleca PHP 8.3 lub nowsze oraz MySQL 8.0+ albo MariaDB 10.11+. Jeśli Twój hosting ma PHP 8.2, pamiętaj, że jego wsparcie kończy się 31 grudnia 2026. Opisuję to osobno w artykule Koniec PHP 8.2: jak przejść na 8.3.

Aktualny harmonogram i, po premierze, zbiorczy opis zmian dla twórców wtyczek znajdziesz na stronie wydania WordPress 7.2 na make.wordpress.org.

Edytor w iframe: co to jest i co może się zepsuć

Iframe to ramka, czyli osobna strona osadzona wewnątrz innej strony. Od wersji 7.1 obszar, w którym piszesz treść wpisu, jest właśnie taką ramką. Dzięki temu edytor pokazuje wpis bardzo podobnie do tego, jak wygląda na stronie, a style panelu nie mieszają się ze stylami motywu.

Najważniejsze dla Ciebie: ta zmiana dotyczy edytora w panelu, a nie strony, którą widzą klienci. Jeśli coś się zepsuje, to raczej Twoja wygoda pracy niż sprzedaż. Ale jeśli nie możesz poprawić ceny w opisie promocji albo wstawić galerii, to też jest awaria.

Typowe objawy

• blok wygląda w edytorze inaczej niż na stronie, bo jego style nie trafiają do ramki,
• rozwijane menu bloku nie zamyka się po kliknięciu obok,
• slider, mapa albo galeria w edytorze pokazuje pusty prostokąt,
• przyciski wtyczki (np. „wstaw produkt”, „wstaw formularz”) nie reagują,
• dodatkowe pola pod treścią wpisu (meta boxy, czyli okienka wtyczek SEO, pól własnych czy kreatorów) zachowują się dziwnie lub nie zapisują zmian.

Według notatki zespołu WordPressa większość bloków działa w ramce bez żadnych zmian. Problemy dotyczą głównie kodu, który zakłada, że edytor i panel to jedna i ta sama strona. W wersji 6.9 rejestracja bloku w starej wersji API dawała już ostrzeżenie w konsoli przeglądarki (przy włączonym trybie SCRIPT_DEBUG). Jeśli twórca wtyczki od tamtej pory jej nie poprawił, to dobry znak ostrzegawczy.

Jak to sprawdzić bez programowania

1. Otwórz na kopii strony (o kopii niżej) kilka typowych wpisów i stron: zwykły wpis, stronę zbudowaną kreatorem, kartę produktu, stronę z formularzem.
2. W każdym kliknij kilka bloków, zmień tekst, wstaw obrazek i zapisz. Sprawdź podgląd i stronę po zapisaniu.
3. Przejrzyj listę zmian swoich najważniejszych wtyczek (zakładka View details na liście wtyczek lub strona wtyczki). Szukaj wzmianek o zgodności z WordPress 7.1 lub o edytorze w iframe.

Jeśli masz dostęp do terminala na kopii, dodaj do wp-config.php linię define('SCRIPT_DEBUG', true);, otwórz edytor i zajrzyj do konsoli przeglądarki (F12, zakładka Console). Ostrzeżenia o przestarzałej wersji API bloków wskażą, które wtyczki trzeba sprawdzić w pierwszej kolejności. Po teście usuń tę linię.

Sprawdź, na jakiej wersji jesteś i jak aktualizuje się strona

Otwórz Kokpit → Aktualizacje (w wersji angielskiej panelu: Dashboard → Updates). Zobaczysz numer obecnej wersji i, co ważniejsze, informację, czy strona sama zainstaluje następną dużą wersję.

Drugie miejsce to raport Narzędzia → Stan witryny → Informacja, sekcja WordPress (w wersji angielskiej: Tools → Site Health → Info). Jest tu wersja, adres strony i informacja, czy działa przez HTTPS. Te dane przydadzą się, jeśli będziesz zgłaszać problem hostingowi albo mnie.

Przez WP-CLI, czyli narzędzie do zarządzania WordPressem z terminala, te same informacje dostaniesz dwoma poleceniami. Pierwsze pokazuje wersję rdzenia, drugie listę wtyczek z wersjami i dostępnymi aktualizacjami:

wp core version
wp plugin list --fields=name,status,version,update

Jak wstrzymać automatyczną aktualizację do czasu testów

Nie wyłączaj aktualizacji całkowicie. Poprawki bezpieczeństwa (np. 7.1.4) chcesz dostawać od razu. Wstrzymujesz tylko dużą wersję, czyli 7.2, do czasu, aż sprawdzisz ją na kopii.

1. Najprościej: w panelu

   Na ekranie aktualizacji kliknij link pod informacją o automatycznych aktualizacjach (Przełącz automatyczne aktualizacje tylko dla wersji utrzymaniowych i poprawiających bezpieczeństwo, widoczny na zrzucie wyżej; w wersji angielskiej Switch to automatic updates for maintenance and security releases only). Komunikat nad linkiem zmieni się na informację, że strona aktualizuje się tylko w ramach wydań poprawkowych i bezpieczeństwa. Jeśli zamiast linku widzisz tylko sam komunikat, ustawienie jest narzucone stałą w wp-config.php albo przez hosting.

2. Pewniej: stała w wp-config.php

   Plik wp-config.php leży w głównym katalogu strony. Otworzysz go menedżerem plików w panelu hostingu albo przez FTP. Dopisz nad linią z komentarzem „That's all, stop editing”:

   define( 'WP_AUTO_UPDATE_CORE', 'minor' );

   Wartość 'minor' oznacza tylko aktualizacje drobne i bezpieczeństwa. Według dokumentacji WordPressa true włącza wszystkie aktualizacje, łącznie z dużymi, a false wyłącza wszystkie. Gdy stała jest ustawiona, ma pierwszeństwo przed ustawieniem z panelu i link do przełączania znika.

3. Sprawdź hosting i wtyczki

   Część hostingów i instalatorów aplikacji w panelu ma własne automatyczne aktualizacje WordPressa, niezależne od ustawień w samym WordPressie. Sprawdź w panelu hostingu ustawienia instalatora, z którego zakładałeś stronę. To samo dotyczy wtyczek do zarządzania wieloma stronami i wtyczek „bezpieczeństwa”, które potrafią aktualizować rdzeń.

Wtyczki mają osobne automatyczne aktualizacje, włączane na liście wtyczek w kolumnie Automatyczne aktualizacje. Od wersji 6.6 WordPress cofa automatyczną aktualizację wtyczki, jeśli wywołała błąd krytyczny. Dotyczy to jednak tylko aktualizacji automatycznych, nie ręcznych, i nie wyłapie błędów, które nie wywalają strony, np. zepsutej kasy.

Test na kopii i kolejność aktualizacji

Kopia testowa (staging) to osobna kopia Twojej strony pod innym adresem, na której możesz psuć bez skutków dla klientów. Wiele hostingów tworzy ją jednym kliknięciem w panelu. Jeśli Twój nie ma takiej funkcji, kopię można zrobić wtyczką do kopii zapasowych albo ręcznie: skopiować pliki i bazę na subdomenę.

1. Zrób kopię zapasową całej strony

   Pliki i bazę danych, zapisane poza serwerem. Kopia z panelu hostingu wystarczy, jeśli wiesz, jak ją przywrócić. Przez WP-CLI bazę wyeksportujesz poleceniem, które zapisuje ją do jednego pliku SQL:

   wp db export przed-7-2-$(date +%F).sql

2. Utwórz kopię testową i wyłącz na niej maile

   Na kopii sklepu wyłącz wysyłkę maili do klientów i przełącz bramkę płatności w tryb testowy. Inaczej testowe zamówienie może trafić do prawdziwego klienta albo obciążyć kartę.

3. Sprawdź wersję PHP na kopii

   Jeśli masz PHP 8.2 lub starsze, najpierw zmień PHP na kopii i sprawdź, czy strona działa, a dopiero potem aktualizuj WordPressa. Dwie zmiany naraz utrudniają ustalenie, co zepsuło stronę.

4. Zaktualizuj wtyczki, potem motyw

   Najpierw wtyczki, po jednej lub w małych grupach, zaczynając od najważniejszych (WooCommerce, bramka płatności, kreator stron). Po każdej grupie zajrzyj na stronę. Potem motyw. Twórcy wtyczek wydają poprawki zgodności przed premierą, więc nowe wersje wtyczek zwykle lepiej znoszą nowy rdzeń.

5. Zaktualizuj rdzeń na kopii

   Po premierze kliknij aktualizację w panelu kopii albo użyj WP-CLI. Wersję kandydującą (RC) przed premierą zainstalujesz na kopii oficjalną wtyczką WordPress Beta Tester z katalogu wordpress.org. Nigdy nie instaluj wersji testowych na prawdziwej stronie.

   wp core update
   wp core update-db

   Drugie polecenie aktualizuje strukturę bazy danych, o co panel prosi zwykle sam po zalogowaniu.

6. Przejdź listę kontrolną (niżej) i dopiero wtedy aktualizuj stronę

   Na prawdziwej stronie powtórz kroki 1, 4 i 5 w tej samej kolejności, najlepiej rano w dzień roboczy, kiedy hosting i twórcy wtyczek odpowiadają na zgłoszenia.

Co sprawdzić po aktualizacji

• Strona główna i kilka podstron w oknie prywatnym, na telefonie i na komputerze.
• Sklep: dodanie do koszyka, kasa, testowa płatność, mail z potwierdzeniem zamówienia.
• Formularze kontaktowe: wyślij wiadomość i sprawdź, czy doszła.
• Edytor: otwórz wpis, stronę z kreatora i produkt, zmień coś i zapisz.
• Raport Stan witryny: czy nie pojawiły się nowe krytyczne problemy.
• Log błędów: plik wp-content/debug.log, jeśli masz włączone WP_DEBUG_LOG, albo log błędów PHP w panelu hostingu.

Jeśli po aktualizacji pojawi się komunikat „Na tej stronie wystąpił błąd krytyczny”, skorzystaj z poradnika Błąd krytyczny WordPress. Przy pustej stronie zajrzyj do artykułu Biały ekran WordPress, a jeśli winna jest konkretna wtyczka, do tekstu Strona nie działa po aktualizacji.

WordPress nie ma przycisku „cofnij aktualizację rdzenia”. Najpewniejszy powrót to kopia zapasowa z kroku 1. Przez WP-CLI można wgrać poprzednią wersję poleceniem wp core update --version=7.1.3 --force, ale aktualizacja mogła już zmienić bazę danych, więc kopia jest bezpieczniejsza.

Kiedy nie robić tego samemu

Przygotowanie opisane wyżej zrobisz sam, jeśli masz kopię testową i godzinę spokoju. Poproś o pomoc, gdy:

• sklep stoi na starej wersji WordPressa lub PHP i aktualizacja oznacza skok o kilka wersji naraz,
• strona korzysta z płatnych wtyczek lub motywu, które nie mają aktualnej licencji,
• ktoś kiedyś zmieniał kod wtyczek lub motywu bez motywu potomnego i aktualizacja nadpisze te zmiany,
• po aktualizacji coś przestało działać, a nie masz pewnej kopii,
• nie masz czasu, żeby przejść test przed sezonem świątecznym.

Najczęstsze pytania