WordPress 7.0 wchodzi 20 maja. Co naprawdę się zmienia i co zepsuje twoją stronę

TL;DR

WordPress 7.0 wchodzi 20 maja 2026. Trzy rzeczy, które muszą Cię obchodzić jako administratora. Po pierwsze, minimalna wersja PHP to 8.3, więc jeśli Twój hosting siedzi na 8.1 albo 8.2, aktualizacja core się nie wykona. Po drugie, nowy Web Client AI API daje wtyczkom jeden natywny interfejs do OpenAI, Anthropic i Gemini, więc autorzy wtyczek przestaną dorzucać własne SDK i klucze API w polach options. Po trzecie, można teraz zarejestrować blok wyłącznie po stronie PHP, bez block.json i bez JS-a. Real-Time Collaboration, którego oczekiwano w 7.0, wypadło z roadmapy i pojawi się dopiero w 7.1. Reszta tekstu to konkretna procedura aktualizacji, lista wtyczek do przetestowania na stagingu i plan rollbacku na wypadek, gdy coś pójdzie nie tak.

PHP 8.3 jest wymagany. Jak sprawdzić i podbić

Najszybszy test, robisz to przez SSH, jedno polecenie.

ssh user@twojadomena.pl 'php -v'

Jeśli zobaczysz PHP 8.3.x, jesteś w domu. Jeśli zobaczysz PHP 8.2.x lub starsze, WP-CLI odmówi aktualizacji core do 7.0 z komunikatem Your server is running PHP version 8.2.x but WordPress 7.0 requires at least 8.3. Klasyczne wp core update w takiej sytuacji nie zrobi nic poza wypisaniem błędu.

Na hostingu mDiv przełączasz wersję PHP w panelu, sekcja Witryny -> [domena] -> PHP, dropdown z dostępnymi wersjami. Po zmianie czekasz 30 sekund, ponownie odpalasz php -v i sprawdzasz, czy faktycznie wskoczyła 8.3. Jeśli nie, restart php-fpm leci automatycznie po zmianie w panelu, więc to kwestia maksymalnie minuty.

Zanim podbijesz PHP na produkcji, zrób listę wtyczek z deprecation warnings na obecnym 8.2.

wp plugin list --status=active --format=csv > active-plugins.csv
wp plugin deactivate --all
wp plugin activate --all 2>&1 | tee deprecation.log
grep -i "deprecated\|warning" deprecation.log

Jeśli widzisz tam wtyczki z Deprecated: Creation of dynamic property albo Deprecated: Return type of, to są kandydaci do problemów na 8.3. Najczęściej winowajcy to stare wtyczki cargo-cult skopiowane z forów sprzed pięciu lat, których autorzy dawno przestali łatać. Zanim pójdziesz dalej, sprawdź czy mają aktualizację. Jeśli nie mają i ostatni commit ma 3 lata, masz decyzję do podjęcia, czy wtyczka jest na tyle ważna, żeby ją łatać własnoręcznie, czy lepiej znaleźć następcę.

Web Client AI API. Co to jest i kiedy się przyda

W 7.0 do core trafia WP_AI_Client. To nie jest model AI w WordPressie. To cienka warstwa abstrakcji nad OpenAI, Anthropic i Gemini, która ujednolica wywołanie, autoryzację i format odpowiedzi. Klucze API trzymasz w Ustawienia -> AI providers raz, na poziomie strony. Każda wtyczka, która chce z tego korzystać, robi to przez wspólny endpoint, bez własnego SDK i bez wbudowywania klucza w pole opcji.

Dlaczego to ma znaczenie. Do tej pory, jeśli miałeś trzy wtyczki AI (SEO, generator opisów produktów, asystent w edytorze), to każda miała własny formularz na klucz OpenAI, każda potencjalnie inną wersję modelu i każdą musiałeś osobno konfigurować. Po 7.0 wszystkie te wtyczki, jeśli autor zrobi swoje, czytają klucz z jednego miejsca.

Przykład wywołania z poziomu wtyczki, dosłownie 15 linii.

<?php
add_action('wp_insert_post', function ($post_id, $post) {
    if ($post->post_status !== 'publish' || $post->post_type !== 'post') {
        return;
    }
    if (get_post_meta($post_id, '_meta_description', true)) {
        return;
    }
    $client = WP_AI_Client::get('openai');
    $response = $client->chat([
        'model'    => 'gpt-4.1-mini',
        'messages' => [
            ['role' => 'system', 'content' => 'Generuj meta description po polsku, do 155 znaków, bez cudzysłowów.'],
            ['role' => 'user',   'content' => wp_strip_all_tags($post->post_content)],
        ],
    ]);
    update_post_meta($post_id, '_meta_description', $response->text());
}, 10, 2);

To realny use case, automatyczne meta description przy publikacji. W 6.x ten sam kod wymagałby zaciągnięcia biblioteki przez Composer, własnej obsługi błędów HTTP i własnego cache. W 7.0 WP_AI_Client ma wbudowany rate-limit, retry z backoffem i opcjonalny cache odpowiedzi w wp_options.

Kiedy się przyda. Przy generowaniu alt-tekstów do obrazków, przy podpowiadaniu kategorii dla wpisu, przy automatycznym tworzeniu skrótu dla newslettera. Wszędzie tam, gdzie do tej pory płaciłeś za płatną wtyczkę robiącą cienką nakładkę na OpenAI API.

PHP-only block registration. Mniej JS, więcej PHP

W 6.x rejestracja własnego bloku Gutenberga zawsze wymagała JS-a. Plik block.json, plik index.js, build przez @wordpress/scripts, wpis w enqueue_block_editor_assets. Dla bloku, który pokazuje cytat z autorem, to było pięć plików i konfiguracja webpacka.

W 7.0 da się tak.

<?php
// Wersja PHP-only, działa po 7.0
register_block_type('mdiv/quote-author', [
    'title'           => 'Cytat z autorem',
    'category'        => 'text',
    'icon'            => 'format-quote',
    'attributes'      => [
        'quote'  => ['type' => 'string', 'default' => ''],
        'author' => ['type' => 'string', 'default' => ''],
    ],
    'render_callback' => function ($attrs) {
        return sprintf(
            '<blockquote class="mdiv-quote"><p>%s</p><cite>%s</cite></blockquote>',
            esc_html($attrs['quote']),
            esc_html($attrs['author'])
        );
    },
    'editor_fields'   => [
        'quote'  => ['type' => 'textarea', 'label' => 'Treść cytatu'],
        'author' => ['type' => 'text', 'label' => 'Autor'],
    ],
]);

Diff w stosunku do 6.x. Wcześniej musiałeś napisać też po stronie JS funkcję edit, save i zarejestrować przez wp.blocks.registerBlockType. Teraz editor_fields mówi Gutenbergowi, jakie pola wyrenderować w prawym panelu edytora, a render_callback rysuje frontend. Dla bloków typu form, FAQ, pull-quote, listy linków, to oszczędność godzin. Kiedy ma sens. Wszędzie tam, gdzie blok nie potrzebuje własnego UI w edytorze, tylko paru pól i renderu po stronie serwera. Kiedy NIE ma sensu. Jeśli budujesz coś interaktywnego, z drag-and-drop, z podglądem na żywo skomplikowanej struktury, dalej potrzebujesz JS-a. Ten API to nie zastępstwo dla pełnego SDK, to skrót dla 80% przypadków.

Co NIE wejdzie do 7.0. Real-Time Collaboration odpadło

W styczniu 2026 Matt Mullenweg pisał na State of the Word, że Real-Time Collaboration jest flagową funkcją 7.0. W kwietniu, po RC2, feature trafił na półkę do 7.1. Powód, który widać w issue trackerze, to dwa problemy.

Po pierwsze, race conditions przy jednoczesnej edycji bloku przez dwóch userów, jeden zaczyna pisać w paragrafie, drugi go usuwa, frontend rozjeżdża się o trzy linie. CRDT, który Gutenberg używał (Yjs), działa świetnie dla tekstu liniowego, ale Gutenberg trzyma drzewo bloków z atrybutami, a tu konflikty są trudniejsze do rozwiązania automatycznie.

Po drugie, zużycie pamięci. Cztery osoby edytujące jeden post jednocześnie potrafiły położyć stronę z domyślnym limitem 256MB PHP. W stagingu Automattic doszli do tego, że na produkcyjnym foliopaczku wymagałoby to 512MB. Dla siteów na shared hostingu to nie wchodzi w grę.

ETA na 7.1 to listopad 2026. Jeśli Twój klient kupował WordPressa pod „edycja w czasie rzeczywistym", musisz go uprzedzić, że nie wchodzi 20 maja. Workaround na pół roku to wtyczki Multicollab albo Frontkom Yoast Collab, które robią to po swojemu i działają już teraz.

Procedura aktualizacji dla strony produkcyjnej

Kolejność. Najpierw PHP, potem wtyczki, na końcu core. Nigdy odwrotnie.

Krok 1. Staging. Sklonuj produkcję do osobnego subdomeny, np. staging.twojadomena.pl. Na mDiv robi to jeden klik w panelu, na innych hostingach wp-cli + wp db export + rsync. Sprawdź, że staging odpala, że logowanie działa, że strony się renderują.

Krok 2. Snapshot bazy.

wp db export backup-before-7.0-$(date +%F).sql

Trzymaj to w katalogu poza public_html. Jeśli coś pójdzie nie tak, to ten plik Cię ratuje.

Krok 3. Snapshot plików.

tar czf wp-content-before-7.0-$(date +%F).tar.gz wp-content/

Krok 4. Podbij PHP na 8.3 (najpierw na stagingu). Sprawdź, czy strona dalej działa, czy w error_log nie wyskakują nowe fatal errors. Daj 24h obserwacji.

Krok 5. Wtyczki. Zaktualizuj wszystkie do najnowszych wersji jeszcze przed aktualizacją core.

wp plugin update --all

Po każdej aktualizacji rzucasz okiem na frontend i error_log.

Krok 6. Core.

wp core check-update --version=7.0
wp core update --version=7.0
wp core update-db

update-db jest istotny. Po major update WordPress migruje strukturę tabel i dopóki tego nie zrobisz, niektóre wtyczki mogą rzucać błędy SQL.

Krok 7. Walidacja. Sprawdź:

• frontend strony głównej i 3 podstron,
• logowanie do wp-admin,
• formularze kontaktowe (najczęstsza ofiara aktualizacji),
• WooCommerce checkout, jeśli masz sklep,
• crony (wp cron event list).

Plan rollbacku, jeśli po godzinie widzisz, że coś nie działa.

# Cofnij core
wp core update --version=6.8.2 --force

# Przywróć bazę
wp db import backup-before-7.0-2026-05-19.sql

# Przywróć wp-content
tar xzf wp-content-before-7.0-2026-05-19.tar.gz

# Cofnij PHP w panelu z 8.3 na 8.2

Cały rollback zajmuje 5 minut, jeśli masz pliki pod ręką. To dlatego snapshot przed aktualizacją to nie jest opcja, tylko warunek wstępny.

Profilaktyka, żeby kolejne wersje nie aktualizowały się same w nieodpowiednim momencie. W wp-config.php dodaj.

define('WP_AUTO_UPDATE_CORE', 'minor');

To pozwala WP samodzielnie łatać 7.0.1, 7.0.2, ale 7.1 poczeka na Twoją decyzję.

Co zepsuje aktualizacja

Pięć kategorii wtyczek, które najczęściej rozjeżdżają się przy major updates. Sprawdź każdą z nich na stagingu, zanim ruszysz produkcję.

Page buildery, czyli Elementor, Beaver Builder, Bricks. Page buildery robią własne hooki w renderingu treści. Jeśli WordPress zmienia the_content filter chain (a w 7.0 zmienia, przez nowy blok content rendering), buildery potrafią pokazać pusty edytor albo zdublować treść. Test, otwórz dowolną stronę zbudowaną w builderze, sprawdź czy widać wszystkie sekcje. Otwórz tę samą stronę w edytorze, sprawdź czy widać wszystkie widgety.

Cache plugins, WP Rocket, W3 Total Cache, LiteSpeed Cache. Po każdym major update wyczyść cache, zarówno wtyczki, jak i hosting-level (OPcache, object cache). Najczęstszy objaw nie wyczyszczenia, frontend pokazuje stary HTML z deprecated funkcji, mimo że core już jest na 7.0. WP Rocket ma znany problem z minifikacją po major updates, jeśli widzisz, że CSS pojechał, wyłącz minifikację i włącz ponownie po godzinie.

Wtyczki bezpieczeństwa, Wordfence, Sucuri, iThemes Security. Wordfence ma własną listę reguł WAF dopasowaną do konkretnej wersji core. Po aktualizacji firma musi wypchnąć update reguł, najczęściej dzieje się to w ciągu doby. W tym czasie możesz zobaczyć false positives, np. blokady legalnego ruchu admina. Trzymaj IP swojego admina w whitelist Wordfence przed aktualizacją.

Formularze, Contact Form 7, WPForms, Gravity Forms. Najmniej oczywista kategoria, ale najczęściej psuta. Powód, formularze często używają wp_mail() z bardzo specyficznym workflowem, a w 7.0 zmienił się sposób, w jaki core obsługuje wp_mail z HTML body. Test, wyślij testowy mail z każdego formularza i sprawdź czy doszedł.

Translation plugins, WPML, Polylang. Te wtyczki głęboko ingerują w WP_Query, w router URL-i, w the_post. WPML w wersjach przed 4.7 ma znany niezgodny patch z 7.0, jeśli jesteś na starszej wersji, zaktualizuj WPML PRZED aktualizacją core. Polylang ma to ogarnięte od marca, ale i tak przetestuj przełączanie między językami.

Jak czytać error_log

Po aktualizacji pierwsze miejsce, gdzie patrzysz, to wp-content/debug.log (jeśli masz włączone WP_DEBUG_LOG) albo log PHP od hostera, najczęściej ~/logs/error.log. Włącz debugowanie tymczasowo na stagingu.

// wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Co szukać.

• Fatal error to natychmiastowy stop, strona nie działa, trzeba reagować.
• Uncaught Error to ekran śmierci, najczęściej z konkretnym plikiem i linią, dający Ci dokładną wtyczkę do wyłączenia.
• Deprecated w PHP 8.3 nie zatrzymuje strony, ale jeśli widzisz ich kilkaset na minutę, to znak, że wtyczka się rozjeżdża i wkrótce wypadnie z gry.

Jak zidentyfikować wtyczkę powodującą fatal error, gdy strona już padła i wp-admin nie wchodzi.

# Zmień nazwę katalogu plugins, WordPress wyłączy wszystkie
mv wp-content/plugins wp-content/plugins.off
# Sprawdź czy wp-admin wszedł
mv wp-content/plugins.off wp-content/plugins
# Włączaj jedna po drugiej
wp plugin activate {nazwa}

Klasyczny binary search, w 5-7 krokach masz winowajcę.

Źródła oficjalne

• WordPress 7.0 Field Guide, pełna lista breaking changes, deprecations i nowych API.
• Release Candidate 4 announcement, oficjalne RC z listą zmian względem RC3.
• PHP 8.3 release notes, żeby wiedzieć, co konkretnie wymusza WordPress.

Co możesz zrobić w pakiecie opieki mDiv

Aktualizacja major core to nie kliknięcie „update now" w panelu. To staging, snapshot, kolejność operacji, plan rollbacku, testy frontu i checkout. Jeśli prowadzisz stronę, na której godzina downtime'u to realny koszt, to nie jest praca dla niedzielnego popołudnia.

W pakietach Pro i Premium opieki nad stroną aktualizacje major (jak właśnie 7.0) wykonujemy zgodnie z procedurą opisaną wyżej, w oknie nocnym, z pełnym rollback planem. Klient dostaje raport, co zostało zaktualizowane, co przetestowane i co dalej wymaga uwagi.

Jeśli Twoja strona siedzi na PHP 8.1 albo 8.2 i nie wiesz, czy przeżyje 20 maja, napisz do nas albo wyceń przeniesienie na hosting z PHP 8.3 i automatyzacją aktualizacji.