To zgłoszenie w jednym zdaniu: zaplanowane treści nie publikują się same, a wejście do panelu trwa minuty. Ta sama witryna postawiona lokalnie działa szybko i publikuje bez zarzutu. Zgłoszenie tego rodzaju jest trudne nie dlatego, że przyczyna jest egzotyczna, tylko dlatego, że objawy pasują do kilkunastu różnych przyczyn naraz.
Dlaczego zgadywanie tu nie działa
Mechanizm zadań zaplanowanych w WordPressie nie jest planistą systemowym. To doczepka do ruchu: przy okazji odsłony strony serwis wysyła żądanie sam do siebie i dopiero ono wykonuje zaległe zadania. Wystarczy, że to żądanie zwrotne nie dochodzi — bo blokuje je zapora, bo domena rozwiązuje się na zewnętrzny adres, bo warstwa pamięci podręcznej odpowiada zamiast serwisu — i zaplanowane treści przestają się publikować, nie zgłaszając żadnego błędu.
Wolne logowanie ma z kolei własny zestaw podejrzanych: rozrośnięta tabela opcji ładowanych przy każdym żądaniu, brak pamięci podręcznej obiektów, wtyczka odpytująca zewnętrzne API w trakcie generowania strony. Każdy z tych tropów brzmi wiarygodnie i każdy da się „naprawić” bez sprawdzenia, czy to on.
Diagnostyka, która nie potrafi wykluczyć hipotezy, jest tylko listą pomysłów.
Sonda, która rozstrzyga
Najciekawszym elementem takiego zestawu narzędzi jest sonda zadań zaplanowanych. Zamiast pytać, czy mechanizm jest włączony, planuje własne zdarzenie i sprawdza z nowego żądania, czy ono przetrwało. Osobna faza wymusza równoległe zapisy tej samej opcji.
To rozstrzyga pytanie, którego nie da się rozstrzygnąć z konfiguracji: czy problem leży w uruchamianiu zadań, czy w trwałości zapisu. Przy równoległych żądaniach lista zadań potrafi się nadpisywać sama, a wtedy zdarzenie znika z kolejki chwilę po tym, jak zostało do niej dopisane. Objaw jest identyczny jak przy niedziałającym żądaniu zwrotnym, a naprawa zupełnie inna.
Reszta zestawu
- Migawka bez ruchu sieciowego — środowisko i stałe, stan zadań, treści zaplanowane, tabela opcji i to, ile z niej ładuje się przy każdym żądaniu, pamięć podręczna obiektów, wtyczki i motyw.
- Testy czynne — żądanie zwrotne pod kilka adresów naraz, ruch wychodzący, baza danych, spójność listy zadań.
- Profiler — oś czasu żądania, wywołania sieciowe z czasami i wskazaniem wtyczki, która je wykonała, najwolniejsze zapytania do bazy i najwolniejsze funkcje podpięte pod zdarzenia.
- Werdykt — około trzydziestu reguł zamieniających surowe dane w listę ustaleń, każde z dowodem i następnym krokiem.
Całość jest tylko do odczytu poza dwoma jawnie oznaczonymi działaniami naprawczymi. Narzędzie diagnostyczne, które po cichu coś zmienia, przestaje być punktem odniesienia — po jego uruchomieniu nie wiadomo już, co było stanem zastanym.
Dostęp bez logowania, i dlaczego to nie jest niedopatrzenie
Punkty dostępowe działają bez zalogowania — celowo, bo diagnozowany bywa właśnie niedziałający panel. Sytuacja „nie mogę się zalogować, więc nie mogę sprawdzić, dlaczego nie mogę się zalogować” jest tu regułą, a nie wyjątkiem.
Chroni je token, limit prób i wyłącznik, a wszystkie trzy dają się przybić stałą w pliku konfiguracyjnym — łącznie z twardym zamknięciem, którego nie da się cofnąć z panelu. Po zakończeniu diagnozy narzędzie ma dać się wyłączyć tak, żeby przypadkowe kliknięcie go nie wskrzesiło.
Przypis z pola walki
Paczkę do wgrania buduje skrypt w PHP, choć system operacyjny ma własne polecenie do archiwów. Powód jest konkretny: wbudowane polecenie zapisuje w nagłówkach lokalnych archiwum separatory katalogów w postaci ukośników wstecznych. Katalog centralny wygląda poprawnie, więc większość narzędzi nie pokaże żadnego problemu — ale rozpakowywarka w PHP tworzy z tego płaskie pliki z ukośnikami w nazwie i instalacja kończy się komunikatem o nieistniejącym pliku wtyczki.
Biblioteka archiwów w PHP zawsze zapisuje ukośnik zwykły, a build dodatkowo to weryfikuje przed wypuszczeniem paczki. Takie rzeczy trafiają do dokumentacji projektu, bo następnym razem kosztowałyby ten sam dzień.
Wszystkie wpisy