WordPress 7.1 „Mary Lou” wyszedł 19 sierpnia 2026. To nie jest kolejny changelog z edytora blokowego — to wydanie, które zmienia sposób, w jaki stylujesz layout, współpracujesz nad treścią i przetwarzasz media. Poniżej: co faktycznie się zmieniło względem 7.0, co z bezpieczeństwem (7.0.2–7.0.4) i jak podjąć decyzję o aktualizacji na produkcji, a nie na slajdzie z konferencji.

Premiera i kontekst

7.1 to drugie duże wydanie w 2026, po WordPress 7.0 z maja. Oficjalne ogłoszenie i Field Guide są na WordPress.org — warto je przeczytać przed ruchem na produkcji, zwłaszcza jeśli utrzymujesz własne bloki, meta boxy albo skórki edytora.

Jeśli na serwerze nadal siedzisz na 7.0.0 albo 7.0.1, aktualizacja nie jest „feature release”. Najpierw doganiasz security, potem myślisz o 7.1.

Najważniejsze zmiany w 7.1

Responsywne style bez własnego CSS

W Site Editorze ustawiasz wygląd bloku na desktopie, tablecie i mobile — zarówno w Global Styles, jak i na pojedynczym bloku. Motywy blokowe mogą nadpisać breakpointy w theme.json. To zamyka lukę, którą wcześniej łataliśmy media queries w child theme albo w Custom CSS.

W praktyce: mniej „naprawdę działa, ale tylko na 1440px”. W praktyce też: więcej miejsc, w których treść redakcyjna może zepsuć layout, jeśli ktoś przestawi breakpoint „bo ładniej”. Na stagingu testuj trzy szerokości, nie jedną.

Stany hover / focus / active przycisków

Button block dostaje osobne style interakcji w panelu. Dobre dla a11y (focus widać), złe jeśli motywy i pluginowe przyciski nagle zaczynają się gryźć. Sprawdź CTA, checkout i formularze — to pierwsze miejsca, w których „lekka zmiana w core” wychodzi na produkcji.

Nowy edytor mediów i przetwarzanie po stronie przeglądarki

Inline crop zastąpił modal: freeform i aspect-ratio crop, flip, rotacja, metadane. Kompresja, resize i miniatury mogą iść w przeglądarce — mniej timeoutów PHP i mniej „Allowed memory size exhausted” przy HEIC z iPhone’a.

7.1 dokłada natywne AVIF, HEIC i HDR gain map. Hosting z agresywnym Imagick/Ghostscript i tak wymaga uwagi — patrz 7.0.4 poniżej.

Notes: @wzmianki, rich text, zaznaczenie

Notes z 6.9/7.0 stają się narzędziem recenzji: formatowanie, linki, @mention z mailem, notatka na fragmencie tekstu, kilka wątków na jednym bloku. Na stronie firmowej z kilkoma redaktorami to realna zmiana workflow. Na one-pagerze z jednym adminem — szum.

Admin bar w każdym edytorze

Pasek zostaje widoczny w post editorze i Site Editorze. Drobiazg, który psuje custom CSS „ukryj admin-bar na /wp-admin”. Jeśli kiedyś go chowaliście, 7.1 to wyłapie.

Nowe bloki: Tabs, Playlist, ikony

Tabs i Playlist są w core. SVG Icon API jest publiczne: wp_register_icon_collection(), wp_register_icon(). Zanim wrzucisz trzeci plugin do zakładek, sprawdź, czy Tabs w core wystarczy — mniej zależności, mniej wektora ataku.

Różnice względem WordPress 7.0

7.0 to była duża zmiana platformy (FSE, collaborative editing, design tokens). 7.1 to warstwa operatorska: jak to stylujesz, jak recenzujesz, jak wrzucasz media. Developerowo istotne jest coś innego: post editor jest w pełni w iframe — także przy legacy meta boxach. Plugin, który sięgał po document edytora albo wstrzykiwał CSS do admina „na pałę”, może przestać działać.

CSS bloków bywa emitowany tylko gdy blok jest na stronie (komentarze w Field Guide). Headless / remote content, które zakładało globalny enqueue Cover Block CSS, może dostać „goły” HTML. Jeśli serwujesz WP jako CMS do Next.js, to sprawdzasz na stagingu, nie w changelogu.

Bezpieczeństwo: 7.0.2, 7.0.3, 7.0.4

Zanim ktokolwiek pyta „czy 7.1 jest stabilny”, pytanie brzmi: czy core jest załatany. Lato 2026 nie było spokojne.

7.0.2 (lipiec): łańcuch SQL injection + pomyłka routingu REST batch → RCE bez logowania na 6.9–7.0.1 (CVE-2026-60137, CVE-2026-63030). WordPress.org włączył wymuszone auto-update. Backport: 6.9.5, 6.8.6 (tylko SQLi).
7.0.3 (sierpień): m.in. pre-auth XSS na ekranie logowania z potencjałem na wykonanie PHP, plus zestaw XSS/SSRF/omijania filtrów. Łatki poszły też do 7.1 RC2.
7.0.4: authenticated Author+ RCE przez złośliwy upload przy Imagick + Ghostscript (CVE-2026-65640). Backport m.in. do 7.1 RC3.

7.1 zawiera te poprawki. Zostawanie na 7.0.0 „bo plugin X nie lubi minorów” w sierpniu 2026 to decyzja ryzyka, nie ostrożność. Szerszy kontekst: checklista zabezpieczenia WordPress i audyt bezpieczeństwa.

Przygotowanie strony do aktualizacji

Nie aktualizujesz „rdzenia” w izolacji. Kolejność, której trzymam się na produkcyjnych WP:

Inwentaryzacja: PHP (minimum zgodne z 7.1), limit pamięci, lista pluginów i motywów z datą ostatniej aktualizacji, custom mu-plugins, must-use, drop-iny.
Czytasz Field Guide pod kątem iframe edytora, Abilities API i theme.json — nie całego Gutenberg changelogu.
Staging z kopią bazy i plików, nie „prawie jak produkcja”.
Backup, który umiesz przywrócić — patrz backup WordPress. Pliki + baza + off-site. Test restore na osobnym URL.
Aktualizacja pluginów i motywu na stagingu przed core, potem core do 7.1, potem smoke test.

Pluginy i motyw

Największe ryzyko: edytor (ACF, klasyczne meta boxy, page buildery), media (optymalizatory, CDN, watermark), security (WAF, 2FA, hide login), cache. Page builder, który ładuje style do okna edytora, to pierwszy kandydat do rozjazdu po iframe.

Motyw klasyczny + FSE: 7.1 nie wymaga migracji na bloki. Wymaga, żeby child theme nie zakładał, że admin bar znika i że crop działa po staremu.

Kolejność na stagingu (WP-CLI)

wp db export /backups/pre-71-$(date +%F).sql
wp plugin update --all
wp theme update --all
wp core update --version=7.1
wp core verify-checksums
wp cache flush
wp rewrite flush

Potem ręcznie: logowanie, edycja strony z ACF, upload HEIC, checkout jeśli Woo. Jeśli coś pada, restore SQL + plików, nie „naprawimy na produkcji”. Breakpointy motywu blokowego w 7.1 wyglądają mniej więcej tak — sprawdź, czy child theme nie nadpisuje ich w ciemno:

{
  "settings": {
    "custom": {
      "breakpoints": {
        "mobile": "480px",
        "tablet": "782px"
      }
    }
  }
}

Abilities API (rozszerzenie z 6.9) w 7.1 dostaje filtry cyklu wykonania i flagę publicznego exposure. Jeśli stawiasz wtyczki „AI do wp-admin”, czytasz te notatki z Field Guide zanim wystawisz ability na REST.

Co testować po aktualizacji

Logowanie, 2FA, reset hasła (XSS na loginie w 7.0.3 nie był teoretyczny).
Edycja wpisu i strony: meta boxy, ACF, podgląd, Notes jeśli zespół ich używa.
Upload HEIC/JPEG, regeneracja miniaturek, CDN.
Front: menu, formularze, WooCommerce checkout, cache (purge).
REST i GraphQL, jeśli to headless — Next.js + headless WordPress.
Responsywność trzech breakpointów na stronie z nowymi stylami.

Kiedy aktualizować od razu

Jesteś na 7.0.0–7.0.3 — najpierw 7.0.4 albo od razu 7.1, byle nie zostać na dziurawym core.
Staging przeszedł edytor, checkout i upload.
Nie masz custom JS wpinanego w dokument edytora.
Masz backup i okno rollback (hosting albo WP-CLI + snapshot).

Kiedy warto poczekać kilka dni

Własne bloki / plugin edytora, który manipuluje DOM poza iframe.
WooCommerce z checkoutem mocno zmodyfikowanym — poczekaj na potwierdzenie kompatybilności od vendorów, ale security core i tak łataj.
Headless, który zaciąga HTML i zakłada globalny CSS bloków.
Brak stagingu. Wtedy nie „czekasz na 7.1.1” — stawiasz staging.

Czekanie bez łatki security to nie strategia. Czekanie z 7.0.4 na 7.1, żeby vendor ACF/builder wydał fix do iframe — jak najbardziej.

FAQ

Czy 7.1 wymaga PHP 8.3?

Trzymaj się macierzy na wordpress.org dla 7.1. Nie zgaduj po forach. Na produkcji nie idź poniżej tego, co core oficjalnie wspiera — stare PHP to osobny wektor, nie „oszczędność”.

Czy auto-update core jest OK?

Dla security minors — tak, jeśli umiesz rollback. Dla 7.0 → 7.1 na sklepie z custom checkoutem — nie. Rozdziel minor security od major/minor z edytorem.

Czy Tabs w core zastępuje plugin do zakładek?

Na prostych landingu tak. Na złożonym accordion/SEO markup — zmierz, zanim wyrzucisz plugin. Mniej pluginów to mniej powierzchni ataku, nie religia.

Podsumowanie

WordPress 7.1 warto wziąć, bo zamyka lato pełne łat security i daje narzędzia (responsive styles, media, Notes), których redakcja realnie użyje. Aktualizujesz przez staging, backup i test edytora — nie przez „Update Now” na produkcji w piątek. Jeśli trzymasz WP tylko jako CMS pod Next.js, 7.1 nadal dotyczy Cię przez REST/GraphQL, iframe i CSS bloków. Reszta to proces, nie wersja.