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.

Według planu notatki w 7.2 miały pozwolić zespołom redakcyjnym:

• 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.

Aktualizacja, 23 października 2026: Ogłoszenie Bety 1 z 20 października wymienia reakcje emoji w notatkach, nową ikonę na pasku narzędzi, notatki w obszarze edycji i zminimalizowany tryb notatek. Trybu sugestii na tej liście nie ma, więc nie planuj pod niego pracy redakcji w 7.2.

#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 sprawdzałem 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.

Aktualizacja, 20 października 2026: ogłoszenie Bety 1 nie wymienia trybu sudo ani w części dla redaktorów, ani w części dla programistów. Jeśli trafi do 7.2, stanie się to w kolejnych betach.

#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.

Aktualizacja, 18 października 2026: wtyczka MCP Adapter jest w wersji 0.7.1 z 15 października 2026. Ogranicza zapisane dane inicjalizacji sesji do 4 KiB (klienci, których to dotyczy, połączą się ponownie jeden raz), zwraca czytelniejsze błędy dla niedostępnych zdolności i dodaje przewodnik dla właścicieli stron: podłączenie klienta AI przez Application Passwords i rozwiązywanie problemów. Autorzy wtyczek powinni pamiętać o zmianie z wersji 0.7.0: dołączanie adaptera jako biblioteki jest przestarzałe, a strony mają instalować wtyczkę.

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.

Aktualizacja, 24 października 2026: Gutenberg 24.2, wydany 14 października, włącza we wtyczce eksperyment React 19 domyślnie. Strony z tą wtyczką ładują React 19 dla skryptów react i react-dom, chyba że aktywny jest motyw albo wtyczka z listy znanych niezgodności. Wtedy zostają przy React 18. Jeśli coś przestanie działać, React 19 wyłączysz w menu Gutenberg, Experiments. Zespół Gutenberga prosi autorów wtyczek i motywów korzystających z Reacta o testy na 24.2 i zgłaszanie błędów, a do ustawiania atrybutu inert tak, żeby działał w obu wersjach, udostępnia nowy pakiet @wordpress/react-inert-value. Ogłoszenie Bety 1 w ogóle nie wspomina o React 19, więc testuj swój kod z Gutenbergiem 24.2, zamiast zakładać, co trafi do samego WordPressa 7.2.

#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.

Aktualizacja, 20 października 2026: Beta 1 wyszła zgodnie z harmonogramem, a ogłoszenie potwierdza termin wydania finalnego na 8 grudnia 2026. Secrets API jest w Becie 1 (Trac #66187): szyfrowanie w spoczynku, rotacja danych uwierzytelniających i własni dostawcy magazynu. Dla programistów doszły też rozszerzenia Abilities API do odczytu i wyszukiwania danych WordPressa, renderowanie zaufanego HTML i reaktywna nawigacja w Interactivity API oraz panel, który ładuje skrypty i style osobno zamiast w dużych paczkach i z wyprzedzeniem pobiera zasoby następnego ekranu. Biblioteka mediów zmniejsza, kompresuje i konwertuje obrazy w przeglądarce przed wysłaniem na serwer. Najszybciej przetestujesz betę poleceniem wp core update --version=7.2-beta1 na kopii stagingowej.

Aktualizacja, 21 października 2026: Ogłoszenie Bety 1 wymienia też widżet kokpitu On This Day (Trac #65116), który pokazuje wpisy opublikowane tego samego dnia w poprzednich latach, przekierowanie pod osobnym adresem do losowo wybranego wpisu (Trac #64498), cień tekstu z presetami w theme.json oraz ikony z biblioteki ikon WordPressa zamiast Dashicons na pasku administracyjnym i w menu bocznym. Notatki przenoszą się na płótno edytora i dostają reakcje emoji oraz ikonę na pasku narzędzi. Ogłoszenie nie wspomina o trybie sudo ani o trybie sugestii w notatkach, więc zanim zaplanujesz wdrożenie pod te funkcje, sprawdź ich zgłoszenia w Trac i notatki deweloperskie przed RC1 (17 listopada).

Aktualizacja, 3 listopada 2026. Numeracja bet przesunęła się po wydaniu bezpieczeństwa. Beta 2 wyszła 27 października do testów (wp core update --version=7.2-beta2 na stagingu). 28 października strona WordPress 7.2 zapisuje Betę 3 razem z WordPressem 7.1.4 (pakiet wordpress-7.2-beta3.zip ma znacznik czasu z tego dnia). Party na 3 listopada to teraz Beta 4, a 10 listopada to Beta 5; RC1 zostaje 17 listopada, finał 8 grudnia. W chwili tej aktualizacji zip Bety 4 jeszcze nie był opublikowany - poczekaj na link ZIP na make.wordpress.org/core/7-2 albo na wpis na WordPress.org News, zanim podniesiesz staging powyżej beta3. Produkcję trzymaj na 7.1.4.

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.

Aktualizacja, 24 października 2026: Commit w rdzeniu z 19 października 2026 autorstwa Westona Rutera (r64585) kończy łączenie skryptów i stylów w panelu i na ekranie logowania. Pliki wp-admin/load-scripts.php i wp-admin/load-styles.php odpowiadają teraz na każde żądanie kodem 410 Gone i jednym zdaniem zwykłego tekstu, bez ładowania WordPressa. Stała CONCATENATE_SCRIPTS nie jest już odczytywana i zniknęła ze Stanu witryny. Przegląd zgodności w pull requeście 14463 przeszukał katalogi wtyczek i motywów: żaden motyw z katalogu nie używa wycofanego kodu, a około 45 wtyczek odwołuje się do obu plików bezpośrednio, zwykle z własnych okien dialogowych, podglądów albo ekranów konfiguracji. Wśród utrzymywanych wtyczek przegląd wymienia Ad Inserter (przyciski w oknie podglądu najpewniej nie działają), CartFlows (nieudane żądanie na każdym ekranie panelu, bez widocznych skutków), Modulę (jej okno galerii w klasycznym edytorze niczego nie wstawia) i UiPress Lite (pasek narzędzi bez stylów na jej ekranach).

Co sprawdzić na kopii testowej z Betą 1:

• Właściciel strony: otwórz okna dialogowe, podglądy i ekrany konfiguracji swoich wtyczek i patrz w zakładce sieci w przeglądarce, czy żądania do load-scripts.php albo load-styles.php nie zwracają 410. Widoczny objaw to strona bez stylów albo przycisk, który nic nie robi. Ten test to moja propozycja, nie zalecenie ze źródeł.
• Autor wtyczki: zamień wpisane na sztywno adresy tych plików na zasoby dodawane przez kolejkę albo, na samodzielnej stronie, na wp_print_scripts() i wp_print_styles(), tak jak zaleca przegląd.
• Autor wtyczki: kod, który ustawia do_concat na true albo zwraca false z print_head_scripts, print_footer_scripts, print_admin_styles lub print_late_styles, żeby wstrzymać wypisywanie, przestaje działać, bo każdy element jest od razu wypisywany jako osobny znacznik.
• Autor wtyczki: _print_scripts(), _print_styles(), script_concat_settings(), in_default_dir() i WP_Dependencies::get_etag() są przestarzałe, a podpięcie się pod cztery filtry wypisywania wywołuje teraz powiadomienie o przestarzałości. Przestarzałe właściwości WP_Scripts i WP_Styles pozostają zadeklarowane i nie dają powiadomienia.

Sprawdzanie wtyczek na kopii testowej przed dużym wydaniem to część mojego utrzymania stron na WordPressie.

Już dziś przygotowuję moje instalacje headless na 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.