WordPress 7.2 jest planowany jako duże wydanie na 8 grudnia 2026 roku. Słowo „planowany” robi tu sporą robotę, bo roadmapa opisuje aktywnie rozwijane prace, a nie gotowy, wyryty w kamieniu changelog. Część zapowiadanych elementów może się zmienić albo nie trafić do wersji finalnej.

Nie ma więc powodu, żeby panikować, wyłączać sklep i instalować pierwszą wersję testową na stronie produkcyjnej. Jest za to dobry moment, żeby wiedzieć, co może się zmienić w obsłudze haseł aplikacji, ciasteczek i dostępu administracyjnego. Szczególnie jeśli strona korzysta z integracji API, formularzy, logowania albo WooCommerce. Krótko mówiąc: bez alarmu, ale z głową.

WordPress 7.2: co jest planowane, a co już pewne?

Roadmapa WordPressa 7.2 obejmuje kilka tematów związanych z bezpieczeństwem. Wśród nich są usprawnienia Application Passwords, lepsze wykrywanie środowisk HTTPS i lokalnych, wsparcie dla atrybutu SameSite ciasteczek, bezpieczniejsze traktowanie wartości default_role, a także dalsze prace nad Secrets API i tak zwanym sudo mode.

To brzmi technicznie, ale sens jest dość praktyczny: chodzi o bezpieczniejsze logowanie, ograniczenie pomyłek przy używaniu poświadczeń i lepszą ochronę operacji administracyjnych. Nie wszystkie elementy są jednak równie dojrzałe. Application Passwords i SameSite mają opisane konkretne kierunki prac, natomiast Secrets API oraz sudo mode pozostają bardziej niepewne.

Według obecnego harmonogramu kolejne wersje beta mają pojawiać się od 20 października 2026 roku, a wersje RC od 17 listopada. Terminy mogą się zmienić. Beta i RC służą testom, więc nie powinny trafiać bezpośrednio na produkcyjną stronę firmy. Strona firmowa to nie laboratorium, zwłaszcza gdy właśnie obsługuje klientów.

Application Passwords: mniej miejsca na phishing i pomyłki

Najbardziej konkretne planowane zmiany dotyczą Application Passwords, czyli haseł aplikacji używanych przez wybrane integracje i połączenia z WordPressem. Nie chodzi o zwykłe hasło użytkownika, tylko o osobne poświadczenie dla aplikacji. Taki mechanizm może być przydatny, ale każde dodatkowe poświadczenie trzeba traktować jak dane, których nie pokazuje się światu.

Planowany ekran zatwierdzania ma wyraźniej pokazywać host docelowy. Użytkownik powinien więc łatwiej ocenić, gdzie trafią przekazywane dane. Ma także zniknąć obsługa formatu username:password@ w adresach URL oraz tak zwanego reject URL. Do tego przewidziano przycisk kopiowania wygenerowanego hasła aplikacji. Niby drobiazgi, ale właśnie na takich drobiazgach często wykłada się codzienna obsługa strony.

Roadmapa wymienia również powiadomienie e-mail po dodaniu hasła aplikacji. Dla właściciela strony oznacza to dodatkowy sygnał: jeśli ktoś utworzył nowe poświadczenie, łatwiej szybciej zauważyć, że wydarzyło się coś, czego nie planowaliśmy. To nie jest magiczna tarcza przed phishingiem ani zamiennik ochrony kont użytkowników. Poświadczeń nadal nie wolno publikować w artykułach, zrzutach ekranu czy publicznych repozytoriach.

Co właściciel strony może zauważyć w praktyce?

Najpewniej nie zmieni się wygląd publicznej strony. Zmiany dotyczą raczej procesu tworzenia i zatwierdzania dostępu. Czytelniejszy host może ułatwić sprawdzenie, gdzie wysyłane są dane, a przycisk kopiowania ograniczyć pomyłki przy przekazywaniu hasła do właściwej integracji.

Powiadomienie e-mail może z kolei szybciej zasygnalizować utworzenie nowego hasła. Warto wtedy wiedzieć, kto i po co je utworzył. Nie oznacza to, że WordPress 7.2 automatycznie uporządkuje wszystkie stare poświadczenia. Przed aktualizacją dobrze po prostu sprawdzić, jakie hasła aplikacji są używane, a które stały się cyfrowymi duchami.

HTTPS i środowisko lokalne: dlaczego WordPress się tym interesuje?

Jednym z planowanych tematów jest lepsze wykrywanie, czy Application Passwords działają w środowisku HTTPS albo lokalnym. W opisie prac wskazano problem, w którym niektóre witryny bez HTTPS mogą być traktowane jako środowiska deweloperskie, mimo że wymagane jest środowisko lokalne.

Dla właściciela strony ważny jest wniosek praktyczny: HTTPS nie powinno być traktowane jako ozdobny dodatek przy panelu i integracjach. Po aktualizacji warto sprawdzić, czy certyfikat działa, przekierowania prowadzą tam, gdzie powinny, a połączenia korzystające z logowania lub API nadal działają prawidłowo.

To nadal nie znaczy, że nowe mechanizmy Application Passwords zastąpią HTTPS. Nie zastąpią też aktualizacji motywu, wtyczek, PHP ani zabezpieczenia kont użytkowników. Bezpieczeństwo nie działa jak jeden przełącznik „włącz i zapomnij”.

SameSite cookies: mała etykieta, duży temat

WordPress 7.2 ma obejmować wsparcie dla atrybutu SameSite ciasteczek. Ciasteczka pomagają między innymi utrzymywać sesję i pamiętać, że użytkownik jest zalogowany. Atrybut SameSite ogranicza wysyłanie ciasteczek podczas części żądań między różnymi źródłami.

W praktyce chodzi o dodatkową kontrolę nad tym, kiedy informacje związane z sesją mogą zostać wysłane. Mechanizm może pomagać ograniczać ryzyko ataków CSRF. Dla właściciela firmy ważne jest jednak to, że zmiana dotyczy ochrony sesji i logowania, a nie wyglądu strony. Nie pojawi się nagle nowy kolor przycisku ani fajerwerki na stronie głównej. I dobrze.

Wsparcie SameSite nie jest kompletnym zabezpieczeniem całej witryny. Po aktualizacji warto sprawdzić logowanie, formularze i integracje, jeśli korzystają z ciasteczek. Szczegóły mogą jeszcze ulec zmianie przed publikacją finalnego changelogu, dlatego nie należy traktować planu jak gwarancji identycznego działania w każdej instalacji.

Secrets API i sudo mode: ciekawe kierunki, ale jeszcze bez fanfar

Secrets API jest opisywane jako propozycja mechanizmu przechowywania danych uwierzytelniających. Brzmi jak coś, co może uporządkować pracę z sekretami, ale w przypadku WordPressa 7.2 zakres może ograniczyć się do obsługi WP-CLI. Interfejs użytkownika do zarządzania sekretami jest planowany na późniejsze wydanie.

Nie warto więc pisać, że po aktualizacji każdy właściciel strony dostanie pełny panel do przechowywania i obsługi sekretów. Tego na tym etapie nie potwierdzono. Podobnie wygląda sprawa sudo mode. To początkowe prace i propozycja funkcji, która potencjalnie mogłaby wymagać ponownego uwierzytelnienia przed wybranymi, szczególnie wrażliwymi działaniami administracyjnymi.

Oba tematy są interesujące, ale jeszcze nie są gotowym pakietem funkcji, który można obiecać każdej instalacji WordPressa 7.2. Najbezpieczniej mówić o kierunkach rozwoju i poczekać na finalne informacje. W międzyczasie nie publikuj kluczy, sekretów ani danych uwierzytelniających — ani w treści, ani na obrazkach, ani w publicznym repozytorium.

Czy trzeba testować stronę przed WordPressem 7.2?

Nie ma potwierdzenia, że WordPress 7.2 wprowadzi formalny obowiązek dodatkowych testów dla każdej strony. Nikt nie powinien dostać komunikatu: „proszę wykonać siedem testów albo strona przestanie działać”. Testowanie jest jednak rozsądną praktyką, zwłaszcza gdy witryna korzysta z wtyczek, motywów i integracji związanych z logowaniem, ciasteczkami, API albo administracją.

Przed aktualizacją przygotuj sprawdzoną kopię zapasową. Jeśli jest taka możliwość, przeprowadź aktualizację najpierw na stagingu, czyli kopii strony przeznaczonej do testów, a nie na produkcji. Nie instaluj bety ani RC bezpośrednio na stronie firmy tylko dlatego, że ciekawość wygrała z rozsądkiem. Ciekawość jest fajna, dopóki nie siedzi na infolinii z klientem.

Źródła nie podają kompletnej listy konfliktów z konkretnymi motywami, wtyczkami, hostingami i integracjami. Dlatego testy są rekomendacją praktyczną, a nie gwarancją, że każdy problem zostanie wykryty. Nie są też oficjalnym nakazem dla każdego właściciela strony.

Co sprawdzić po aktualizacji?

Kontrola nie musi przypominać wielkiej operacji wojskowej. Zacznij od rzeczy, z których firma korzysta codziennie:

• Logowanie do panelu oraz działanie kont użytkowników.
• Formularze i komunikaty po ich wysłaniu.
• Integracje API oraz połączenia z zewnętrznymi usługami.
• Sklep WooCommerce, jeśli strona go posiada, w tym podstawowe działania potrzebne do obsługi sklepu.

Jeśli coś korzysta z ciasteczek, poświadczeń albo dostępu administracyjnego, powinno znaleźć się na liście kontrolnej. Nowe funkcje bezpieczeństwa nie zastępują aktualizacji WordPressa, motywu, wtyczek i PHP ani ochrony kont użytkowników.

Co zrobić już teraz? Krótka lista kontrolna

Nie trzeba dziś przebudowywać całej strony pod WordPressa 7.2. Wystarczy przygotować się bez nerwowych ruchów:

• Śledź finalne informacje o wydaniu i pamiętaj, że roadmapa nie jest zamkniętą listą gwarantowanych funkcji.
• Sprawdź, czy kopia zapasowa jest aktualna i możliwa do wykorzystania.
• Zobacz, jakie hasła aplikacji są używane, a które nie są już potrzebne.
• Jeśli możesz, zaplanuj aktualizację najpierw poza produkcją.
• Po aktualizacji sprawdź logowanie, formularze, ciasteczka, integracje API, zewnętrzne usługi i sklep.
• Pamiętaj o aktualizacjach motywu, wtyczek i PHP oraz ochronie kont użytkowników.

Najważniejsze jest zachowanie proporcji. Nie ignoruj zmian, ale też nie traktuj każdej zapowiedzi jak awarii czekającej za rogiem. WordPress 7.2 ma przynieść usprawnienia w obszarach, które dotyczą dostępu i bezpieczeństwa, jednak szczegóły mogą się jeszcze zmienić.

WordPress 7.2 zapowiada zmiany w Application Passwords, obsłudze HTTPS, ciasteczkach i mechanizmach uwierzytelniania. Część planu jest konkretna, a część — szczególnie Secrets API i sudo mode — pozostaje na wcześniejszym etapie. Dlatego najlepsze przygotowanie to sprawdzona kopia zapasowa, test na stagingu, kontrola integracji i spokojne śledzenie finalnych informacji. Bez wersji testowej na produkcji i bez wiary, że jedna aktualizacja załatwi całe bezpieczeństwo. Masz stronę, sklep albo materiały graficzne, które proszą się o ogarnięcie? Napisz do INB Marketing i zobaczymy, co da się z tym sensownie zrobić.