„Nie powiodła się publikacja”. Dlaczego edytor WordPressa nie zapisuje wpisu?

Tekst jest gotowy, zdjęcia wstawione, zostaje jedno kliknięcie. Zamiast potwierdzenia na dole ekranu pojawia się czerwony pasek z informacją, że publikacja się nie powiodła. Wpis nie trafia na stronę, a przy kolejnej próbie komunikat wraca.

Ten błąd dotyka najczęściej osoby, które same prowadzą firmową stronę albo blog i nie mają pod ręką programisty. Wygląda groźnie, ale w zdecydowanej większości przypadków treść nie przepada, a przyczyna leży w jednym z kilku dobrze znanych miejsc: w połączeniu, w ustawieniach adresów, we wtyczce, w zaporze albo w ograniczeniach serwera.

Ta instrukcja prowadzi przez całą drogę: od zabezpieczenia napisanego tekstu, przez ustalenie przyczyny za pomocą narzędzi wbudowanych w WordPressa, po naprawę każdej z nich i sprawdzenie, czy zapis działa już poprawnie.

Po czym rozpoznać ten błąd i jak dokładnie brzmi komunikat?

Komunikat pojawia się w edytorze blokowym, w lewym dolnym rogu ekranu albo na pasku nad treścią, zaraz po kliknięciu „Opublikuj”. W polskiej wersji WordPressa brzmi on obecnie „Nie powiodła się publikacja.”, a w wielu opisach w sieci funkcjonuje jako „Publikowanie nie powiodło się”. Oba sformułowania oznaczają to samo zdarzenie.

Ten sam błąd ma kilka odmian zależnych od czynności. Przy zmianie istniejącego wpisu edytor pokazuje „Nie powiodła się aktualizacja.”, a przy ustawianiu daty w przyszłości „Nie powiodła się zaplanowana publikacja.”. Przyczyny i sposób postępowania są we wszystkich trzech przypadkach identyczne.

Często do głównego zdania dołączona jest druga część, która od razu podpowiada kierunek. Gdy przeglądarka straciła dostęp do sieci, pojawia się dopisek o pracy offline, w nowszych wydaniach w postaci „Publikowanie nie powiodło się, ponieważ użytkownik był offline. Sprawdź połączenie i spróbuj ponownie.”, a w starszych „Prawdopodobnie jesteś offline.”. Gdy serwer odpowiedział czymś innym, niż edytor oczekiwał, dopisek brzmi „Odpowiedź nie jest prawidłową odpowiedzią JSON.”.

Warto od razu zanotować pełną treść komunikatu, razem z dopiskiem. To pierwsza i najtańsza wskazówka, a po odświeżeniu strony znika.

Co dzieje się w chwili kliknięcia „Opublikuj”?

Edytor blokowy nie przeładowuje strony przy zapisie, tak jak robił to dawny edytor. Wysyła treść w tle do samego WordPressa przez mechanizm o nazwie REST API, czyli przez specjalny adres w obrębie witryny, zwykle zaczynający się od /wp-json/. Serwer zapisuje wpis w bazie i odsyła krótkie potwierdzenie.

Komunikat o niepowodzeniu oznacza, że ta wymiana się nie udała. Żądanie nie dotarło do serwera, zostało po drodze zatrzymane, zostało odrzucone albo odpowiedź wróciła w zepsutej postaci. Sam edytor zwykle działa poprawnie, a kłopot leży na drodze między przeglądarką a serwerem.

Z tego wynika praktyczny wniosek. Zamiast przepisywać wpis albo instalować edytor od nowa, należy sprawdzić po kolei wszystko, co stoi na tej drodze: połączenie z siecią, ważność logowania, adresy witryny, plik .htaccess, wtyczki i motyw, zaporę oraz limity serwera. Dokumentacja WordPressa wprost odradza wyłączanie REST API, ponieważ zależą od niego funkcje kokpitu.

Kolejność sprawdzania ma znaczenie. Przyczyny banalne, takie jak zerwane połączenie czy wygasła sesja, zdarzają się najczęściej i sprawdza się je w minutę. Dopiero gdy zostaną wykluczone, jest sens sięgać do plików na serwerze.

Jak zabezpieczyć napisaną treść, zanim zacznie się naprawa?

Największą obawą jest utrata kilku godzin pracy. Dopóki karta z edytorem pozostaje otwarta, tekst nadal w niej jest, a edytor przechowuje dodatkowo kopię roboczą w pamięci przeglądarki. Najgorszym ruchem jest w tej chwili zamknięcie karty lub odświeżenie strony bez zrobienia kopii.

1. Kartę z edytorem należy zostawić otwartą i niczego w niej nie odświeżać.
2. W prawym górnym rogu edytora trzeba otworzyć menu „Opcje” oznaczone trzema kropkami i wybrać „Kopiuj wszystkie bloki”.
3. Skopiowaną treść wkleja się do zwykłego pliku tekstowego na komputerze i zapisuje pod czytelną nazwą. Taka kopia zachowuje bloki, więc później da się ją wkleić z powrotem do pustego wpisu.
4. Jeśli wpis zawiera nowe zdjęcia, należy w nowej karcie otworzyć „Media” i sprawdzić, czy pliki są już w bibliotece. Zdjęcia wgrane przed błędem zwykle tam są.
5. Dalsze czynności naprawcze wykonuje się w osobnej karcie przeglądarki, a kartę z wpisem zostawia w spokoju do końca.

Jeżeli karta została już zamknięta, nie wszystko stracone. Po ponownym otwarciu wpisu WordPress często wyświetla informację „Kopia wpisu znajdująca się w przeglądarce różni się od prezentowanej poniżej.” z przyciskiem „Przywróć kopię”. Kopia ta jest przechowywana tylko w tej samej przeglądarce i na tym samym urządzeniu, dlatego nie należy w międzyczasie czyścić danych przeglądania.

Drugim ratunkiem są automatyczne zapisy i wersje wpisu widoczne w panelu bocznym edytora. Działają one jednak tylko wtedy, gdy zapis w tle w ogóle dochodził do skutku, więc przy tym błędzie nie należy na nich polegać. Własna kopia w pliku tekstowym jest pewniejsza.

Jak w kilka minut ustalić, która przyczyna zachodzi?

WordPress ma wbudowane narzędzie, które samo sprawdza, czy REST API odpowiada. To najszybszy sposób, żeby oddzielić kłopot po stronie witryny od kłopotu po stronie komputera, z którego pisany jest wpis.

Odczytanie ekranu „Stan witryny”

1. W nowej karcie należy otworzyć kokpit i przejść do „Narzędzia”, a następnie „Stan witryny”.
2. Na karcie „Status” trzeba poczekać, aż testy się zakończą. Trwa to zwykle kilkanaście sekund.
3. Na liście problemów należy odszukać pozycję dotyczącą REST API. Przy awarii nosi ona nazwę „REST API napotkało błąd” albo „REST API napotkało nieoczekiwany rezultat”.
4. Po rozwinięciu tej pozycji widać adres, który był sprawdzany, oraz odpowiedź serwera wraz z kodem liczbowym. Te dwie informacje należy zanotować.
5. Jeśli takiej pozycji nie ma, trzeba rozwinąć sekcję „Testy zaliczone” i poszukać wpisu „REST API jest dostępne”.

Wynik testu rozdziela dalszą drogę na dwie części. Gdy REST API jest dostępne, serwer i ustawienia witryny są w porządku, a przyczyny trzeba szukać w przeglądarce, połączeniu, sesji albo w regule zapory reagującej na konkretną treść wpisu. Gdy test zgłasza błąd, winne są adresy witryny, plik .htaccess, wtyczka, zapora lub serwer.

Co mówi kod odpowiedzi serwera?

Kod liczbowy przy odpowiedzi jest bardzo użyteczną podpowiedzią. Kody 401 i 403 oznaczają odmowę dostępu, czyli wygasłe logowanie albo blokadę nałożoną przez zaporę lub wtyczkę bezpieczeństwa. Kod 404 wskazuje, że adres REST API nie istnieje, co prowadzi do bezpośrednich odnośników i pliku .htaccess.

Kody zaczynające się od cyfry 5 oznaczają awarię po stronie serwera: błąd w kodzie wtyczki lub motywu, wyczerpaną pamięć albo przekroczony czas wykonywania. Osobno opisałem, jak ustalić przyczynę błędu 500 w WordPressie, ponieważ ten kod wymaga zajrzenia do dziennika błędów.

Sprawdzenie w narzędziach przeglądarki

Ten sam kod da się odczytać bezpośrednio w karcie z edytorem, bez jej odświeżania. Po naciśnięciu klawisza F12 otwierają się narzędzia dla programistów. Należy przejść na kartę „Sieć”, ponownie kliknąć „Opublikuj” i odszukać na liście czerwony wiersz z adresem zawierającym wp-json.

Kolumna ze stanem pokazuje kod, a po kliknięciu wiersza widać treść odpowiedzi. Jeśli zamiast uporządkowanych danych znajduje się tam strona HTML z komunikatem zapory albo ostrzeżenie PHP, przyczyna jest właściwie ustalona. Sytuację z dopiskiem o JSON omawia szerzej osobny wpis o tym, jak naprawić zapis, gdy odpowiedź nie jest prawidłową odpowiedzią JSON.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: ustalę, co zatrzymuje zapis w edytorze, usunę przyczynę i sprawdzę, czy wpisy publikują się bez błędu.

Co zrobić, gdy zawiodło połączenie albo wygasła sesja?

Dopisek o pracy offline nie zawsze oznacza brak internetu w całym biurze. Wystarczy chwilowe przełączenie sieci bezprzewodowej, uśpienie laptopa albo niestabilne połączenie przez telefon. Edytor nie ponawia wysyłki sam, więc po przywróceniu sieci trzeba kliknąć „Opublikuj” jeszcze raz.

Prosty test polega na otwarciu w nowej karcie dowolnej innej strony oraz strony głównej własnej witryny. Jeśli obie się wczytują, połączenie działa i ponowna próba zapisu powinna się udać. Jeśli własna witryna nie odpowiada, a inne tak, kłopot leży po stronie hostingu i z publikacją trzeba poczekać.

Druga częsta przyczyna to wygasłe logowanie. Zdarza się, gdy wpis jest otwarty przez wiele godzin, gdy komputer był uśpiony albo gdy w innej karcie nastąpiło wylogowanie. WordPress zwykle pokazuje wtedy okno z informacją „Twoja sesja wygasła. Zaloguj się, aby kontynuować.”, ale okno to bywa zasłonięte lub zamknięte przez przypadek.

Naprawa jest bezpieczna dla treści. W nowej karcie należy otworzyć stronę logowania witryny, zalogować się ponownie, wrócić do karty z wpisem i ponowić zapis. Karty z edytorem nie trzeba przy tym odświeżać.

Trzecia rzecz z tej grupy to dodatki przeglądarki. Rozszerzenia blokujące reklamy i skrypty oraz programy ochronne na komputerze potrafią zatrzymać żądanie wysyłane w tle. Najprościej sprawdzić to, logując się do kokpitu w oknie prywatnym albo w innej przeglądarce i publikując tam krótki wpis próbny. Jeśli zapis działa, winne jest jedno z rozszerzeń i wystarczy dodać własną witrynę do jego wyjątków.

Jak naprawić adresy witryny i bezpośrednie odnośniki?

Ta grupa przyczyn ujawnia się zwykle po zmianach: po włączeniu certyfikatu SSL, po przeniesieniu strony na inny hosting, po zmianie domeny albo po ręcznej edycji plików. Edytor wysyła wtedy treść pod adres, który nie zgadza się z tym, pod którym witryna faktycznie działa.

Zgodność dwóch adresów w ustawieniach

Po wejściu w „Ustawienia”, a następnie „Ogólne” widać dwa pola: „Adres WordPressa (URL)” oraz „Adres witryny (URL)”. Oba powinny zaczynać się tak samo, jak adres widoczny w pasku przeglądarki podczas pracy w kokpicie. Jeżeli strona otwiera się przez https://, a w polach widnieje http://, przeglądarka blokuje wysyłkę w tle jako niezabezpieczoną.

To samo dotyczy przedrostka www. Adres z www i adres bez www są dla przeglądarki dwiema różnymi witrynami. W obu polach i w pasku adresu powinna być używana jedna, ta sama postać.

Zmiana tych pól wymaga dużej ostrożności. Literówka w adresie odcina dostęp do kokpitu i strona przestaje się otwierać. Przed zapisaniem należy dwa razy przeczytać wpisaną wartość, a jeśli pola są wyszarzone, oznacza to, że adresy zostały ustawione w pliku wp-config.php i tam trzeba je poprawić. Kto nie ma pewności, powinien powierzyć tę zmianę osobie z dostępem do plików serwera.

Odświeżenie reguł bezpośrednich odnośników

Adres REST API korzysta z tych samych reguł przepisywania adresów co wpisy i strony. Gdy plik .htaccess jest uszkodzony albo niekompletny, adres /wp-json/ zwraca kod 404 i zapis w edytorze przestaje działać. WordPress potrafi odtworzyć te reguły sam.

1. W kokpicie należy otworzyć „Ustawienia”, a następnie „Bezpośrednie odnośniki”.
2. Nie zmienia się żadnego ustawienia. Wybrany format odnośników ma pozostać taki, jaki był, ponieważ jego zmiana zmieniłaby adresy wszystkich wpisów.
3. Na dole ekranu trzeba kliknąć „Zapisz zmiany”. WordPress zapisuje wtedy reguły na nowo.
4. Jeśli pojawi się informacja, że plik nie jest zapisywalny, WordPress wyświetli treść reguł do ręcznego wklejenia. Wtedy plik .htaccess w głównym katalogu witryny uzupełnia się przez menedżera plików w panelu hostingu, po uprzednim zrobieniu kopii tego pliku.
5. Na koniec w nowej karcie wpisuje się adres własnej witryny z dopiskiem /wp-json/. Poprawnie działające REST API wyświetla stronę wypełnioną uporządkowanymi danymi technicznymi, a nie stronę błędu.

Gdy adres z dopiskiem /wp-json/ nadal zwraca błąd, a wersja z dopiskiem /?rest_route=/ działa, potwierdza to kłopot z przepisywaniem adresów na serwerze. W takiej sytuacji należy poprosić pomoc techniczną hostingu o sprawdzenie, czy serwer obsługuje reguły z pliku .htaccess.

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

Jeżeli błąd pojawił się po aktualizacji albo po instalacji nowego dodatku, podejrzenie pada przede wszystkim na wtyczki. Najczęściej zapis zatrzymują wtyczki bezpieczeństwa z własną zaporą, wtyczki ograniczające dostęp do REST API, wtyczki pamięci podręcznej oraz dodatki, które przy zapisie wpisu wykonują własne operacje i kończą je błędem.

Przed testami należy mieć aktualną kopię witryny. Wyłączanie wtyczek zwykle niczego nie usuwa, ale przy sklepie lub rozbudowanej stronie firmowej nie należy pracować bez zabezpieczenia. Sposób przygotowania takiej kopii opisuje wpis o tym, jak zrobić kopię zapasową WordPressa i sprawdzić, czy działa.

1. W kokpicie należy otworzyć „Wtyczki”, a następnie „Zainstalowane wtyczki”.
2. W pierwszej kolejności wyłącza się przyciskiem „Wyłącz” jedną wtyczkę: tę ostatnio zainstalowaną lub zaktualizowaną albo wtyczkę bezpieczeństwa.
3. W karcie z wpisem trzeba ponowić zapis. Jeśli się powiedzie, winowajca jest znaleziony.
4. Jeśli nie, zaznacza się wszystkie wtyczki, z listy „Działania masowe” wybiera „Wyłącz” i klika „Zastosuj”. Następnie ponawia się zapis.
5. Gdy przy wyłączonych wtyczkach zapis działa, włącza się je po jednej przyciskiem „Włącz”, po każdej sprawdzając zapis. Wtyczka, po której włączeniu błąd wraca, jest przyczyną.
6. Gdy wyłączenie wszystkich wtyczek nie pomogło, w „Wygląd”, a następnie „Motywy” włącza się na chwilę jeden z motywów domyślnych WordPressa i ponawia próbę.

Na działającej stronie firmowej wyłączenie wszystkich wtyczek naraz jest widoczne dla odwiedzających: znikają formularze, koszyk, elementy wyglądu. Bezpieczniejszą drogą jest oficjalna wtyczka Health Check & Troubleshooting, przygotowana przez społeczność WordPressa. Jej tryb rozwiązywania problemów wyłącza wtyczki i przełącza motyw wyłącznie dla zalogowanego administratora, a odwiedzający widzą stronę bez zmian. Drugą bezpieczną drogą jest kopia testowa witryny, którą część firm hostingowych pozwala utworzyć w panelu.

Po znalezieniu winnej wtyczki są trzy rozsądne wyjścia. Można zaktualizować ją do najnowszej wersji, można poszukać w jej ustawieniach opcji dotyczącej REST API lub zapory i ją poluzować, wreszcie można zgłosić błąd autorowi i na czas oczekiwania zastąpić dodatek innym. Trwałe pozostawienie wyłączonej wtyczki bezpieczeństwa bez zamiennika nie jest dobrym rozwiązaniem.

Co zrobić, gdy zapis blokuje zapora lub serwer?

Zapory działają na trzech poziomach: we wtyczce bezpieczeństwa, na serwerze hostingu oraz w zewnętrznej usłudze pośredniczącej w ruchu do witryny. Każda z nich analizuje treść wysyłaną na serwer i może uznać zwykły wpis za próbę ataku.

Charakterystyczny objaw to błąd zależny od treści. Krótki wpis próbny publikuje się bez przeszkód, a ten jeden konkretny nie. Zdarza się to, gdy tekst zawiera fragmenty kodu, polecenia baz danych, znaczniki skryptów albo nietypowe adresy. W narzędziach przeglądarki widać wtedy kod 403, o którym więcej piszę w tekście o tym, gdzie szukać blokady przy błędzie 403 w kokpicie WordPressa.

Prosty sposób potwierdzenia polega na utworzeniu nowego wpisu próbnego i wklejaniu do niego treści partiami, z zapisem szkicu po każdej. Fragment, po którym zapis przestaje działać, wywołuje regułę zapory. Wpis próbny należy po teście usunąć.

Zapory na serwerze i w usłudze zewnętrznej nie należy wyłączać w całości. Właściwą drogą jest zgłoszenie do pomocy technicznej z prośbą o wskazanie reguły, która zadziałała, i dodanie wyjątku dla adresu REST API witryny. Zgłoszenie może brzmieć na przykład tak: „Przy zapisie wpisu w edytorze WordPressa żądanie do adresu /wp-json/wp/v2/posts kończy się kodem 403. Proszę o sprawdzenie dziennika zapory dla mojej domeny z podanej godziny i o dodanie wyjątku dla reguły, która blokuje zapis.”. Do zgłoszenia należy dopisać nazwę domeny, godzinę nieudanej próby oraz własny adres IP.

Osobną grupą są limity serwera. Bardzo długi wpis z dużą liczbą bloków, zapisany przy wielu aktywnych wtyczkach, może wyczerpać pamięć przydzieloną dla PHP albo przekroczyć dozwolony czas wykonywania. W odpowiedzi pojawia się wtedy kod z grupy 500, a w dzienniku błędów wpis o pamięci lub czasie. Limity podnosi się w panelu hostingu albo przez pomoc techniczną, a ich aktualne wartości pokazuje ekran „Stan witryny” na karcie „Informacja”, w części dotyczącej serwera.

Jak odczytać dziennik błędów, gdy nic innego nie pomaga?

Jeżeli żaden z dotychczasowych kroków nie wskazał przyczyny, pozostaje zapisanie błędów PHP do pliku. WordPress ma do tego wbudowany tryb diagnostyczny, włączany w pliku wp-config.php w głównym katalogu witryny.

Dokumentacja WordPressa zaleca, aby trybu diagnostycznego nie używać na działających publicznie stronach, lecz na kopii testowej. Jeśli kopii testowej nie ma, tryb należy włączyć tylko na kilka minut, z ukrytym wyświetlaniem błędów, a potem wyłączyć. Przed edycją pliku trzeba pobrać jego kopię na komputer, ponieważ błąd składni w tym pliku wyłącza całą witrynę.

1. W menedżerze plików w panelu hostingu należy otworzyć do edycji plik wp-config.php.
2. Trzeba odszukać wiersz z ustawieniem WP_DEBUG. Jeśli istnieje, zastępuje się go wierszami podanymi poniżej. Jeśli nie, wkleja się je przed wierszem z komentarzem informującym o końcu edycji.
3. Po zapisaniu pliku należy wrócić do karty z wpisem i jeszcze raz kliknąć „Opublikuj”, żeby błąd wystąpił ponownie.
4. W katalogu wp-content pojawia się plik debug.log. Trzeba go otworzyć i przeczytać ostatnie wiersze.
5. Po odczytaniu należy przywrócić w pliku wp-config.php wartość false przy WP_DEBUG i usunąć plik debug.log z serwera.

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

W dzienniku najważniejsze są wiersze oznaczone jako „Fatal error”. Każdy z nich zawiera ścieżkę do pliku, w którym błąd wystąpił. Nazwa katalogu po wp-content/plugins/ to nazwa wtyczki, a po wp-content/themes/ to nazwa motywu. W ten sposób dziennik wskazuje winowajcę nawet wtedy, gdy wyłączanie wtyczek po kolei było niemożliwe.

Plik debug.log bywa dostępny z zewnątrz pod przewidywalnym adresem i może zawierać informacje techniczne o witrynie. Z tego powodu usunięcie go po zakończeniu diagnozy jest częścią naprawy, a nie dodatkiem.

Po czym poznać, że naprawa zadziałała, i jakich błędów unikać?

Samo zniknięcie czerwonego paska przy jednej próbie nie wystarcza. Naprawę należy potwierdzić w kilku miejscach, ponieważ część przyczyn wraca przy kolejnym, dłuższym wpisie.

• Po kliknięciu „Opublikuj” edytor pokazuje potwierdzenie z odnośnikiem do wpisu, a wpis otwiera się w nowej karcie pod swoim adresem.
• Po zmianie jednego zdania i kliknięciu „Zapisz” zmiana jest widoczna na stronie po jej odświeżeniu.
• Ekran „Stan witryny” na karcie „Status” nie pokazuje już pozycji o błędzie REST API, a w sekcji „Testy zaliczone” widnieje „REST API jest dostępne”.
• Wpis z dodanym zdjęciem i wpis z ustawioną datą w przyszłości zapisują się bez komunikatu o błędzie.
• Zapis działa także z innej przeglądarki i z innego urządzenia.

Gdy naprawa nie zadziałała, najczęściej zachodzą dwie przyczyny jednocześnie, na przykład niezgodne adresy i reguła zapory. Wtedy należy przejść całą kolejność jeszcze raz, od ekranu „Stan witryny”, i porównać kod odpowiedzi z poprzednim. Zmiana kodu, na przykład z 404 na 403, oznacza, że jedna przeszkoda została usunięta i ujawniła się następna.

W praktyce widzę kilka powtarzających się pomyłek, które wydłużają naprawę albo dokładają nowe kłopoty.

• Odświeżanie karty z wpisem przed skopiowaniem treści, co bywa jedyną drogą do rzeczywistej utraty tekstu.
• Wyłączanie REST API albo całej zapory „na stałe”, żeby komunikat zniknął. Pierwsze psuje kokpit, drugie odbiera witrynie ochronę.
• Zmiana formatu bezpośrednich odnośników zamiast samego ponownego zapisania ustawień, co zmienia adresy wpisów i szkodzi widoczności w wyszukiwarce.
• Edycja pliku wp-config.php lub .htaccess bez pobrania kopii pliku na komputer.
• Pozostawienie włączonego trybu diagnostycznego i pliku debug.log na serwerze.
• Wprowadzanie kilku zmian naraz, po czym nie wiadomo, która pomogła i którą należy cofnąć.

Radzę też zapisywać krótką notatkę: co było przyczyną i co ją usunęło. Ten błąd lubi wracać po aktualizacjach, a notatka skraca wtedy naprawę do kilku minut.

Najczęstsze pytania

Czy po tym komunikacie napisany tekst przepada?

Zwykle nie. Dopóki karta z edytorem jest otwarta, cała treść pozostaje na ekranie i można ją skopiować poleceniem „Kopiuj wszystkie bloki” z menu „Opcje”. Po zamknięciu karty szansą jest kopia przechowywana w przeglądarce oraz automatyczne zapisy, ale żadna z tych dróg nie daje pewności, dlatego własną kopię należy zrobić przed pierwszą próbą naprawy.

Dlaczego błąd pojawia się tylko przy jednym wpisie, a inne publikują się poprawnie?

Taki objaw wskazuje na treść wpisu albo na jego rozmiar. Zapora mogła uznać fragment tekstu za podejrzany, zwłaszcza gdy zawiera on kod lub nietypowe adresy, albo bardzo długi wpis przekroczył limit pamięci lub czasu na serwerze. Wklejanie treści partiami do wpisu próbnego pozwala ustalić, który fragment wywołuje blokadę.

Czy przejście na edytor klasyczny rozwiązuje problem?

Oficjalna wtyczka „Edytor klasyczny” zapisuje wpisy w inny sposób, bez wysyłki w tle przez REST API, więc często pozwala opublikować pilny tekst mimo awarii. Jest to jednak obejście, a nie naprawa. Przyczyna pozostaje w witrynie i daje o sobie znać w innych miejscach, które korzystają z REST API, dlatego po publikacji i tak należy ją usunąć.

Komunikat pojawił się zaraz po włączeniu certyfikatu SSL. Co sprawdzić w pierwszej kolejności?

W pierwszej kolejności pola „Adres WordPressa (URL)” i „Adres witryny (URL)” w „Ustawienia”, „Ogólne”. Oba powinny zaczynać się od https://, tak jak adres w pasku przeglądarki. Jeśli certyfikat był włączany przez wtyczkę albo przez usługę zewnętrzną, trzeba też sprawdzić, czy nie pozostały w niej ustawienia wymuszające starą postać adresu.

Czy wyłączenie wtyczek na czas testu usuwa ich ustawienia?

Samo wyłączenie wtyczki zwykle zachowuje jej ustawienia i dane, a po ponownym włączeniu wszystko wraca. Inaczej jest przy usunięciu wtyczki, które może skasować jej dane na stałe. Do testów stosuje się więc wyłącznie wyłączenie, a przed rozpoczęciem przygotowuje kopię zapasową witryny.

Hosting twierdzi, że po jego stronie wszystko działa. Co wtedy?

Wtedy należy przekazać pomocy technicznej konkrety zamiast ogólnego opisu: adres żądania zawierający wp-json, kod odpowiedzi odczytany w narzędziach przeglądarki, dokładną godzinę próby i własny adres IP. Z takimi danymi obsługa może odszukać zdarzenie w dzienniku zapory i w dzienniku błędów serwera. Ogólne zgłoszenie o niedziałającym edytorze najczęściej kończy się odpowiedzią, że serwer pracuje poprawnie.

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

Sam komunikat nie ma wpływu na wyszukiwarkę, ponieważ widzi go tylko osoba zalogowana w kokpicie. Szkodzić może dopiero przyczyna, jeśli ta sama blokada albo awaria serwera dotyka też odwiedzających, oraz nieostrożna naprawa, na przykład zmiana formatu odnośników we wszystkich wpisach. Po naprawie dobrze jest otworzyć kilka wpisów na stronie i upewnić się, że ich adresy pozostały bez zmian.

Jak ograniczyć ryzyko powrotu błędu?

Pomagają trzy nawyki. Aktualizacje wtyczek, motywu i WordPressa należy wykonywać pojedynczo, po każdej sprawdzając zapis krótkiego szkicu. Długie teksty lepiej zapisywać jako szkic co kilkanaście minut, zamiast trzymać kartę otwartą przez cały dzień. Wreszcie po każdej zmianie w ustawieniach zapory lub hostingu warto zajrzeć na ekran „Stan witryny” i sprawdzić pozycję dotyczącą REST API.

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

To zrozumiałe. Prowadzenie firmy zostawia mało miejsca na czytanie dzienników błędów i rozmowy z pomocą techniczną hostingu, a wpis czeka na publikację. Mogę przejąć całość: zabezpieczę napisaną treść, ustalę, co zatrzymuje zapis w edytorze, usunę przyczynę we wtyczkach, ustawieniach, zaporze lub na serwerze, a na koniec sprawdzę publikację, aktualizację i planowanie wpisów oraz opiszę prostymi słowami, co było nie tak.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz treść komunikatu. Odpowiem, od czego zacznę i czego będę potrzebować.