Plany wydawnicze WordPress 7.2: tryb sudo, Secrets API, notatki w Gutenbergu i zespół wydania

#Kto prowadzi wydanie WordPress 7.2

Według strony wydania 7.2 liderem zespołu wydania WordPress 7.2 jest Matt Mullenweg. Ta sama strona wymienia pozostały skład:

Cykl wydania zbiegł się z krótkim sporem o kierownictwo w Automattic, firmie, którą kieruje Mullenweg. 10 września 2026 r. Automattic poinformował, że Mullenweg przebywa na urlopie, a firmą jako tymczasowy CEO pokieruje dyrektor finansowy Mark Davies. 12 września rzecznik firmy przekazał serwisowi CMSWire, że Mullenweg jest prezesem i CEO z pełnym poparciem zarządu, a później Automattic określił jego nieobecność na 33 godziny i 20 minut, nie wyjaśniając powodu urlopu. Jego rola w projekcie open source WordPress w tych dniach się nie zmieniła: dyrektor wykonawcza WordPressa Mary Hubbard oświadczyła, że pozostaje on liderem projektu (WebHosting.Today).

Zespół wydania podejmuje i komunikuje decyzje dotyczące wydania oraz zbiera opinie społeczności. Cotygodniowe spotkania deweloperów odbywają się w środy o 15:00 UTC na kanale #core w Slacku Making WordPress.

#Notatki w Gutenbergu w WordPress 7.2

Notatki są już w rdzeniu. Według zgłoszenia o kolejnej iteracji notatek w 7.2 WordPress 7.1 wprowadził notatki do zaznaczonego tekstu, formatowanie w treści notatki, podpowiadanie wzmianek @ i powiadomienia e-mail dla wspomnianych osób. Plan wymienia trzy nowości w 7.2.

Dzięki notatkom w 7.2 zespoły redakcyjne powinny móc:

• Zaproponować zmianę w trybie sugestii, którą autor potem akceptuje albo odrzuca.
• Dodawać do notatek reakcje emoji jako szybką informację zwrotną.
• Dodać notatkę z paska narzędzi bloku, bo dziś tę opcję trudno znaleźć.

Według aktualizacji tego zgłoszenia z 30 września tryb sugestii jest ukryty za flagą eksperymentu w dziewięciu pull requestach, które nie przeszły jeszcze pełnego przeglądu, reakcje emoji przeniesiono z 7.1 do nowego selektora emoji, a pull request ze skrótem na pasku narzędzi został zatwierdzony. Prace, które się nie zmieszczą, zbiera osobne zgłoszenie dla 7.3, więc zanim obiecasz zespołowi redakcyjnemu tryb sugestii, sprawdź notatki deweloperskie do Bety 1.

#Współpraca w czasie rzeczywistym w WordPress 7.2

Wspólna edycja w czasie rzeczywistym nie wchodzi do 7.2. Plan ją pomija, dopóki nie zapadną decyzje architektoniczne. Współpracę w czasie rzeczywistym usunięto z WordPressa 7.0, a 18 września 2026 r. Chris Zarate zaproponował podejście oparte na serwerze. Dziś przeglądarki scalają zmiany bezpośrednio i wysyłają wynik przy zapisie. Według propozycji każda aktualizacja przechodzi przez WordPressa, który zapisuje jej autora, sprawdza uprawnienia, scala ją i zapisuje wynik, a następnie wysyła pozostałym uczestnikom brakujące zmiany albo zgłasza konflikt do przejrzenia. Przeglądarki przestałyby wymieniać aktualizacje między sobą.

Wpis zaznacza, że to wczesny etap badań i rozwiązanie nie jest gotowe do rdzenia. Trzy kandydujące silniki synchronizacji (Yjs-server, Distributed Editing i Intent log) leżą w repozytorium gutenberg-sync-engines jako eksperymentalna wtyczka. Otwartym kosztem jest hosting: scalanie po stronie serwera zwiększa obciążenie, częste odpytywanie jest droższe na słabszych planach, a transport przez WebSocket wymagałby demona działającego poza pulą procesów PHP i zarządzanego przez hosting.

#Czym jest tryb sudo w WordPress 7.2

W dobie zaawansowanych automatów skanujących i złośliwych skryptów przechwytujących sesje (session hijacking), tradycyjne uwierzytelnianie administratora przestaje wystarczać. Jeśli złośliwy skrypt przechwyci aktywne pliki cookie lub token aktywnego administratora, uzyskuje on natychmiastowy i nieograniczony dostęp do całej witryny.

Plan prac wymienia dla 7.2 tryb sudo: ponowne uwierzytelnienie przed akcjami o najwyższych uprawnieniach. Nazwa pochodzi od uniksowego polecenia sudo. Sam przechwycony plik cookie sesji nie wystarczyłby wtedy do wykonania uprzywilejowanej akcji, bo akcja ponownie poprosi o dane logowania.

Nie wiadomo jeszcze publicznie, które akcje zostaną nim objęte. Plan zapowiada propozycję i zaproszenie do współpracy, a gdy sprawdzaliśmy 12 października 2026 r., na make.wordpress.org/core nie było jeszcze żadnej propozycji trybu sudo. Do tego czasu sensownym przygotowaniem jest inwentaryzacja: spisz własne ekrany administracyjne i endpointy REST w swoich wtyczkach, które zmieniają użytkowników, role i uprawnienia, pliki lub ustawienia bezpieczeństwa, bo właśnie przed nimi stanąłby krok ponownego uwierzytelnienia.

#Secrets API w WordPress 7.2 do kluczy API

Przechowywanie kluczy API (np. do Stripe, Mailchimp czy zewnętrznych baz danych) od zawsze stanowiło słaby punkt WordPressa. Przez ponad dwie dekady programiści musieli zapisywać wrażliwe klucze bezpośrednio w pliku wp-config.php lub w bazie danych jako niezaszyfrowane wpisy w tabeli wp_options.

Propozycja Secrets API autorstwa Erica Manna z 25 sierpnia 2026 r. celuje w wersję 7.2 i wprowadza pełnoprawny magazyn danych uwierzytelniających. Opis problemu jest konkretny: klucze zapisane otwartym tekstem w tabeli opcji trafiają do zrzutów bazy, kopii zapasowych, klonów stagingowych i wyników poleceń CLI, a wtyczki, które same szyfrują swoje klucze, robią to każda inaczej. Integracje z AI dodatkowo podnoszą koszt wycieku klucza.

Proponowany projekt:

• Szyfrowanie jest zawsze włączone. Każdy sekret dostaje własny klucz danych, opakowany kluczem głównym, który z kolei opakowuje klucz witryny (szyfrowanie kopertowe). Nie ma trybu otwartego tekstu ani stałej wyłączającej szyfrowanie. Kryptografia korzysta z libsodium, a awaryjnie z sodium_compat.
• Domyślnym magazynem jest tabela opcji, w której leży wyłącznie szyfrogram z autoload=no, wyłączony z options.php i z endpointu ustawień REST. Preferowanym źródłem klucza jest osobna stała; witryny bez niej korzystają z klucza wyprowadzonego z istniejących soli.
• Zewnętrzne magazyny podłącza się przez drop-in. Plik secrets.php udostępnia dwa osobne punkty rozszerzeń: przechowywanie (na przykład HashiCorp Vault albo AWS Parameter Store) i pęk kluczy (KMS albo HSM).
• W razie awarii odmawia dostępu. Gdy backend jest nieosiągalny, wywołanie kończy się błędem, bez lokalnej ścieżki zapasowej. Wartości można tylko zapisywać: nie ma eksportu.

#Funkcje Secrets API w WordPress 7.2

wp_set_secret( string $name, string $value ): bool|WP_Error
wp_get_secret( string $name, string $version = WP_Secret_Version::CURRENT ): WP_Secret|null|WP_Error
wp_delete_secret( string $name ): bool|WP_Error
wp_import_option_as_secret( string $option, string $name ): bool|WP_Error

wp_get_secret() zwraca obiekt WP_Secret, a nie ciąg znaków. Wartość wydobywa się przez reveal(), a fingerprint() daje identyfikator, który można bezpiecznie zapisać w logach. Obiekt maskuje się w logach, w var_dump() i w komunikatach błędów oraz odmawia serializacji. Funkcja zwraca null, gdy sekret nie istnieje, i WP_Error, gdy istnieje, ale nie da się go odszyfrować. Nazwy zgodnie z konwencją mają przestrzeń nazw w formie plugin-slug/secret-name.

Dostępu do magazynu pilnują dwa uprawnienia: manage_secrets i manage_network_secrets. W multisite główny klucz sieci wyprowadza podklucze dla poszczególnych witryn, a sekrety witryny i sieci obsługują osobne funkcje, bez niejawnego przełączania się między nimi. Rotację przeprowadza operator, korzystając z dwóch slotów wersji, CURRENT i PREVIOUS, a przy każdym zapisie uruchamia się hook z informacją o wykonawcy, znacznikiem czasu oraz starym i nowym odciskiem.

Na ścieżce odczytu celowo nie ma filtra: filtr pozwoliłby dowolnej wtyczce przechwytywać dane uwierzytelniające, dlatego hostingi podłączają się przez dostawców. Propozycja otwarcie mówi też o swoich ograniczeniach. Każdy kod działający wewnątrz WordPressa może wywołać wp_get_secret(), a slug wtyczki w nazwie sekretu nie jest uwierzytelniany, więc API nie izoluje sekretów jednej wtyczki od drugiej. Usuwa natomiast klucze zapisane otwartym tekstem ze zrzutów bazy, kopii zapasowych i kopii stagingowych.

Dla agencji i deweloperów budujących nowoczesne integracje (w tym integracje z agentami AI, gdzie klucze API są intensywnie wykorzystywane) Secrets API to ustandaryzowane ramy, które przybliżają bezpieczeństwo WordPressa do standardów oprogramowania enterprise.

#Jak przenieść klucze API wtyczki do Secrets API

Propozycja nie przewiduje w 7.2 ekranu w panelu administracyjnym: ekran ustawień odłożono do 7.3. Obsługa WP-CLI mieści się w zakresie 7.2, żeby dane uwierzytelniające przestały trafiać do historii powłoki i list procesów, ale nazwy poleceń nie są jeszcze ustalone (to jedno z otwartych pytań we wpisie). Najpierw ma powstać wtyczka funkcyjna, a po niej łatka do rdzenia z tym samym API.

W kodzie wtyczki migracja to świadomy krok dla każdej opcji osobno, przez wp_import_option_as_secret(), a nie automatyczne przeczesanie bazy. Zaimportowane sekrety są oznaczane do rotacji, bo stara wartość w otwartym tekście trafiła już do każdej dotychczasowej kopii zapasowej. Odczyt bezpieczny dla wtyczki, która musi działać na 7.1 i 7.2, wygląda tak:

$name = 'my-plugin/stripe-key';

if ( function_exists( 'wp_get_secret' ) ) {
	$secret = wp_get_secret( $name );
	if ( null === $secret && get_option( 'my_plugin_stripe_key' ) ) {
		wp_import_option_as_secret( 'my_plugin_stripe_key', $name );
		$secret = wp_get_secret( $name );
	}
	$key = $secret instanceof WP_Secret ? $secret->reveal() : '';
} else {
	$key = (string) get_option( 'my_plugin_stripe_key', '' );
}

Sygnatury pochodzą z propozycji i mogą się zmienić przed Betą 1, więc zostaw warunek function_exists() i starą ścieżkę dla witryn na 7.1. Propozycja nie mówi, czy import usuwa pierwotną opcję, dlatego zanim cokolwiek skasujesz, sprawdź notatkę deweloperską. Gdy klucz trafi już do Secrets API, wygeneruj nowy u operatora płatności lub dostawcy API.

#Dlaczego hostingi mają zastrzeżenia do propozycji Secrets API

Dyskusja pod propozycją pokazuje, które elementy projektu wciąż budzą spór. Chris Reynolds z Pantheon napisał, że Pantheon utrzymuje zewnętrzny magazyn sekretów, do którego aplikacje mają dostęp tylko do odczytu, zapytał, czy dostawcy tylko do odczytu mieszczą się w zakresie i jak wtyczki mają obsłużyć WP_Error zwrócony przy zapisie, oraz zauważył, że magazyny platformowe wymagające otwartego tekstu kłócą się z modelem drop-in. Ryan McCue z Altis sprzeciwił się propozycji w obecnym kształcie i argumentował, że WordPress powinien sekrety tylko odczytywać, a szyfrowanie zostawić zewnętrznym modułom HSM.

Eric Mann odpowiedział, że dostawca tylko do odczytu może zamienić funkcję zapisu w operację pustą i że hostingi będą mogły podstawić silniejszego dostawcę, czego przykładem jest integracja z AWS Secrets Manager w jego repozytorium secrets-api. Zastrzeżenia hostingów dotyczące dostawców podejmuje pull request do wordpress-develop (#13759). We wpisie zostaje pięć otwartych pytań, między innymi o to, czy dwa sloty wersji wystarczą i które polecenia WP-CLI powstaną najpierw.

Dla autora wtyczki praktyczny wniosek jest taki, że wp_set_secret() na hostingu zarządzanym może z założenia zwrócić błąd. Formularz ustawień zapisujący klucz musi pokazać zwrócony błąd, a nie zakładać sukces.

#Zmiany w hasłach aplikacji w WordPress 7.2

Sekcja bezpieczeństwa w planie wymienia też wzmocnienie haseł aplikacji (Application Passwords): poprawki interfejsu, powiadomienie e-mail po dodaniu nowego hasła aplikacji, poprawki wykrywania środowiska, bezpieczniejszą obsługę default_role i obsługę ciasteczek SameSite. Prace śledzą zgłoszenia w Tracu #66009, #63927, #57388, #46744 i #37000. Listę zmian w bezpieczeństwie zamyka utwardzone przetwarzanie HTML oparte na HTML API.

Hasła aplikacji to dane uwierzytelniające, z których korzysta większość integracji z REST API, więc powiadomienie daje właścicielowi witryny sygnał, gdy ktoś doda takie hasło bez jego wiedzy.

#Inne funkcje w planach WordPress 7.2

Ipsum, nowy domyślny motyw, to minimalistyczny motyw blogowy pomyślany jako czyste płótno, z kropkowanymi podkreśleniami, kilkoma zestawami typografii i wariantami stylu, które zmieniają kolory całej strony, łącznie z obrazkami. Według wpisu wprowadzającego Henrique Iamarino każde połączenie kolorów i stylów spełnia wymagania kontrastu WCAG AA. Ipsum kończy też z nazywaniem domyślnych motywów od roku. Kod jest na GitHubie do testów, a zespół określa harmonogram jako napięty.

Prace nad AI toczą się we wtyczce AI, bez gwarancji, że trafią do rdzenia: więcej możliwości (eksperymentalny dostęp tylko do odczytu do mediów, taksonomii i komentarzy), MCP Adapter zaktualizowany do bieżącej specyfikacji MCP i dystrybuowany przez katalog wtyczek, tożsamości agentów z audytowalnymi uprawnieniami oraz strumieniowanie odpowiedzi w PHP AI Client.

W blokach i API plan wymienia blok listy opisów dla <dl>, <dt> i <dd>, wyszukiwanie po słowach kluczowych w bloku ikony, dyrektywę data-wp-html i router w Interactivity API oraz renderowanie po stronie serwera dla bloku spisu treści, żeby mógł stać się stabilny. Aktualizacja do React 19 w dużej mierze trafiła już do Gutenberga, ale raczej nie wejdzie w całości do 7.2.

W panelu administracyjnym DataViews i DataForms dostają widoki, pola i akcje rejestrowane po stronie serwera, a inspektor wpisu zostaje zastąpiony przez DataForm. Komunikaty błędów stają się łatwiejsze do zdiagnozowania i dostają przycisk kopiowania, a przebudowane fundamenty edytora witryny pozwalają wtyczkom rejestrować własne ekrany. W wydajności łączenie skryptów i stylów zastępuje prefetching (Trac #57548), równolegle z pracami z wtyczki Enhanced Responsive Images.

#Harmonogram wydania WordPress 7.2

David Baumwald opublikował harmonogram wydania WordPress 7.2 na make.wordpress.org 6 października 2026 r. Każdy etap startuje o 15:00 UTC.

Od Bety 1 kontrybutorzy rdzenia przechodzą na testowanie i poprawianie błędów, a zaczynają się pojawiać notatki deweloperskie. RC1 przynosi Field Guide, twarde zamrożenie tekstów interfejsu i gałąź wydania. Po zamrożeniu funkcji trafiają już tylko poprawki błędów, w pierwszej kolejności regresji.

Zainstaluj Betę 1 na kopii stagingowej 20 października i powtórz testy wtyczek oraz motywu na RC1 (17 listopada), żeby konflikty wyszły na stagingu przed 8 grudnia.

#Jak testować betę WordPress 7.2

Są dwie udokumentowane drogi. Wtyczka WordPress Beta Tester, dostępna w menu Narzędzia, Beta Testing (w multisite w Ustawieniach), przełącza wbudowany mechanizm aktualizacji z domyślnego kanału Point release na Bleeding edge (trunk) albo na paczki beta i RC. W wierszu poleceń wp core update przyjmuje --version=nightly albo ścieżkę do pobranego pliku zip. Najpierw zrób kopię zapasową i nie instaluj wersji beta na produkcji.

Co testować, wynika z planu: wtyczki, które trzymają klucze API w opcjach, własne procesy administracyjne zmieniające użytkowników lub pliki, procesy redakcyjne oparte na notatkach oraz motywy potomne, jeśli planujesz przenieść witrynę na Ipsum.

#Jak przygotować stronę na WordPress 7.2

Wydanie WordPress 7.2 to jedna z najważniejszych strukturalnych zmian w 2026 roku. Połączenie zaawansowanych funkcji pracy zespołowej z zaostrzonymi standardami bezpieczeństwa backendu oznacza, że deweloperzy i agencje muszą zacząć przygotowywać swoje systemy już teraz.

W WPPoland już dziś przygotowujemy nasze bezgłowe instalacje Astro oraz integracje z serwerami MCP tak, aby korzystały z nowego Secrets API i obsługiwały ponowne uwierzytelnianie w trybie sudo.

Chcesz zabezpieczyć swój system WordPress klasy enterprise lub zmigrować swoje autorskie wtyczki do standardów nadchodzącej wersji 7.2? Skontaktuj się ze mną w celu przygotowania planu migracji.