Jak naprawić nieładujący się edytor bloków WordPress

W większości przypadków edytor bloków WordPress, który się nie ładuje, to błąd JavaScriptu — jeden uszkodzony skrypt z wtyczki lub szablonu zatrzymuje całą aplikację React, a edytor nigdy nie kończy renderowania. Otwórz konsolę deweloperską przeglądarki (F12 lub Cmd+Option+I na Macu), przeładuj ekran edycji i przeczytaj czerwony błąd. Prawie zawsze wskazuje on plik, który rzucił wyjątek. Ta jedna linijka mówi ci, którą wtyczkę wyłączyć, i zwykle możesz wrócić do pisania w niecałe pięć minut. Ponowna instalacja WordPressa, podniesienie limitu pamięci PHP i przełączenie się na klasyczny edytor to trzy najczęstsze porady w internecie — i wszystkie trzy zwykle są błędem.

Dlaczego edytor psuje się właśnie tak

Edytor bloków (Gutenberg) to jednostronicowa aplikacja React, która działa wewnątrz wp-admin/post.php oraz post-new.php. WordPress ładuje stos pakietów skryptów — wp-blocks, wp-element, wp-editor, wp-edit-post — a aplikacja startuje przez wp.domReady(). JavaScript przestaje się wykonywać przy pierwszym nieprzechwyconym wyjątku. Więc jeśli którykolwiek załadowany skrypt rzuci wyjątek podczas inicjalizacji edytora, wszystko po nim umiera razem z nim. Twoje starannie napisane pole wpisu zamienia się w pusty biały panel albo w komunikat „Edytor napotkał nieoczekiwany błąd”.

Domyślnie WordPress łączy też skrypty administracyjne w mniejszą liczbę żądań. To oznacza, że uszkodzony JS jednej wtyczki może pociągnąć za sobą niepowiązane skrypty załadowane w tym samym pakiecie — dlatego winowajca nie zawsze jest oczywisty na podstawie samego zachowania. Konsola już tak.

Drugi rodzaj awarii wygląda inaczej: edytor się ładuje, ale zapisywanie rzuca błąd „Aktualizacja nie powiodła się. Odpowiedź nie jest prawidłową odpowiedzią JSON”. To nie jest problem JavaScriptu. Edytor komunikuje się z REST API pod adresem /wp-json/wp/v2/ i oczekuje w odpowiedzi czystego JSON-a. Jeśli wtyczka albo functions.php twojego szablonu wypisze notice, ostrzeżenie lub błąd krytyczny PHP przed JSON-em — albo jeśli wtyczka zabezpieczająca zablokuje trasę REST, albo wtyczka przekierowań przepisze URL — odpowiedź jest zanieczyszczona i edytor nie potrafi jej sparsować.

Jak to naprawić, od najszybszego

1. Przeczytaj konsolę. Odtwórz awarię z otwartymi narzędziami deweloperskimi. Błąd w rodzaju Uncaught TypeError ... some-plugin/build/index.js wskazuje prosto na winną wtyczkę. Ten jeden krok rozwiązuje większość przypadków i oszczędza ci ślepego przeszukiwania metodą połowienia.

2. Wyklucz przeglądarkę. Wykonaj twarde odświeżenie (Cmd/Ctrl+Shift+R), a potem spróbuj w oknie incognito z wyłączonymi rozszerzeniami. Blokery reklam i rozszerzenia chroniące prywatność czasami wycinają skrypty administracyjne. Jeśli w trybie incognito działa, problemem jest rozszerzenie przeglądarki albo nieaktualna pamięć podręczna, a nie twoja witryna.

3. Sprawdź REST API bezpośrednio, jeśli widziałeś komunikat „nie jest prawidłową odpowiedzią JSON”. Wejdź na https://twojawitryna.com/wp-json/ w przeglądarce. Powinieneś zobaczyć ścianę JSON-a. Jeśli dostajesz HTML, błąd 500 albo przekierowanie do logowania, to jest twój błąd — jakaś wtyczka psuje odpowiedź REST, a nie sam edytor.

4. Przeszukaj wtyczki metodą połowienia. Wyłącz wszystkie, potwierdź, że edytor się ładuje, a potem włączaj po jednej, aż znów się zepsuje. Jeśli jesteś całkowicie zablokowany w wp-admin, zrób to przez SFTP, zmieniając nazwę folderu:

mv wp-content/plugins wp-content/plugins_off

WordPress wyłącza wszystko, gdy folder znika. Zmień nazwę z powrotem, a potem przenoś wtyczki pojedynczo.

5. Przetestuj szablon. Przełącz się na Twenty Twenty-Four. Szablon, który ładuje uszkodzony JS edytora albo rzuca błędy PHP w functions.php, daje te same objawy.

6. Włącz dziennik i przeczytaj prawdziwy błąd. Zwłaszcza przy awariach REST/JSON włącz debugowanie w wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Błąd krytyczny zostanie zapisany w wp-content/debug.log wraz z dokładną nazwą pliku i numerem linii. Jeśli ten ślad stosu jest gęsty — nazwy klas z przestrzeniami nazw, łańcuchy require, błąd krytyczny ukryty pod dziesięcioma liniami śladu — wklej go do naszego dekodera dziennika błędów WordPress, żeby zobaczyć w prostych słowach, która wtyczka i linia faktycznie go wywołały. To różnica między „coś jest zepsute” a „linia 214 tej konkretnej wtyczki jest zepsuta”.

Jeśli podejrzewasz, że łączenie skryptów maskuje prawdziwego winowajcę, wymuś ładowanie każdego skryptu osobno, żeby błąd w konsoli wskazywał dokładnie jeden plik:

define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );

Czego nie robić

Nie instaluj wtyczki Classic Editor i nie uznawaj tego za rozwiązanie. Ona niczego nie naprawia — ukrywa edytor bloków, żebyś przestał widzieć błąd. Uszkodzony JavaScript albo zepsuta odpowiedź REST nadal tam są i znów cię ugryzą w edytorze witryny, w widżetach albo przy następnej aktualizacji. Najpierw zdiagnozuj; wróć do klasycznego edytora tylko wtedy, gdy świadomie zdecydowałeś się przestać używać bloków.

Nie podnoś limitu pamięci PHP odruchowo. To ulubiona kopiuj-wklej poprawka internetu, ale pusty edytor rzadko wynika z wyczerpania pamięci. Prawdziwe wyczerpanie rzuca konkretny błąd krytyczny — „Allowed memory size of N bytes exhausted” — który zobaczysz w debug.log. Jeśli tej linii tam nie ma, więcej pamięci niczego nie zmieni.

Nie instaluj ponownie rdzenia WordPressa. Pliki rdzenia są bajt w bajt identyczne na każdej instalacji. Gdyby to rdzeń był problemem, każda witryna WordPress na świecie miałaby teraz zepsuty edytor. Wina prawie zawsze leży w twoich wtyczkach albo szablonie, a ponowna instalacja rdzenia grozi nadpisaniem różnych rzeczy, niczego przy tym nie naprawiając.

Nie czyść ani nie wyłączaj na ślepo wtyczki pamięci podręcznej jako pierwszego kroku. Agresywna minifikacja i łączenie JS-a mogą zepsuć edytor, więc warto to przetestować — ale zajrzyj do konsoli, zanim zaczniesz czyścić pamięć podręczną na oślep. Zgadywanie to sposób, w jaki pięciominutowa naprawa zamienia się w stracone popołudnie.

Nadal utknąłeś?

Jeśli konsola jest czysta, REST API zwraca prawidłowy JSON, a pełne przeszukanie wtyczek i szablonu metodą połowienia nadal zostawia martwy edytor, odpowiedź prawie zawsze siedzi w debug.log. Włącz WP_DEBUG_LOG, odtwórz awarię raz i przepuść powstały błąd krytyczny przez dekoder dziennika błędów. Ślad stosu wskazuje plik — zacznij od niego.