Artykuł ten powinien się ukazać na przełomie czerwca i lipca, gdy cala akcja miała miejsce. Pisać zacząłem go kilka dni temu, ale uznałem, że fajnie, jak ukaże się właśnie dziś, tj. 24 sierpnia 2020. Data znamienna, 24 czerwca ukazał się poprzedni/ostatni artykuł na Webinsider.pl, czyli równo 2 miesiące temu. Przerwa długa, najprawdopodobniej najdłuższa w kilkuletniej historii serwisu. Przerwa wynikająca z jednej z większych – jesli nie największej – zmian w moim życiu, przynajmniej od kilku lat. Przerwa, która w planach miała trwać 2-3 dni, maksymalnie tydzień. Stąd też moje „informatyczne” zaplecze – np. w postaci laptopa z golutkim i świeżutkim systemem Windows i telefonu – miało wystarczyć, by w razie ew. pilnych i ważnych problemów móc działać. Ale czasem w życie przynosi niespodzianki, i to większe, niż można się było spodziewać.

Permanentny spinner podczas (próby) finalizacji zamówienia w sklepie internetowym

I tak w takim przygotowanym tymczasowym nieprzygotowaniu, które okazało się dłuższe niż chwilowe, zdarzył się problem, który faktycznie wymagał działania. Problem dotyczył sklepu internetowego, a więc wymagał natychmiastowego działania. Nawet jeśli ów sklep był w trakcie testowego rozruchu.

Strona, sam sklep, katalog produktów, dodawanie produktów do koszyka, w końcu sama wizyta w koszyku – wszystko zdawało się działać prawidłowo. Przynajmniej do czasu przejścia do ostatniego etapu, gdzie oprócz danych do wysyłki należy wybrać metodę płatności. I w tym miejscu pojawił się problem – wybór metody wysyłki i płatności był nieaktywny, blokowany przez „spinner”, czyli kręcące się kółeczko, symbolizujące, że coś się dzieje (wczytuje) i trzeba czekać. Zdarza się, z tym że w tym przypadku można było czekać i czekać…

Sklep, o którym mowa działa na WooCommerce, a więc na WordPressie, a więc oprócz standardowych modułów mamy tu kilka dodatkowych wtyczek, oraz trochę/sporo dodatkowego kodu, tak by realizować powierzone mu zadania. W sumie nic nadzwyczajnego. I w sumie jeszcze kilka dni wcześniej – akcja ma miejsce pod koniec czerwca, czyli 2-3 dni po rozpoczęciu planowo nieplanowanego dłuższego urlopu – wszystko działało, łącznie z testowany zakupami, i to w relatywnie realnym środowisku, bo nawet z bramkami szybkich płatności. A tutaj niespodzianka, i to bez większych aktualizacji, które potencjalnie mogłyby tłumaczyć sytuację.

Tak więc wyciągam z torby laptopa, odpala mojego świeżutkiego Windowsa, instaluje Firefoksa (tak, tak i tak!), odpalam narzędzia dla deweloperów i nic, co by mogło wskazywać na konkretny błąd (np. JavaScript). Kolejny krok to logi na serwerze – tu również cisza i spokój. Debugowania WordPressa podobnie, czyli bez czegokolwiek, co by mogło naprowadzić na rozwiązanie problemu… Na koniec szybki test z cofnięciem wtyczki WooCommerce, jak i samego WordPressa o jedną wersję wstecz i… już wiem, że trzeba klonować sklep do wersji testowej, tak by ew. modyfikacje/testy nie tylko nie wpływały na bieżące działanie sklepu (testowy rozruch, więc i tak głównie obsługa i IT ;-)), ale by nie było później zabawy z odwracaniem zmian.

Śmielsze testy na sklonowanym sklepie

W tym momencie mogę pozwolić sobie na śmielsze działania, więc zaczynam od wyłączenia wszystkich wtyczek poza WooCommerce, oraz wywalenia wszelkich modyfikacji motywu, w tym wszystkiego, co zbędne z pliku functions.php (zostaje tylko deklaracja dla motywu potomnego). Niestety to nic nie daje. Kolejny krok, to zmiana motywu na któryś ze standardowych motywów WordPressa, a że mamy rok 2020, więc siłą rzeczy wybór pada na Twenty Twenty. I bingo – w tym momencie wszystko zaczyna działać prawidłowo.

Motywy potomne z problemem

Podejrzenie pada na motyw Divi, który być może po aktualizacji z jakichś powodów gryzie się z WooCommerce. By to sprawdzić, zmieniam ponownie używany motyw, tym razem na Divi. I tu kolejna niespodzianka – wszystko działa prawidłowo, i to bez potrzeby przywracania Divi do starszej wersji.

Kolejny test, to zmiana na goły (czysty) motyw potomny Divi, i… jest problem. Trochę to dziwne, choć zaczyna się układać w pewną całość. By zweryfikować swoje podejrzenia, szybko tworzę goły/czysty motyw potomny Twenty Twenty i jak pewnie niektórzy z Was się domyślają – pojawia się „spinnerowy problem”. Czyli strona/sklep działa zarówno na standardowym motywie Twenty Twenty, jak i na motywie Divi, ale nie działa na ich motywach potomnych. Dziwne, ale co poradzić, gdy tak jest…

Tak więc mam sklep, co blokuje się na ostatnim kroku procesu zakupowego (spinner), ale tylko wtedy, gdy jest aktyny motyw potomny. I to nawet w sytuacji, gdy motyw potomny jest golaskiem, czyli poza niezbędnym do jego działania minimów nic więcej tam nie ma. Zresztą dotyczy to również wtyczek, które wszystkie – oczywiście poza WooCommerce – zostały wyłączone.

W międzyczasie trafiam na podobny problem (spinner bez końca) w oknie wyszukiwania nowych motywów i wtyczek, i to z identycznymi objawami – motyw potomny aktywny jest problem, motyw główny (rodzic) aktywny i problemu brak. W tym momencie moje zdziwienie wzrosło jeszcze bardziej, i to nawet nie tylko dlatego, że pierwszy raz spotkałem się z taką sytuacją.

Przecież są jeszcze tzw. wtyczki „must use”

Trochę jakby skonfundowany skoczyłem po coś chłodnego z solidną dawką chmielu do piwnej lodówki (konkretnie była to jakaś solidna IPA z TO ØL). Usiadłem, przelałem do szklanki, zrobiłem „check in” w aplikacji Untappd, i… Przypomniałem sobie, że oprócz zwykłych wtyczek każda moja strona zazwyczaj posiada jeszcze kilka wtyczek wymuszonych, czyli tzw. „must use”, których nie widać bezpośrednio w panelu zarządzania WordPressem (WP-Admin), a „instalują” się automatycznie, podczas pobierania plików WordPressa z mojego startowego repozytorium w serwisie GitHub. Jak się szybko okazało, to był strzał w dziesiątkę. Teraz zostało odszukać konkretną mikro-wtyczkę, która generowała ów problem.

Szybko okazało się, że problem generuje wtyczka, która odpowiada za powiadomienia e-mail m.in. o aktywności (wybranych typów) użytkowników, takie jak np. zalogowanie się np. administratora do WordPressa. W sumie to – patrząc na problem – tylko pogłębiło moje zdziwienie. Ale testy jednoznacznie wykazały, ze faktycznie to tutaj jest źródło problemu.

Tag zamykający blok kodu PHP

Analizując kod wtyczki, szybko zwróciłem uwagę na to, że na końcu znajduje się tag zamykający blok kodu PHP, czyli coś, przed czym sam ostrzegałem ponad rok wcześniej w artykule „brak tagu zamykającego blok języka PHP nie tylko nie musi być błędem, ale często wręcz może być koniecznością”. Dlatego trochę mnie to zdziwiło, ale gdzieś tam mi w głowie się kołatało, że jakoś 2 czy 3 dni wcześniej na szybko, korzystając z telefonu, odkomentowałem jakąś regułkę, która akurat znajdowała się na końcu pliku, i być może tam ukrył się ów tag. A że po tej operacji działała nie tylko strona, ale i owa reguła, to prace poszły dalej. Zwłaszcza że jak pisałem, był to niezwykle intensywny dla mnie okres.

I chyba bez zaskoczenia będzie – skoro właśnie o tym tagu piszę w tym miejscu – że właśnie to była (dziwna) przyczyna (dziwnego) niedziałania ostatniego kroku zakupowego w sklepie internetowym. Bo choć problem udało się relatywnie szybko rozwiązać, to objawy występujące tylko w przypadku korzystania z motywów potomnych nadal dziwią.

Sklep (już) działa, wracamy (do działania) i my

I tak zastanawiając się nad pierwszym artykułem, jaki po zakończeniu trochę wymuszonej okolicznościami, a trochę chyba też chęcią, powinien pojawić się na Webinsider.pl, od razu czułem/wiedziałem, że to powinien być właśnie ten artykuł. Z jednej strony w pewnym sensie merytoryczny, bo przedstawiający konkretne zdarzenie, poszukiwanie źródła problemu, i ostateczne rozwiązanie.

Z drugiej strony wiedziałem, że to będzie mógł być też na tyle luźny pod względem formy i treści artykuł, gdzie będę mógł też dość swobodnie przedstawić całe tło, i to nie tylko związane z opisywanym problemem, ale też m.in. z przerwą w ukazywaniu się nowych artykułów. Mam nadzieję, że tym samym wrócimy do regularnych publikacji, nawet jeśli ze względu na charakter przerwy nie można powiedzieć, by to był urlop, a tym samym być może kosy nie do końca naostrzone tak, jak być powinny… ;-)