„Odpowiedź nie jest prawidłową odpowiedzią JSON”. Jak naprawić zapis w edytorze?

Wpis jest gotowy, wystarczy go zapisać, a edytor WordPressa wyświetla czerwony pasek: „Aktualizacja nie powiodła się. Odpowiedź nie jest prawidłową odpowiedzią JSON”. Przy nowym wpisie początek brzmi „Publikowanie nie powiodło się”, a ten sam tekst potrafi pojawić się także przy wgrywaniu obrazka. Strona dla odwiedzających działa normalnie, tylko zmian nie da się zachować.

Ten tekst jest instrukcją dla właścicieli firm i osób, które same prowadzą swoją stronę na WordPressie. Komunikat brzmi technicznie, ale w praktyce ma kilka powtarzalnych przyczyn i większość z nich da się usunąć z poziomu kokpitu, bez pisania kodu.

Po lekturze czytelnik będzie umiał zabezpieczyć niezapisaną treść, ustalić, co naprawdę odpowiedział serwer, dopasować do tego właściwą naprawę, sprawdzić jej skutek oraz przygotować rzeczowe zgłoszenie do firmy hostingowej, jeśli przyczyna leży po jej stronie.

Co oznacza komunikat o nieprawidłowej odpowiedzi JSON?

Edytor blokowy nie przeładowuje strony przy zapisie. Wysyła treść wpisu w tle do mechanizmu WordPressa o nazwie REST API i czeka na odpowiedź w ustalonym, uporządkowanym formacie tekstowym, czyli JSON. W poprawnie działającej witrynie odpowiedź przychodzi w ułamku sekundy i edytor pokazuje potwierdzenie zapisu.

Błąd pojawia się wtedy, gdy zamiast takiej odpowiedzi do edytora wraca coś innego. Może to być strona błędu 404, strona logowania, ekran blokady wystawiony przez zaporę, ostrzeżenie PHP dopisane przed właściwą odpowiedzią albo pusta odpowiedź po błędzie serwera. Edytor nie umie tego odczytać, więc zgłasza jedynie, że odpowiedź nie jest prawidłowa.

Z tego wynika najważniejsza rzecz: komunikat nie nazywa przyczyny, tylko jej skutek. Treść wpisu zwykle nie jest uszkodzona, a sam edytor działa poprawnie. Zawodzi droga między edytorem a serwerem i to ją trzeba sprawdzić.

Dokumentacja WordPressa dla programistów mówi wprost, że REST API nie należy wyłączać, ponieważ korzystają z niego funkcje panelu administracyjnego. Jeżeli więc w witrynie działa wtyczka albo fragment kodu, który „wyłącza REST API dla bezpieczeństwa”, edytor blokowy traci możliwość zapisu. To jedna z przyczyn, o której najłatwiej zapomnieć, bo takie ustawienie włącza się raz i przestaje o nim myśleć.

Najczęstsze źródła problemu, w kolejności, w jakiej spotykam je w praktyce, to: nieodświeżone reguły bezpośrednich odnośników, niezgodne adresy witryny po przejściu na https, konflikt wtyczki lub motywu, blokada ze strony zapory oraz błędy PHP wyświetlane na ekranie. Każdą z nich opisuję niżej razem ze sposobem sprawdzenia i naprawy.

Jak zabezpieczyć niezapisaną treść przed dalszymi próbami?

Zanim zacznie się cokolwiek naprawiać, trzeba zadbać o tekst, który jest otwarty w edytorze. Odświeżenie karty przeglądarki w tym momencie może oznaczać utratę wszystkiego, co powstało od ostatniego udanego zapisu. Edytor przechowuje co prawda kopię roboczą w pamięci przeglądarki, ale nie należy na niej polegać.

1. Kartę z edytorem zostawia się otwartą i niczego w niej nie odświeża.
2. W prawym górnym rogu edytora należy otworzyć menu „Opcje” oznaczone trzema kropkami i użyć polecenia kopiowania wszystkich bloków. Jeżeli polecenia nie widać, wystarczy kliknąć w treść, zaznaczyć całość skrótem Ctrl+A i skopiować skrótem Ctrl+C.
3. Skopiowaną treść wkleja się do zwykłego pliku tekstowego na komputerze i zapisuje. Bloki skopiowane w ten sposób można później wkleić z powrotem do edytora bez utraty układu.
4. Wszystkie dalsze czynności wykonuje się w drugiej karcie przeglądarki, a do karty z wpisem wraca się dopiero po naprawie, żeby ponowić zapis.

Przed zmianami w plikach i ustawieniach radzę też wykonać pełną kopię witryny. Sposób jej przygotowania i sprawdzenia opisałem w tekście o tym, jak zrobić kopię zapasową WordPressa, która naprawdę działa. Większość opisanych tu napraw jest bezpieczna, ale edycja pliku .htaccess lub wp-config.php z literówką potrafi wyłączyć całą stronę.

Jak sprawdzić, co naprawdę odpowiedział serwer?

Naprawianie na oślep polega na próbowaniu po kolei wszystkich znanych sposobów. Szybciej jest najpierw zobaczyć, co wróciło do edytora zamiast poprawnej odpowiedzi. Służą do tego trzy proste testy, które razem zajmują kilka minut.

Test adresu REST API w przeglądarce

W nowej karcie należy wpisać adres własnej witryny z dopiskiem /wp-json/, na przykład https://nazwa-domeny.pl/wp-json/. Poprawny wynik to strona wypełniona gęstym tekstem w nawiasach klamrowych, zaczynającym się od nazwy i opisu witryny. Tak wygląda JSON i taki widok oznacza, że REST API odpowiada.

Jeżeli zamiast tego pojawia się strona „Nie znaleziono” z szablonu witryny, przyczyną są najpewniej reguły bezpośrednich odnośników. Dla potwierdzenia warto wpisać drugi adres: https://nazwa-domeny.pl/?rest_route=/. Jest to ta sama usługa wywołana bez przyjaznych adresów. Gdy drugi adres pokazuje JSON, a pierwszy nie, wina leży po stronie przepisywania adresów na serwerze.

Ekran blokady, strona logowania albo komunikat o zabronionym dostępie wskazują z kolei na zabezpieczenia: wtyczkę ochronną, zaporę serwera lub usługę pośredniczącą w ruchu. Biała strona albo błąd serwera kierują podejrzenie na kod PHP wtyczki lub motywu.

Podgląd odpowiedzi w narzędziach przeglądarki

Bywa, że adres /wp-json/ działa, a zapis konkretnego wpisu nadal się nie udaje. Wtedy trzeba podejrzeć dokładnie to żądanie, które wysyła edytor. Każda popularna przeglądarka na komputerze ma do tego wbudowane narzędzia dla programistów.

1. W karcie z edytorem należy nacisnąć klawisz F12, a następnie przejść do zakładki „Network”, która w polskiej wersji narzędzi nosi nazwę „Sieć”.
2. Przy otwartym panelu trzeba ponownie kliknąć przycisk zapisu wpisu, czyli „Zapisz”, „Aktualizuj” albo „Opublikuj”.
3. Na liście pojawi się nowy wiersz z adresem zawierającym wp-json albo rest_route, zwykle oznaczony na czerwono. Należy w niego kliknąć.
4. W kolumnie statusu widać trzycyfrowy kod odpowiedzi, a w zakładce z treścią odpowiedzi to, co serwer faktycznie odesłał.
5. Kod i pierwsze wiersze odpowiedzi warto skopiować do notatki. Przydadzą się przy wyborze naprawy i w ewentualnym zgłoszeniu do hostingu.

Kod 404 oznacza, że serwer nie znalazł adresu REST API. Kod 403 mówi o odmowie dostępu, czyli o blokadzie. Kody z grupy 500 wskazują na błąd po stronie serwera, najczęściej w kodzie PHP. Kod 200 z odpowiedzią, która zaczyna się od słów w rodzaju „Warning” lub „Notice” albo od znaczników HTML, oznacza, że coś dopisało się przed właściwą treścią odpowiedzi.

Wbudowany test w ekranie „Stan witryny”

WordPress ma własne narzędzie diagnostyczne. W kokpicie należy wybrać „Narzędzia”, a następnie „Stan witryny”. Ekran ma dwie zakładki: „Stan” z wynikami testów oraz „Informacje” ze szczegółami konfiguracji. Testy uruchamiają się same po otwarciu ekranu.

W zakładce „Stan” trzeba poszukać pozycji dotyczących REST API oraz żądań zwrotnych, czyli połączeń, które witryna wykonuje sama do siebie. Jeżeli test REST API zgłasza błąd lub nieoczekiwany wynik, po rozwinięciu pozycji widać kod odpowiedzi i opis. To ta sama informacja, którą daje podgląd w przeglądarce, tylko uzyskana jednym kliknięciem.

Zakładka „Informacje” przydaje się w następnym kroku. W sekcji „WordPress” pokazuje obok siebie adres strony głównej, adres witryny, strukturę bezpośrednich odnośników oraz to, czy witryna korzysta z https. Wystarczy rzut oka, żeby wychwycić niezgodność.

Jak odświeżyć bezpośrednie odnośniki i plik .htaccess?

To pierwsza naprawa, od której należy zacząć, bo jest najszybsza i niczego nie psuje. Adres /wp-json/ nie jest prawdziwym katalogiem na serwerze. Działa dzięki regułom przepisywania adresów, które WordPress zapisuje w pliku .htaccess. Po przeniesieniu strony, zmianie hostingu albo po pracy wtyczki modyfikującej ten plik reguły bywają nieaktualne lub niekompletne.

1. W kokpicie należy wybrać „Ustawienia”, a następnie „Bezpośrednie odnośniki”.
2. Niczego się nie zmienia. Wybrana struktura adresów ma pozostać taka, jaka była, ponieważ jej zmiana zmieniłaby adresy wszystkich wpisów.
3. Na dole ekranu trzeba kliknąć „Zapisz zmiany”. WordPress zapisze reguły od nowa.
4. Po powrocie do karty z edytorem ponawia się zapis wpisu.

Jeżeli pod przyciskiem pojawia się informacja, że plik .htaccess nie jest zapisywalny, razem z ramką zawierającą reguły do ręcznego wklejenia, WordPress nie ma uprawnień do zmiany pliku. Wtedy plik trzeba poprawić samodzielnie, przez menedżer plików w panelu hostingu albo program FTP.

1. W głównym katalogu witryny, tam gdzie leży plik wp-config.php, należy odszukać plik .htaccess. Zaczyna się od kropki, więc w menedżerze plików trzeba czasem włączyć wyświetlanie plików ukrytych.
2. Plik pobiera się na komputer jako kopię. Tego kroku nie wolno pomijać.
3. W pliku na serwerze sprawdza się, czy między wierszami # BEGIN WordPress i # END WordPress znajduje się komplet reguł podany niżej. Brakujące wiersze uzupełnia się, niczego nie usuwając z pozostałych części pliku.
4. Po zapisaniu pliku trzeba od razu otworzyć stronę główną i adres /wp-json/. Jeśli witryna przestała się wyświetlać, wgrywa się z powrotem kopię z komputera.

Domyślna treść bloku WordPressa dla witryny zainstalowanej w katalogu głównym domeny wygląda następująco:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Dla WordPressa w podkatalogu oraz dla sieci witryn reguły są inne, dlatego w takich instalacjach należy skopiować je z ramki wyświetlonej na ekranie „Bezpośrednie odnośniki”, a nie z tego tekstu. Na serwerach Nginx pliku .htaccess nie ma wcale, a reguły ustawia administrator w konfiguracji serwera. W takim przypadku pozostaje zgłoszenie do hostingu z prośbą o sprawdzenie reguł przepisywania adresów dla WordPressa.

Objawem tej samej usterki bywa to, że wpisy otwierane z listy pokazują stronę błędu. Ten przypadek omawiam osobno w tekście o tym, jak naprawić bezpośrednie odnośniki, gdy wpisy zwracają błąd 404.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Przejmę sprawę: ustalę, co serwer odsyła edytorowi zamiast poprawnej odpowiedzi, usunę przyczynę i sprawdzę, czy zapis wpisów oraz wgrywanie obrazków znów działają.

Czy adresy witryny i certyfikat https są ze sobą zgodne?

Druga częsta przyczyna to niespójne adresy. Edytor otwarty pod adresem z https próbuje wysłać treść pod adres zapisany w ustawieniach. Jeśli ten zaczyna się od http albo różni się przedrostkiem www, przeglądarka traktuje takie połączenie jako niebezpieczne lub obce i je blokuje, a serwer odpowiada przekierowaniem zamiast danych.

Sprawdzenie zajmuje chwilę. W kokpicie należy wybrać „Ustawienia”, a następnie „Ogólne” i porównać dwa pola: „Adres WordPressa (URL)” oraz „Adres witryny (URL)”. Oba powinny zaczynać się od https, oba powinny mieć www albo oba powinny być bez www, i żaden nie powinien kończyć się ukośnikiem. Adres w pasku przeglądarki, pod którym otwarty jest kokpit, ma być z nimi zgodny.

Poprawkę w tych polach trzeba wprowadzać bardzo uważnie. Literówka w adresie odcina dostęp do kokpitu i wtedy naprawa wymaga już edycji pliku wp-config.php albo bazy danych. Gdy pola są wyszarzone, adresy zostały ustawione na stałe w pliku wp-config.php i tam należy je poprawić.

Warto też spojrzeć na kłódkę przy adresie w przeglądarce. Jeżeli przeglądarka ostrzega, że połączenie nie jest w pełni bezpieczne, część elementów strony wczytuje się jeszcze po http. Certyfikat musi być ważny i obejmować dokładnie tę wersję domeny, z której korzysta witryna. Całe przejście opisałem w tekście o tym, jak przejść na https bez strat.

Osobny przypadek to witryny działające za usługą pośredniczącą, która szyfruje ruch tylko między odwiedzającym a sobą. WordPress widzi wtedy połączenie nieszyfrowane, chociaż w przeglądarce jest https, i miesza adresy. Rozwiązaniem jest pełne szyfrowanie na całej trasie, czyli ważny certyfikat także na serwerze hostingu, oraz odpowiedni tryb szyfrowania w ustawieniach tej usługi.

Jak znaleźć wtyczkę lub motyw, które psują zapis?

Jeżeli odnośniki i adresy są w porządku, następnym podejrzanym jest dodatek. Zapis wpisu uruchamia kod wielu wtyczek jednocześnie: do pozycjonowania, pamięci podręcznej, zabezpieczeń, tłumaczeń, optymalizacji obrazków. Wystarczy, że jedna z nich zgłosi błąd albo dopisze coś do odpowiedzi, a edytor odrzuci całość.

Najbezpieczniejszą metodą jest tryb rozwiązywania problemów z wtyczki „Kontrola kondycji i rozwiązywanie problemów”, przygotowanej przez zespół WordPress.org. Zgodnie z jej opisem tworzy ona czystą sesję, w której wszystkie wtyczki są wyłączone i używany jest domyślny motyw, ale wyłącznie dla zalogowanego administratora. Odwiedzający przez cały czas widzą witrynę bez zmian.

1. W kokpicie należy wybrać „Wtyczki”, potem „Dodaj wtyczkę”, wyszukać nazwę „Health Check & Troubleshooting”, zainstalować wtyczkę i ją włączyć. Na stronie wtyczki trzeba wcześniej przeczytać informację o zgodności z używaną wersją WordPressa.
2. W menu „Narzędzia” otwiera się „Stan witryny” i przechodzi do zakładki rozwiązywania problemów, a następnie włącza tryb rozwiązywania problemów.
3. W tym trybie należy otworzyć wpis i spróbować go zapisać. Udany zapis oznacza, że przyczyną jest któraś wtyczka albo motyw.
4. Z górnego paska administracyjnego włącza się wtyczki pojedynczo i po każdej ponawia zapis. Ta, po której błąd wraca, jest przyczyną.
5. Na koniec z tego samego paska przywraca się własny motyw. Jeśli błąd wraca dopiero wtedy, źródłem jest motyw.
6. Po zakończeniu testu trzeba wyłączyć tryb rozwiązywania problemów w górnym pasku albo po prostu się wylogować.

Dla porządku dodam, że w witrynie musi być zainstalowany jeden z domyślnych motywów WordPressa, inaczej tryb nie będzie miał na co się przełączyć. Opis wtyczki uprzedza też, że w rzadkich przypadkach po włączeniu trybu dostęp do kokpitu bywa utrudniony. Dlatego wcześniejsza kopia zapasowa nie jest formalnością.

Metoda tradycyjna polega na wyłączeniu wszystkich wtyczek na ekranie „Zainstalowane wtyczki” przez zaznaczenie całej listy, wybranie w polu „Działania masowe” pozycji „Wyłącz” i kliknięcie „Zastosuj”. Jest skuteczna, ale ryzykowna na działającej stronie firmowej: na czas testu znikają formularze, sklep, zabezpieczenia i pamięć podręczna, a klienci to widzą. Jeśli już trzeba z niej skorzystać, to w porze najmniejszego ruchu i z gotową kopią.

Po wskazaniu winnego dodatku należy najpierw go zaktualizować i przejrzeć jego ustawienia pod kątem opcji związanych z REST API, pamięcią podręczną dla zalogowanych oraz blokowaniem żądań. Gdy to nie pomaga, pozostaje zgłoszenie do autora wtyczki z opisem kodu odpowiedzi albo wymiana dodatku na inny o tej samej funkcji.

Czy zapis blokuje zapora albo zabezpieczenia serwera?

Zapory aplikacyjne czytają treść wysyłaną na serwer i szukają w niej wzorców typowych dla ataków. Zdarza się, że za atak uznają zwykły wpis. Dzieje się tak zwłaszcza wtedy, gdy tekst zawiera fragmenty kodu, polecenia baz danych, osadzone ramki, skrypty albo długie adresy z parametrami. Serwer odsyła wtedy stronę z odmową, czyli kod 403, a edytor pokazuje znany komunikat.

Rozpoznanie jest proste. Trzeba utworzyć nowy wpis roboczy z jednym słowem w treści i go zapisać. Jeżeli krótki wpis zapisuje się bez problemu, a właściwy nie, przyczyną jest zawartość. Dzieląc treść na połowy i zapisując je osobno, można dojść do konkretnego bloku, który wywołuje blokadę.

Blokować mogą trzy warstwy. Pierwsza to wtyczka zabezpieczająca w samym WordPressie, w której dzienniku zwykle widać zablokowane żądanie. Druga to zapora na serwerze hostingu, najczęściej moduł ModSecurity, którym zarządza dostawca. Trzecia to zewnętrzna usługa ochrony i przyspieszania ruchu, która ma własny rejestr zdarzeń zapory w panelu.

Nie polecam wyłączania zabezpieczeń na stałe. Właściwa droga to odszukanie w dzienniku reguły, która zadziałała, i dodanie wyjątku tylko dla niej albo tylko dla adresów REST API używanych przez zalogowanych redaktorów. W przypadku zapory serwera wyjątek ustawia hosting na podstawie zgłoszenia z datą, godziną i adresem żądania. Jeżeli blokada obejmuje cały kokpit, pomocny będzie tekst o tym, gdzie szukać blokady przy błędzie 403 w kokpicie WordPressa.

Do tej samej grupy należy wygasła sesja. Gdy edytor był otwarty przez wiele godzin, WordPress może uznać logowanie za nieważne i odesłać okno logowania zamiast danych. Wystarczy wtedy zalogować się ponownie w drugiej karcie, wrócić do edytora i powtórzyć zapis.

Co zrobić, gdy do odpowiedzi dopisują się błędy PHP?

Odpowiedź dla edytora musi zawierać wyłącznie JSON. Jeśli witryna ma włączone wyświetlanie błędów na ekranie, każde ostrzeżenie PHP z wtyczki lub motywu zostaje wypisane przed właściwą treścią i psuje całość. W podglądzie odpowiedzi w przeglądarce widać wtedy wiersze zaczynające się od słów „Warning”, „Notice” lub „Deprecated”, a dopiero po nich nawias klamrowy.

Podobny skutek dają zbędne znaki w plikach edytowanych ręcznie. Pusty wiersz albo spacja przed otwierającym znacznikiem <?php w pliku functions.php motywu lub w wp-config.php trafiają do każdej odpowiedzi serwera. Na zwykłej stronie nikt tego nie zauważa, a edytorowi to wystarcza, żeby odrzucić zapis.

Rozwiązanie polega na tym, żeby błędy zapisywać do dziennika, a nie wyświetlać. Dokumentacja WordPressa opisuje do tego trzy ustawienia w pliku wp-config.php.

1. Plik wp-config.php z głównego katalogu witryny należy pobrać na komputer jako kopię, a następnie otworzyć do edycji na serwerze.
2. Trzeba odszukać wiersz z ustawieniem WP_DEBUG. Jeżeli istnieje, zastępuje się go trzema wierszami podanymi niżej. Jeżeli go nie ma, wiersze dopisuje się powyżej komentarza informującego o końcu edycji pliku.
3. Po zapisaniu pliku ponawia się zapis wpisu w edytorze, żeby błąd został zarejestrowany.
4. W katalogu wp-content pojawi się plik debug.log. Ostatnie wiersze wskazują ścieżkę do pliku, który zgłosił błąd, a nazwa katalogu w tej ścieżce to nazwa wtyczki lub motywu.
5. Po ustaleniu przyczyny wartość WP_DEBUG oraz WP_DEBUG_LOG zmienia się na false, a plik debug.log usuwa się z serwera.

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

Ostatni krok jest ważny. Ekran „Stan witryny” traktuje zapisywanie błędów do potencjalnie publicznego pliku jako problem krytyczny, podobnie jak wyświetlanie błędów odwiedzającym. Dziennik zawiera ścieżki i szczegóły konfiguracji, więc nie powinien leżeć na serwerze dłużej, niż trwa diagnoza.

Często samo ustawienie WP_DEBUG_DISPLAY na false przywraca zapis, bo ostrzeżenia przestają trafiać do odpowiedzi. To jednak usunięcie objawu. Ostrzeżenie nadal istnieje i warto przekazać je autorowi dodatku albo zaktualizować dodatek do wersji zgodnej z wersją PHP na serwerze.

Kody z grupy 500 bez żadnej treści oznaczają zwykle błąd krytyczny albo wyczerpany limit zasobów przy zapisie bardzo długiego wpisu. Wtedy dziennik debug.log oraz dziennik błędów w panelu hostingu podają dokładny powód, na przykład przekroczony limit pamięci lub czasu wykonania.

Dlaczego ten sam błąd pojawia się przy wgrywaniu obrazka?

Wgrywanie plików w edytorze blokowym również przechodzi przez REST API, więc wszystkie opisane wyżej przyczyny dotyczą także obrazków. Są jednak dwie dodatkowe. Pierwsza to plik zbyt ciężki lub o zbyt dużych wymiarach, którego serwer nie jest w stanie przetworzyć na miniatury w dozwolonym czasie. Druga to nazwa pliku ze znakami, które zapora uznaje za podejrzane.

Sprawdzenie polega na wgraniu małego obrazka o prostej nazwie złożonej z liter bez polskich znaków, cyfr i dywizów. Jeśli taki plik przechodzi, właściwy obrazek trzeba zmniejszyć przed wgraniem i nazwać w ten sam sposób. Zdjęcie prosto z aparatu lub telefonu jest zazwyczaj wielokrotnie większe, niż wymaga tego strona.

Rozwiązaniem doraźnym jest wgranie pliku poza edytorem, przez ekran „Media” i opcję dodawania nowego pliku, a następnie wstawienie go do wpisu z biblioteki. Limit wielkości wgrywanego pliku oraz aktywny moduł do obróbki obrazów można odczytać w sekcji „Obsługa mediów” w zakładce „Informacje” ekranu „Stan witryny”.

Po czym poznać, że naprawa zadziałała, i co zrobić, gdy nie pomogła?

Dowodem naprawy nie jest sam brak czerwonego paska przy jednej próbie. Należy zapisać wpis, zamknąć kartę, otworzyć wpis ponownie i sprawdzić, czy zmiana została zachowana. Potem warto powtórzyć próbę na stronie i na wpisie z obrazkiem, opublikować wersję roboczą oraz jeszcze raz otworzyć adres /wp-json/. Test REST API na ekranie „Stan witryny” powinien przejść bez zastrzeżeń.

Jeżeli żadna z opisanych czynności nie przyniosła skutku, a podgląd w przeglądarce pokazuje kod 403, kod z grupy 500 albo odpowiedź, której pochodzenia nie da się ustalić, sprawę trzeba przekazać firmie hostingowej. Zgłoszenie będzie skuteczne, jeśli znajdą się w nim konkretne dane:

• adres witryny oraz pełny adres żądania, które kończy się błędem, skopiowany z narzędzi przeglądarki,
• kod odpowiedzi i pierwsze wiersze treści odpowiedzi,
• dokładna godzina próby zapisu oraz adres IP, z którego ją wykonano,
• informacja, co zostało już sprawdzone: bezpośrednie odnośniki, adresy witryny, test bez wtyczek.

Samą prośbę można sformułować na przykład tak: „Zapis wpisów w edytorze WordPressa kończy się komunikatem o nieprawidłowej odpowiedzi JSON. Żądanie do adresu podanego niżej zwraca kod 403. Proszę o sprawdzenie dziennika zapory serwera dla tej godziny i tego adresu IP oraz o wskazanie reguły, która zablokowała żądanie”.

Do czasu rozwiązania sprawy można pracować w starszym edytorze. Wtyczka „Klasyczny edytor”, utrzymywana przez zespół WordPressa, zapisuje wpisy tradycyjnym formularzem i w mniejszym stopniu zależy od REST API. Traktuję ją wyłącznie jako rozwiązanie zastępcze, ponieważ nie usuwa przyczyny, a z REST API korzysta wiele innych funkcji i wtyczek.

Jakich błędów unikać podczas naprawy?

• Odświeżania karty z edytorem przed skopiowaniem treści.
• Zmiany struktury bezpośrednich odnośników zamiast samego ponownego zapisania ustawień, bo zmienia to adresy całej witryny.
• Usuwania pliku .htaccess bez wcześniejszego pobrania kopii, ponieważ mogą w nim być przekierowania i reguły innych wtyczek.
• Wyłączania wszystkich wtyczek w godzinach pracy firmy, kiedy klienci korzystają ze strony.
• Pozostawiania wyłączonej zapory lub włączonego dziennika błędów po zakończeniu testów.
• Instalowania kilku wtyczek „naprawczych” naraz, co utrudnia ustalenie, która zmiana pomogła.

Najczęstsze pytania

Czy przy tym błędzie treść wpisu przepada?

Nie od razu. Dopóki karta z edytorem pozostaje otwarta, treść jest widoczna i można ją skopiować. Przepada dopiero po zamknięciu lub odświeżeniu karty, jeśli nie została wcześniej zapisana ani skopiowana, dlatego kopiowanie wszystkich bloków do pliku tekstowego powinno być pierwszą czynnością.

Dlaczego błąd pojawia się tylko przy jednym wpisie?

Najczęściej oznacza to, że zapora uznała fragment treści za podejrzany albo że wpis jest na tyle obszerny, iż przekracza limity serwera. Pomaga test z krótkim wpisem roboczym oraz zapisywanie treści częściami, aż do znalezienia bloku, który wywołuje odmowę.

Czy przejście na „Klasyczny edytor” rozwiązuje problem?

Pozwala zapisać wpis i dokończyć pilną pracę, ale przyczyna pozostaje. REST API nadal nie działa poprawnie, co prędzej czy później ujawni się w innych funkcjach kokpitu i w dodatkach, które z niego korzystają. Starszy edytor należy traktować jako rozwiązanie na czas diagnozy.

Czy samo ponowne zapisanie bezpośrednich odnośników może coś zepsuć?

Nie, o ile nie zmienia się wybranej struktury. Kliknięcie „Zapisz zmiany” bez żadnych modyfikacji jedynie odświeża reguły przepisywania adresów. Adresy wpisów, stron i kategorii pozostają takie same.

Błąd pojawił się zaraz po włączeniu https. Gdzie szukać?

W polach „Adres WordPressa (URL)” i „Adres witryny (URL)” na ekranie „Ogólne” oraz w ważności certyfikatu. Oba adresy muszą zaczynać się od https i być zgodne z adresem, pod którym otwiera się kokpit. Jeżeli witryna korzysta z zewnętrznej usługi pośredniczącej, trzeba też sprawdzić w niej tryb szyfrowania.

Czy przyczyną może być pamięć podręczna?

Tak, jeśli wtyczka pamięci podręcznej lub usługa pośrednicząca przechowuje odpowiedzi REST API albo strony dla zalogowanych użytkowników. Po wyczyszczeniu pamięci należy w ustawieniach wykluczyć z niej kokpit oraz adresy zaczynające się od /wp-json/. Tryb rozwiązywania problemów szybko pokaże, czy źródłem jest wtyczka.

Czy błąd szkodzi widoczności strony w Google?

Bezpośrednio nie, ponieważ dotyczy zapisu w kokpicie, a nie tego, co widzą odwiedzający i roboty wyszukiwarek. Pośrednio tak, jeśli z jego powodu przez dłuższy czas nie da się publikować ani poprawiać treści. Bywa też sygnałem szerszej usterki, na przykład błędnych adresów po przejściu na https, która wpływa już na całą witrynę.

Kiedy sprawę powinien przejąć hosting?

Wtedy, gdy adres /wp-json/ zwraca odmowę lub błąd serwera również przy wyłączonych wtyczkach i domyślnym motywie. Oznacza to, że przyczyna leży poza WordPressem: w zaporze serwera, konfiguracji przepisywania adresów albo limitach konta, do których właściciel strony nie ma dostępu.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

To zrozumiałe. Komunikat o odpowiedzi JSON pojawia się zwykle w najmniej dogodnej chwili, kiedy tekst ma być opublikowany, a nie wtedy, gdy jest czas na przeglądanie plików serwera. Mogę zająć się tym od początku do końca: zabezpieczę treść i wykonam kopię witryny, sprawdzę odpowiedź serwera, odnośniki, adresy, wtyczki i zaporę, usunę przyczynę, a jeśli leży ona po stronie hostingu, przygotuję zgłoszenie i dopilnuję odpowiedzi. Na koniec przekażę krótką informację, co było źródłem błędu i co zostało zmienione.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz moment, w którym błąd się pojawia.