Wyobraźcie sobie: kończą Państwo pisać post, klikają „Opublikuj", a WordPress wyświetla czerwony komunikat z błędem. Odświeżyć stronę? Ten sam błąd. Ponownie zalogować się do panelu administracyjnego? Bez zmian. Post wisi w wersjach roboczych, a czas nagli.

Błąd aktualizacji (Updating Failed) lub publikacji (Publishing Failed) to jeden z tych problemów, które wprawiają w zakłopotanie: komunikat nie mówi, co dokładnie się zepsuło. Jednak przez lata pracy z WordPressem wypracowaliśmy jasną sekwencję diagnostyczną. W większości przypadków przyczyna leży na wierzchu, a naprawa zajmuje kilka minut.

W tym materiale przedstawiamy 7 sprawdzonych sposobów: od najprostszych (internet i adres URL witryny) po precyzyjne debugowanie przez wp-config i pracę z wtyczkami. Każdy krok zawiera konkretne działania i zrzuty ekranu z panelu administracyjnego.

💡 Szybki przegląd:

• Sprawdzić połączenie internetowe i adres URL witryny w ustawieniach
• Otworzyć „Narzędzia → Stan witryny" i sprawdzić status REST API
• Włączyć tryb debugowania przez WP_DEBUG w pliku wp-config.php
• Usunąć tymczasowy plik .maintenance z serwera przez FTP
• Dezaktywować wszystkie wtyczki jednocześnie i włączać pojedynczo, aby wykryć konflikt
• Tymczasowo zastąpić Gutenberg Classic Editorem, aby wykluczyć konflikt z edytorem blokowym
• Jeśli nic nie zadziałało, zwrócić się do dostawcy hostingu lub społeczności WordPressa

1. Proszę sprawdzić połączenie internetowe i adres URL witryny

Najprostsza, a przez to często pomijana przyczyna: WordPress traci połączenie z serwerem w trakcie zapytania.

Proszę otworzyć sąsiednią kartę przeglądarki i wejść na dowolną stronę. Strona się załadowała? Internet działa. Jeśli nie, proszę przywrócić połączenie i spróbować opublikować post ponownie.

Jeśli internet działa prawidłowo, kolejnym podejrzanym są ustawienia adresu URL. Przez lata migracji, zmian domen i eksperymentów z HTTPS adresy w „Ustawienia → Ogólne" czasami rozmijają się z rzeczywistością. Proszę tam przejść i zweryfikować dwa pola: Adres WordPress (URL) i Adres witryny (URL). Muszą one być zgodne z faktycznym adresem, pod którym logują się Państwo do panelu administracyjnego.

Jeśli oba adresy są prawidłowe, a błąd nie znika, przechodzimy głębiej.

2. Proszę sprawdzić status REST API

WordPress REST API to mechanizm, za pomocą którego edytor Gutenberg komunikuje się z serwerem. Gdy REST API nie odpowiada lub zwraca błąd, przycisk „Opublikuj" przestaje działać.

Na szczęście w WordPressie 5.2 i nowszych dostępne jest wbudowane narzędzie diagnostyczne. Proszę wejść w Narzędzia → Stan witryny (Site Health). Proszę przewinąć do sekcji „Zalecane ulepszenia" i znaleźć wiersz „The REST API encountered an unexpected result" lub podobny błąd.

Jeśli REST API pokazuje błąd, proszę rozwinąć informacje debugowania w tym samym miejscu, na karcie „Informacje" → „REST API". Zobaczą tam Państwo konkretne wywołanie, które się nie powiodło, oraz kod odpowiedzi serwera. Najczęściej problem leży w:

• Wtyczce bezpieczeństwa blokującej zapytania REST (Wordfence, iThemes/Solid Security z agresywnymi ustawieniami firewalla);
• Niestandardowym kodzie w functions.php, który przypadkowo psuje endpointy REST;
• Wtyczce cache'ującej, która zwraca zcache'owaną odpowiedź REST API.

Proszę wyłączyć podejrzaną wtyczkę i sprawdzić stan REST API na tej samej stronie.

3. Proszę włączyć tryb debugowania WordPressa

Gdy problem nie leży na powierzchni, trzeba go „podświetlić", do tego w WordPressie przewidziano wbudowany tryb debugowania.

Będą Państwo potrzebować dostępu do plików witryny. Wystarczy klient FTP (FileZilla, WinSCP) lub menedżer plików w panelu hostingu. Przed jakimikolwiek zmianami w plikach proszę wykonać kopię zapasową. Błąd w pliku wp-config.php może położyć witrynę, a kopia zapasowa przywróci wszystko w minutę.

Kolejność działań:

• Proszę połączyć się z serwerem przez FTP, znaleźć główny folder WordPressa (tam, gdzie znajdują się wp-content, wp-admin i wp-includes).
• Proszę znaleźć plik wp-config.php i pobrać go na komputer.
• Proszę otworzyć plik w edytorze tekstowym (Notepad++, Sublime Text, nie Word ani Notatnik, które psują kodowanie).
• Na samym dole, przed linią /* That's all, stop editing! Happy publishing. */, proszę dodać:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

Pierwsza linia włącza debugowanie, druga zapisuje błędy do pliku wp-content/debug.log (nie pokazując ich odwiedzającym), trzecia ukrywa błędy z ekranu witryny.

Proszę zapisać plik i wgrać go z powrotem na serwer z zastąpieniem. Teraz proszę spróbować opublikować post. Jeśli błąd zniknął, przyczyną było ostrzeżenie PHP, które zagłuszało odpowiedź REST. Proszę otworzyć wp-content/debug.log przez ten sam FTP i znaleźć wpisy z PHP Notice lub PHP Warning, wskażą one winowajcę wśród wtyczek.

Po zakończeniu proszę koniecznie wyłączyć WP_DEBUG, zamieniając true na false, w przeciwnym razie plik debug.log będzie rósł w nieskończoność.

Jeśli błąd pozostał, idziemy dalej.

4. Proszę usunąć plik.maintenance

WordPress tworzy tymczasowy plik .maintenance w katalogu głównym witryny podczas aktualizacji rdzenia, wtyczek i motywów. Przełącza on witrynę w tryb konserwacji, odwiedzający widzą komunikat „Prace techniczne, proszę zajrzeć później".

Czasami aktualizacja kończy się, a plik .maintenance pozostaje. WordPress myśli, że konserwacja wciąż trwa i blokuje publikację.

Proszę ponownie otworzyć FTP, wejść do głównego folderu i znaleźć plik .maintenance (z kropką na początku, jest ukryty; w FileZilli proszę włączyć pokazywanie ukrytych plików przez „Serwer → Wymuś pokazywanie ukrytych plików").

Proszę usunąć .maintenance i natychmiast sprawdzić publikację, efekt utrzymuje się około 10 minut (WordPress odtworzy plik, jeśli aktualizacja jest nadal aktywna). Jeśli błąd zniknął, a po 10 minutach powrócił, oznacza to, że aktualizacja w tle wciąż wisi. Proszę zaczekać lub dokończyć ją przez „Wtyczki → Zainstalowane" (tam będzie status aktualizacji).

5. Proszę znaleźć konfliktującą wtyczkę

Najczęstsza przyczyna błędów publikacji to konflikt wtyczek. Jedna wtyczka psuje REST API, inna ingeruje w proces zapisywania, trzecia koliduje z Gutenbergiem.

Szybki sposób na znalezienie winowajcy to masowa dezaktywacja z sekwencyjnym włączaniem:

• Proszę przejść do Wtyczki → Zainstalowane wtyczki.
• Proszę zaznaczyć checkbox „Wtyczka" w nagłówku tabeli, wybrane zostaną wszystkie.
• Z listy rozwijanej „Działania" proszę wybrać „Dezaktywuj" i kliknąć „Zastosuj".

Teraz wszystkie wtyczki są wyłączone. Proszę spróbować opublikować post. Udało się? Świetnie, przyczyna leży w jednej z wtyczek. Proszę włączać je pojedynczo i po każdej sprawdzać publikację. Gdy tylko błąd powróci, znaleźli Państwo winowajcę.

Co zrobić z problematyczną wtyczką:

• Zaktualizować ją do najnowszej wersji (twórca mógł już naprawić błąd).
• Napisać do wsparcia technicznego wtyczki ze szczegółami: wersja WordPressa, wersja wtyczki, przy jakich działaniach występuje błąd.
• Tymczasowo zastąpić ją odpowiednikiem, dopóki twórca nie wyda poprawki.

6. Proszę tymczasowo zastąpić Gutenberg Classic Editorem

Edytor blokowy Gutenberg pojawił się w WordPressie 5.0 i od tego czasu przeszedł długą drogę. Jednak konflikty z poszczególnymi wtyczkami i motywami wciąż się zdarzają, szczególnie ze starymi page builderami (WPBakery, stare wersje Elementora) i wtyczkami, które nie są przystosowane do REST API.

Klasyczny edytor nie używa REST API do zapisywania, działa przez stary admin-ajax.php. Dlatego jego instalacja to szybki test: jeśli błąd znika, problem leży właśnie w połączeniu Gutenberg + jakaś wtyczka.

Proszę zainstalować Classic Editor, oficjalną wtyczkę od zespołu WordPressa:

• Wtyczki → Dodaj nową.
• W wyszukiwaniu proszę wpisać „Classic Editor".
• Proszę kliknąć „Zainstaluj", a następnie „Aktywuj".

Po aktywacji proszę spróbować opublikować post przez klasyczny edytor. Działa? Oznacza to konflikt po stronie Gutenberga.

Ważne: to krok diagnostyczny, a nie stałe rozwiązanie. Classic Editor wyłącza edytor blokowy, tracą Państwo wszystkie możliwości Gutenberga: bloki, szablony, wbudowane formatowanie. Gdy znajdą Państwo winowajcę wśród wtyczek (metodą z kroku 5), proszę usunąć Classic Editor i wrócić do Gutenberga już z naprawionym środowiskiem.

7. Proszę zwrócić się o pomoc

Jeśli przeszli Państwo wszystkie sześć kroków, a błąd nie znika, problem najprawdopodobniej leży głębiej: na poziomie serwera, hostingu lub rzadkiego błędu rdzenia WordPressa.

Oto gdzie się zwrócić, w kolejności skuteczności:

Dostawca hostingu. Proszę napisać do wsparcia technicznego ze szczegółami: wersja WordPressa, wersja PHP, które wtyczki są aktywne, przy jakim działaniu występuje błąd. Dostawca hostingu ma dostęp do logów serwerowych, często widzą przyczynę w minutę (skończyło się miejsce na dysku, moduł PHP jest wyłączony, limit pamięci).

Fora WordPressa. Oficjalne forum wsparcia WordPress.org to żywa społeczność, gdzie odpowiadają twórcy rdzenia i autorzy wtyczek. Proszę otworzyć wątek, dodać zrzuty ekranu i zawartość debug.log.

Po przeczytaniu tego materiału mają Państwo pełny łańcuch diagnostyczny: od kliknięcia myszą po edycję plików serwerowych. W 9 na 10 przypadków problem rozwiązuje się na krokach 1-5, bez FTP i wp-config.

Poniżej odpowiedzi na najczęstsze pytania oraz wideo dla utrwalenia materiału.

⁉️🤔 Często zadawane pytania

Dlaczego błąd pojawia się natychmiast po aktualizacji WordPressa?

Najprawdopodobniej jedna z wtyczek jest niekompatybilna z nową wersją rdzenia lub nową wersją PHP, którą hosting aktywował wraz z aktualizacją. Proszę przejść krok 5 (masowa dezaktywacja), szybko znajdą Państwo winowajcę.

Czy można po prostu przeinstalować WordPressa i nie rozkładać tego na czynniki pierwsze?

Ponowna instalacja rdzenia przez „Aktualizacje → Zainstaluj ponownie" jest bezpieczna i nie narusza treści ani wtyczek. Jeśli jednak błąd jest spowodowany konfliktem wtyczek, ponowna instalacja rdzenia nie pomoże. Lepiej poświęcić 5 minut na diagnostykę według powyższych kroków, niż na ślepo przeglądać rozwiązania.

Dlaczego błąd pojawia się tylko na jednym poście, a reszta publikuje się normalnie?

Prawdopodobna przyczyna leży w treści samego posta. Jakaś kombinacja bloków Gutenberga, wstawiony iframe lub skrypt powoduje awarię podczas zapisywania. Proszę spróbować skopiować treść do nowego posta i opublikować. Jeśli nowy post się publikuje, proszę usunąć stary i pracować z kopią.

Czy trzeba trzymać Classic Editor na stałe po naprawie?

Nie. Classic Editor to tymczasowe rozwiązanie diagnostyczne. Gdy tylko znajdą i naprawią Państwo konfliktującą wtyczkę, proszę usunąć Classic Editor i wrócić do Gutenberga. Edytor blokowy to standard WordPressa i nie warto z niego rezygnować bez poważnego powodu.

Co zrobić, jeśli nie ma dostępu do FTP?

Proszę użyć menedżera plików w panelu hostingu (cPanel → File Manager, ISPmanager → Pliki). Funkcjonalnie robi to samo. Jeśli i jego nie ma, proszę zwrócić się do wsparcia technicznego hostingu, pomogą z dostępem.

Który ze sposobów wypróbować jako pierwszy?

Uniwersalna formuła: proszę sprawdzić internet (10 sekund) → zajrzeć do Site Health (30 sekund) → masowo dezaktywować wtyczki (1 minuta). W większości przypadków na tym etapie problem jest już rozwiązany.

Jeśli błąd powraca po naprawie, oznacza to, że znaleziono nie przyczynę, a symptom. Proszę włączyć WP_DEBUG_LOG (krok 3) i zebrać pełny log, wskaże on dokładny plik i linię z błędem. Z tym logiem można udać się do wsparcia wtyczki lub na forum WordPressa.

I najważniejsze: proszę zawsze mieć świeżą kopię zapasową. Zmienia ona każdą awarię z katastrofy w pięciominutowe opóźnienie.