Weryfikacja i typowe problemy - WordPress

Zdarzenie testowe

Nie musisz psuć strony, żeby sprawdzić połączenie. Na ekranie Ustawienia → DockRay kliknij Wyślij zdarzenie testowe: wtyczka wysyła zdarzenie synchronicznie i pokazuje wynik razem z identyfikatorem, bez przeładowania strony. Udany test czeka na odpowiedź 200 {"success": true}, a jego rezultat i data zostają na ekranie jako pigułka statusu.

Zdarzenie powinno pojawić się w panelu w sekcji Błędy projektu wskazanego przez token. Sprawdź przy okazji trzy rzeczy: środowisko, czas i kontekst żądania. Jeśli środowisko jest puste, wtyczka nie dostała ani wartości z ekranu, ani typu środowiska z WordPressa.

Weryfikacja na prawdziwym błędzie

Test z ekranu potwierdza połączenie, ale nie automatyczne przechwytywanie. Żeby sprawdzić i to, wywołaj na środowisku testowym nieobsłużony wyjątek - na przykład z tymczasowego shortcode'a albo z hooka init na wybranym adresie - i sprawdź, czy zdarzenie dojechało. Po udanym teście usuń ten kod: każde kolejne wywołanie podbija licznik sztucznego błędu i zużywa miesięczny limit.

Typowe problemy

Nic nie dociera do panelu

Sprawdź kolejno: czy komplet poświadczeń jest wpisany (pigułka statusu odpowiada na to wprost), czy token i klucz należą do tego samego projektu, czy klucz nie został odwołany w panelu i czy hosting dopuszcza połączenia wychodzące HTTPS. Wtyczka nie podąża za przekierowaniami, więc adres własnej instancji DockRay musi być tym docelowym, a nie takim, który przekierowuje.

Wpisałem token na ekranie, a wtyczka używa innego

Zwykle znaczy to, że w wp-config.php stoi DOCK_RAY_TOKEN albo DOCK_RAY_PRIVATE_KEY, a źródło konfiguracji jest ustawione na Auto - wtedy stała wygrywa. Obszar statusu wypisuje, które stałe są aktywne. Przestaw źródło na Tylko ten ekran, jeżeli ta witryna ma raportować do innego projektu niż wspólna konfiguracja serwera.

Zdarzenia są, ale bez stosu wywołań albo bez kontekstu żądania

Zdarzenie z hooka wywołanego przez WP-CLI albo cron nie ma żądania HTTP, więc nie będzie miało też kontekstu żądania - i tak ma być. Brak stosu przy błędzie PHP oznacza natomiast, że zdarzenie powstało z błędu, a nie z wyjątku; wtedy miejsce awarii wskazuje plik i linia.

Za dużo notice'ów i deprecacji

Instalacja z kilkunastoma wtyczkami potrafi generować ich setki dziennie i wypchnąć z listy to, co znaczące. Zawęź DOCK_RAY_ERROR_TYPES w wp-config.php do poziomów, na które faktycznie reagujecie.

Błędy JavaScriptu nie docierają

Kolektor jest domyślnie wyłączony - włącz Zbieraj błędy JavaScript na ekranie ustawień. Jeżeli po włączeniu nadal nic nie przychodzi, pamiętaj o trzech bramkach odbiornika: nonce, limit 16 kB na zgłoszenie i 20 zgłoszeń na adres IP na minutę. Odbiornik odpowiada 202 także wtedy, gdy zgłoszenie odrzucił, więc status odpowiedzi w konsoli przeglądarki niczego nie rozstrzyga.

Ten sam błąd zajmuje całą listę

To zwykle jeden wyjątek w pętli albo w cronie. Panel grupuje błędy po odcisku sha256(token projektu + typ + komunikat) i trzyma jeden wiersz na błąd na dzień, więc taki przypadek widać jako jeden wiersz z wysokim licznikiem. Jeśli mimo to rozbija się na wiele wierszy, znaczy, że komunikat zawiera zmienną część - identyfikator zamówienia albo znacznik czasu - i to ją trzeba wyprowadzić z treści wyjątku.

Panel odpowiada 200, ale zdarzenia nie ma

Odpowiedź 200 {"success": false} znaczy, że konto wyczerpało miesięczny limit błędów. Integracja nie traktuje tego jak awarii - i słusznie. Limit widzisz na pulpicie konta; do końca miesiąca liczy się z zapisanego zużycia, więc nie zresetuje go usunięcie błędów.

Nadal nie działa

Przejdź przez listę kontrolną braku danych w panelu, a jeśli to nie pomoże - napisz do nas. Podaj nazwę projektu, wersję integracji i przybliżoną godzinę testu: to skraca drogę do odpowiedzi.