Jak skutecznie rozwiązać problemy z REST API w WordPress?

Problemy REST API pojawiają się między innymi przy zapisie w edytorze, pobieraniu danych i obsłudze integracji. Zapisz, co próbujesz zrobić, pod jakim adresem i kiedy pojawia się błąd. Informacja, że API nie działa, jest zbyt ogólna, aby wybrać właściwą poprawkę.

Otwórz narzędzia przeglądarki i kartę Sieć lub Network. Odszukaj żądanie związane z nieudaną czynnością. Zanotuj trasę, metodę HTTP, status i komunikat odpowiedzi. Nie udostępniaj cookies, nonce ani nagłówka Authorization. Mogą zawierać dane pozwalające działać w Twoim kontekście.

Jeżeli przeglądarka nie wysyła oczekiwanego żądania, problem może występować wcześniej w JavaScript. Z kolei udana odpowiedź API nie dowodzi, że interfejs poprawnie ją przetworzył. Te sytuacje wymagają innych sprawdzeń.

Gdy dopiero planujesz połączenie systemów, zacznij od przewodnika WordPress REST API. Tutaj skupiamy się na istniejącej czynności, która zwraca błąd lub przestała działać.

Sprawdź nie tylko status, lecz także Content-Type i zawartość odpowiedzi. JSON z kodem błędu WordPressa daje inną wskazówkę niż strona HTML informująca o blokadzie. Odpowiedź może pochodzić z WordPressa, serwera, proxy albo WAF stojącego przed witryną.

Status 200 nie wystarcza do uznania testu za poprawny. Serwer może zwrócić formularz logowania lub stronę ochrony zamiast oczekiwanych danych. Podobnie status 403 nie oznacza automatycznie źle ustawionej roli WordPressa, jeśli żądanie zostało zatrzymane wcześniej przez zaporę.

Zapisz krótki komunikat i czas. Jeśli ochrona podaje identyfikator zdarzenia, ułatwi on administratorowi odnalezienie konkretnej reguły. Nie kopiuj całego żądania razem z sekretami do publicznego narzędzia analizującego nagłówki.

Przy przekierowaniu sprawdź adres docelowy. Zmiana domeny, protokołu lub ścieżki może sprawić, że żądanie trafi w inne miejsce niż oczekuje integracja. Najpierw ustal zamierzony adres, zanim zmienisz ustawienia WordPressa.

Dla typowych bezpośrednich odnośników indeks API jest dostępny pod /wp-json/. Publiczne wpisy można zwykle odczytać przez /wp-json/wp/v2/posts. Taki odczyt pomaga sprawdzić osiągalność API bez wykonywania zapisu. Nie wymaga ujawniania hasła administratora.

Nie każdy WordPress używa identycznego adresu. Przy innym ustawieniu odnośników może występować parametr rest_route, a instalacja w podkatalogu ma własną ścieżkę. Integracja powinna korzystać z prawidłowo wykrytego adresu, nie przypadkowo sklejonego URL.

Jeżeli publiczny GET działa, nadal może nie działać zapis konkretnego wpisu, endpoint rozszerzenia lub operacja wymagająca uprawnień. Test w Narzędzia > Stan witryny także ma swój zakres i kontekst. Różny wynik nie musi oznaczać sprzeczności.

Dalszą diagnozę oprzyj na dokładnej trasie, metodzie i koncie używanym w nieudanej operacji. Testy zmieniające dane wykonuj na kopii i materiale testowym. Nie uruchamiaj prawdziwej płatności, wysyłki wiadomości ani webhooka tylko po to, aby uzyskać odpowiedź API.

WordPress przy odmowie uprawnień może zwrócić różne statusy. Funkcja rest_authorization_required_code wybiera 401 dla użytkownika niezalogowanego oraz 403 dla zalogowanego. Nie oznacza to jednak, że każda odpowiedź o takim statusie pochodzi z tej funkcji.

W interfejsie zalogowanego WordPressa używane są cookie sesji i nonce. Kod rest_cookie_check_errors pokazuje, że brak nonce powoduje potraktowanie żądania jako anonimowego, a nieprawidłowy nonce zwraca rest_cookie_invalid_nonce ze statusem 403.

Jeśli problem pojawił się w długo otwartym edytorze, zabezpiecz niezapisany tekst, odśwież własną sesję i ponownie otwórz ekran. Nie próbuj naprawiać nonce przez udostępnienie endpointu wszystkim użytkownikom. Nadal potrzebna jest kontrola prawa do konkretnej operacji.

Według dokumentacji nonce rzeczywisty domyślny okres ważności mieści się między 12 a 24 godzinami. Mechanizm korzysta z dwóch przedziałów czasu, więc nie jest to dokładnie doba od każdego kliknięcia. Zmiana sesji również ma znaczenie. Nonce chroni przed określonym nadużyciem żądania, ale nie zastępuje uwierzytelnienia ani uprawnień.

Zewnętrzna integracja może używać innej metody uwierzytelnienia niż edytor WordPressa. REST API Handbook opisuje Application Passwords dostępne w core od wersji 5.6 i stosowane przez HTTPS. Nie przenoś automatycznie tych samych danych do API dowolnej wtyczki.

Sprawdź, czy właściwy serwer wysyła oczekiwany nagłówek i czy konto ma uprawnienia potrzebne do działania. Jeżeli proxy lub konfiguracja PHP usuwa nagłówek Authorization, poprawka dotyczy tej warstwy. Powinna zostać dobrana przez administratora do używanego serwera, a nie wklejona do przypadkowego pliku.

Sekret integracji pozostaje po stronie serwera lub w przeznaczonym do tego bezpiecznym narzędziu. Nie umieszczaj go w JavaScript, HTML ani adresie URL dostarczanym użytkownikowi. Nie zapisuj wartości nagłówka w logu diagnostycznym.

Testuj możliwie mały wymagany zakres uprawnień. Przy odczycie publicznej treści token administratora nie powinien być sposobem ukrycia błędu konfiguracji. Po teście upewnij się, że użytkownik bez odpowiednich praw nadal otrzymuje odmowę przy chronionej operacji.

Przy 404 sprawdź dokładną trasę, namespace, metodę i to, czy moduł rejestrujący endpoint działa. Brak konkretnej trasy nie jest dowodem awarii całego REST. Zweryfikuj też sposób przekazywania ścieżki i parametrów przez serwer.

Nie usuwaj całego .htaccess na próbę. Może zawierać potrzebne reguły ochrony lub przekierowań. LiteSpeed Web Server obsługuje ten plik, natomiast Nginx korzysta z innej konfiguracji. Instrukcję trzeba dopasować do faktycznego produktu i środowiska.

Przy 500 odczytaj prywatny log PHP z czasu żądania. Problemem może być kod endpointu lub zależnego rozszerzenia. Dopiero komunikat o wyczerpaniu pamięci uzasadnia przejście do diagnozy memory limit. Sam status nie jest powodem, by ustawić 256 MB lub większą wartość.

Gdy zamiast JSON pojawia się komunikat PHP, nie włączaj publicznego wyświetlania błędów. Dokumentacja debugowania pozwala wskazać prywatną ścieżkę logu i niezależnie wyłączyć wyświetlanie komunikatów. Najpierw wykorzystaj istniejące logi hostingu; dodatkową diagnostykę prowadź na kopii i zakończ po zebraniu danych.

Jeżeli odpowiedź wskazuje blokadę, odszukaj odpowiadające jej zdarzenie ochrony. Administrator powinien ustalić regułę, trasę i parametry, które wywołały reakcję. Dopiero wtedy można rozważyć wąski wyjątek dla potwierdzonej poprawnej operacji.

Nie dodawaj całego /wp-json/ do allowlisty jako uniwersalnej naprawy. Może to ominąć ochronę innych endpointów. Własny permission_callback nadal musi kontrolować działanie i dostęp do obiektu. Zwrócenie true dla wszystkich użytkowników nie jest poprawką błędu autoryzacji.

Cache może wpływać na spersonalizowaną odpowiedź albo stronę zawierającą stary nonce. Nie oznacza to, że odpowiada za każdy błąd 401. Cloudflare opisuje, że HTML i JSON nie są domyślnie buforowane jak obsługiwane zasoby statyczne. Sprawdź rzeczywiste reguły witryny oraz cache na pozostałych warstwach.

Przy problemie po zmianie CDN skorzystaj z poradnika konfiguracji Cloudflare. Kontroluj także HTTPS i przekierowania. Home i siteurl mogą celowo różnić się ścieżką, więc nie wyrównuj ich bez zrozumienia sposobu instalacji.

Powtórz dokładnie tę samą operację na kopii: trasę, metodę i kontekst użytkownika. Sprawdź oczekiwaną odpowiedź oraz efekt w danych. Jeżeli test dotyczy zapisu, potwierdź brak duplikatów i utrzymanie odmowy dostępu dla kont bez uprawnień.

Nie wyłączaj całego REST API, by pozbyć się komunikatu. Oficjalny REST API Handbook mówi: "You should not disable the REST API". Funkcje panelu i rozszerzeń mogą od niego zależeć.

Jeżeli potrzebujesz pomocy, wyślij przez kontakt adres strony i opis nieudanej czynności. Status, krótki komunikat oraz czas są opcjonalnym uzupełnieniem. Nie dołączaj haseł ani pełnego eksportu ruchu przeglądarki bez usunięcia sekretów.

Pomoc w naprawie WordPressa pozwala ustalić warstwę problemu. Po usunięciu awarii można omówić opiekę nad stroną, aby kolejne aktualizacje obejmowały również test działania ważnych połączeń.