mDiv.pl
mDiv.pl
arrow_backBaza wiedzy
WordPressHosting11 min czytania2026-11-10

WordPress 7.2 wychodzi 8 grudnia. Trzy zmiany, które mogą zepsuć stronę, i kiedy naprawdę aktualizować

Koniec sklejania skryptów w panelu, przepisany oczyszczacz HTML i zmiana trybu SQL. Co przetestować od 17 listopada, czego spodziewać się po nowym panelu i dlaczego właściciel sklepu nie powinien aktualizować w dniu premiery.

Architekt rysuje projekt ołówkiem przy linijce na drewnianym biurku
fot. Daniel McCullough / Unsplash

W skrócie

WordPress 7.2 wychodzi 8 grudnia 2026, a wersja kandydująca pojawia się 17 listopada. To wydanie wnosi trzy zmiany, które mogą naprawdę zepsuć działającą stronę, i wszystkie trzy są techniczne, więc nie zobaczysz ich w materiałach marketingowych. Panel przestaje sklejać skrypty w jedną paczkę, a stare adresy zwracają teraz kod 410, co wywróci wtyczki odwołujące się do nich wprost. Mechanizm oczyszczania kodu HTML został napisany od nowa i inaczej traktuje zapisaną treść, w tym grafiki SVG. Zmienia się też tryb pracy z bazą danych, a przywrócenie starego zachowania wymaga pliku, którego zwykła wtyczka nie zastąpi. Po stronie zysków jest szybszy panel, nowy sposób przechowywania haseł do usług zewnętrznych i przetwarzanie zdjęć w przeglądarce zamiast na serwerze. Najważniejsza rada dotyczy jednak terminu: jeśli prowadzisz sklep, nie aktualizuj 8 grudnia, bo to środek sezonu świątecznego.

Kalendarz, który warto znać

Etap Data
Beta 1 20 października 2026
Wersja kandydująca 17 listopada 2026
Wydanie 8 grudnia 2026

Testować warto od wersji kandydującej, nie od bety. W becie funkcje wciąż się zmieniają, więc błąd, który znajdziesz, może zniknąć sam albo zostać zastąpiony innym. Wersja kandydująca jest już zamrożona i zachowuje się tak, jak zachowa się wydanie. Siedemnastego listopada masz więc trzy tygodnie na spokojne sprawdzenie, zanim cokolwiek dotknie produkcji.

Trzy zmiany, które mogą zepsuć stronę

To jest sedno tekstu. Każda z tych rzeczy działa dziś i przestanie działać po aktualizacji.

Koniec sklejania skryptów w panelu

Dotąd panel administracyjny łączył wiele plików JavaScript i arkuszy stylów w jedną dużą odpowiedź, serwowaną przez load-scripts.php oraz load-styles.php. Od 7.2 panel ładuje każdy plik osobno, a te dwa adresy zwracają kod 410, czyli trwale usunięte.

Dla Ciebie znaczy to tyle: jeśli któraś wtyczka albo motyw odwołuje się do tych adresów wprost, przestanie dostawać swoje zasoby. Objaw jest charakterystyczny i łatwy do rozpoznania: panel wygląda na rozsypany, przyciski tracą style, a część funkcji przestaje reagować, choć sama strona dla odwiedzających działa normalnie.

Jest też druga strona tej zmiany, o której mowa niżej przy wydajności.

Przepisany oczyszczacz HTML

WordPress ma mechanizm, który sprawdza i czyści kod HTML przed zapisaniem go w bazie. W 7.2 został on napisany od nowa, w oparciu o nowy analizator składni.

Nowa wersja normalizuje wynik, usuwa zawartość znaczników skryptów i stylów oraz odrzuca część niepoprawnie zbudowanych grafik SVG, wzorów matematycznych i komentarzy. To zmiana na korzyść bezpieczeństwa, ale oznacza, że treść zapisana wcześniej może zostać potraktowana inaczej niż dotąd.

Najbardziej narażone są strony, które trzymają w treści surowy kod: bloki własnego HTML, osadzone grafiki SVG w roli ikon, widżety od zewnętrznych usług, a także układy budowane w kreatorach przechowujących znaczniki w bazie.

Zmiana trybu pracy z bazą danych

Ta jest najbardziej techniczna, ale potrafi zaskoczyć najmocniej. WordPress 7.2 usuwa ze swojej sesji połączenia z bazą ustawienie NO_BACKSLASH_ESCAPES. Strony, które na nim polegają, zaczną inaczej traktować ukośniki odwrotne w zapisywanych danych.

Przywrócenie starego zachowania jest możliwe, ale wyłącznie przez plik db.php umieszczony bezpośrednio w katalogu wp-content. Zwykła wtyczka, nawet ta ładowana jako obowiązkowa, uruchamia się za późno, żeby to ustawienie zmienić.

Dotyczy to mniejszości stron, zwykle takich z własnymi integracjami albo importem danych z zewnętrznych systemów. Jeśli Twoja strona to zwykły WordPress z wtyczkami z katalogu, prawdopodobnie Cię to ominie.

Co nowego zobaczysz w panelu

Teraz rzeczy przyjemniejsze, czyli zmiany, które zauważysz jako użytkownik.

Szybszy panel, ale z zastrzeżeniem. Wspomniana wyżej rezygnacja ze sklejania plików ma konkretny cel: przeglądarka może teraz zapamiętać każdy plik osobno, więc po pierwszym wejściu kolejne ekrany ładują się szybciej. Zastrzeżenie dotyczy hostingu. Przy nowoczesnych protokołach, czyli HTTP/2 i HTTP/3, wiele małych plików pobiera się równolegle i zysk jest realny. Na starym hostingu, serwującym po HTTP/1.1, większa liczba połączeń może dać efekt odwrotny i panel potrafi zwolnić.

Nowy sposób przechowywania haseł do usług zewnętrznych. Dochodzi mechanizm przeznaczony do trzymania kluczy i haseł do zewnętrznych API. Do tej pory autorzy wtyczek wrzucali je albo do wp-config.php, albo do tabeli opcji, gdzie leżały otwartym tekstem. To zmiana, która z czasem poprawi bezpieczeństwo wielu instalacji, choć efekt zobaczysz dopiero, gdy autorzy wtyczek zaczną z niej korzystać.

Przetwarzanie zdjęć w przeglądarce. Biblioteka multimediów potrafi teraz przygotować plik po stronie przeglądarki, zanim trafi on na serwer. Przy wgrywaniu wielu zdjęć naraz zdejmuje to obciążenie z hostingu i skraca oczekiwanie.

Nowy motyw domyślny Ipsum oraz drobniejsze rzeczy: reakcje emoji w notatkach współpracy, widżet na pulpicie pokazujący wpisy sprzed lat, odświeżone ikony panelu.

Kiedy aktualizować, a kiedy na pewno nie

Tu mam jedną stanowczą radę i jedną zwyczajną.

Jeśli prowadzisz sklep, nie aktualizuj 8 grudnia. Premiera wypada tydzień po Cyber Monday, w samym środku sezonu świątecznego, gdy ruch i liczba zamówień są najwyższe w roku. Duża aktualizacja rdzenia w takim momencie to ryzyko bez żadnej nagrody. Rozsądny termin to styczeń, po ustaniu zwrotów poświątecznych, gdy autorzy wtyczek zdążą już wypuścić swoje poprawki zgodności.

Dla zwykłej strony firmowej wystarczy odczekać tydzień albo dwa od premiery. W tym czasie pojawią się aktualizacje wtyczek dostosowane do nowego wydania, a pierwsze błędy zostaną zgłoszone i załatane w wydaniu 7.2.1.

W obu przypadkach odradzam zostawianie tego automatom. Aktualizacje w obrębie gałęzi, czyli z 7.2 na 7.2.1, warto mieć włączone. Przejście z 7.1 na 7.2 to decyzja, którą podejmujesz świadomie i w wybranym momencie.

Jak przetestować, krok po kroku

Od 17 listopada, zawsze na kopii testowej, nigdy na produkcji.

Najpierw włącz dziennik diagnostyczny w pliku wp-config.php kopii:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Potem zainstaluj wersję kandydującą i przeklikaj po kolei:

  1. Panel administracyjny, a w nim edytor wpisów, bibliotekę multimediów, listę wtyczek i ustawienia wyglądu. Tu ujawni się problem ze sklejaniem skryptów.
  2. Konsolę przeglądarki na ekranach panelu. Naciśnij klawisz F12, przejdź na zakładkę sieci i poszukaj odpowiedzi z kodem 410. Każda taka pozycja wskazuje wtyczkę do aktualizacji albo wymiany.
  3. Strony zbudowane w kreatorze oraz wszystkie miejsca z własnym kodem HTML i grafikami SVG. Porównaj je z produkcją, szukając znikniętych elementów i rozjechanych układów.
  4. Formularze i koszyk, jeśli prowadzisz sklep. Pełna ścieżka, aż do potwierdzenia zamówienia.

Na końcu sprawdź, co nazbierało się w dzienniku:

grep -c "Deprecated\|Fatal\|Warning" wp-content/debug.log
grep -oE "(Fatal error|Warning)[^,]{0,80}" wp-content/debug.log | sort | uniq -c | sort -rn | head -20

Błędy krytyczne wymagają reakcji przed aktualizacją produkcji. Ostrzeżenia zanotuj i obserwuj, ale same w sobie nie blokują przejścia.

Konkrety na hostingu mDiv

Jeśli korzystasz z naszego hostingu, kilka rzeczy załatwisz szybciej.

Środowisko testowe dostajesz na życzenie, bez dopłaty. Napisz do nas, a przygotujemy kopię strony pod osobnym adresem, na której spokojnie zainstalujesz wersję kandydującą.

Wersję PHP sprawdzisz i zmienisz w panelu, w sekcji Witryny -> [domena] -> PHP. WordPress 7.2 nie podnosi wymagań, ale jeśli stoisz jeszcze na PHP 8.2, pamiętaj, że ta wersja przestaje dostawać łatki bezpieczeństwa 31 grudnia. Opisaliśmy to szerzej w artykule o wyborze wersji PHP.

Protokół nie będzie Twoim problemem. Nasze serwery obsługują HTTP/3 wraz z kompresją Brotli, więc nowy sposób ładowania zasobów panelu zadziała tu na korzyść, a nie przeciwnie. Jeśli korzystasz z innego hostingu, sprawdź, czy serwuje po HTTP/2 lub nowszym, bo od tego zależy, czy panel po aktualizacji przyspieszy, czy zwolni.

Źródła

Czego nie musisz robić sam

Duża aktualizacja rdzenia to środowisko testowe, kopia zapasowa, kolejność operacji i plan wycofania. Na zwykłej stronie firmowej zajmuje godzinę, na sklepie z dwudziestoma wtyczkami cały wieczór, a jej skutki ujawniają się czasem dopiero po kilku dniach.

W pakietach opieki nad stroną aktualizacje major robimy zgodnie z tą procedurą, w oknie nocnym, z pełnym planem wycofania i raportem po wszystkim. Jeśli masz sklep i nie chcesz podejmować decyzji o terminie samodzielnie, napisz do nas albo wyceń opiekę.

Siódemka dwa to dobre wydanie i nie ma powodu się go bać. Jest tylko powód, żeby nie wpuszczać go na produkcję w tygodniu, w którym Twoi klienci kupują prezenty.

Mirosław Parcz

O autorze

Mirosław Parcz

Programista i administrator serwerów

Programista i administrator serwerów z 16+ letnim doświadczeniem. Specjalizacja: WordPress/WooCommerce, aplikacje webowe, hosting, wydajność, bezpieczeństwo, integracje AI.

Spodobało się? Podaj dalej.

LinkedIn

Potrzebujesz pomocy?

mDiv może zająć się tym za Ciebie. Bezpiecznie, z backupem i bez przestojów.

Napisz do mnie