Strona główna → Usługi → Automatyzacja aktualizacji WordPressa
Dla agencji z Holandii budujemy i utrzymujemy strony WordPress jej klientów. Aktualizacje rdzenia, wtyczek i motywów szły ręcznie, strona po stronie, i to ograniczało, jak często mogły się dziać. Powstała własna wtyczka utrzymaniowa i skrypt uruchamiany z harmonogramu serwera: aktualizuje, sprawdza, czy strona po aktualizacji nadal działa, i wysyła raport. Poniżej to, czego dowiedzieliśmy się po drodze — prawie każda z tych rzeczy wyszła dopiero w działaniu.
WP-Cron odpala się przy wejściu na stronę. Na stronie, na którą przez tydzień nikt nie wchodzi, zaplanowane zadania po prostu milczą. Dlatego aktualizacje uruchamia wpis w harmonogramie hostingu: skrypt PHP, który sam wczytuje WordPressa.
To przeniosło inny problem. Poza żądaniem HTTP tablica $_SERVER jest prawie pusta, a wtyczki z typowanymi metodami zwracają z niej null i wywalają się na TypeError — jeszcze w trakcie wczytywania WordPressa, czyli zanim cokolwiek było w stanie napisać raport z tego błędu. Skrypt podstawia więc bezpieczne wartości przed wp-load.
Nie dotyka wp-config.php. Rozpoznaje tam ustawienia warte uwagi i o nich pisze, ale decyzję zostawia człowiekowi: w tym pliku siedzą własne stałe, a literówka gasi stronę.
Nie wycofuje też aktualizacji samodzielnie — raport podaje wersje przed i po, żeby było z czego wracać. I poprawka jednej strony zostaje na jej serwerze, z kopią i notatką; do kodu, który jedzie na wszystkie, nie trafia.
Niektórych rzeczy automat aktualizować nie powinien. Lista wstrzymanych aktualizacji powstała po tym, jak aktualizacja Bricksa wyłączyła jedną stronę na pół dnia. Przyczyna: 2.4 wywołuje hooki szablonu przez do_action_ref_array(), a puste argumenty WordPress dokłada tylko w do_action() — callbacki motywu potomnego z wymaganym parametrem zaczęły padać na ArgumentCountError. Przy ręcznym przebiegu na tej samej stronie automat zaktualizował Bricksa mimo wpisu na liście: lista była sprawdzana tylko przy wtyczkach, a Bricks instaluje się jako motyw.
Drugie znalezisko z tego samego tygodnia: zapis jednej zakładki ustawień czyścił listę do pustej. Obsługa zapisu przetwarza tylko pola swojej zakładki, a przypisanie trafiło do bloku innej — przy każdym zapisie wartość leciała do ''. Naprawa obu była warunkiem przejścia z przebiegu cotygodniowego na codzienny.
Po aktualizacji sklep ma być sprawdzony, bo zepsuta kasa nie zgłasza się sama. Pierwsza wersja składała testowe zamówienie i po sobie sprzątała — ustawiała status „anulowane” i wrzucała do kosza. Status „anulowane” uruchamia firmowy mail WooCommerce, a kosz ukrywa zamówienie: właściciele sklepów dostawali maile o anulowanym zamówieniu, którego nie mogli znaleźć. Filtry nie pomagają, bo te maile wychodzą z kolejki, w następnym żądaniu. Sprzątanie przeszło więc na trwałe usunięcie — które na sklepach z nowym magazynem zamówień nic nie usuwało, bo tam zamówienia nie leżą już w tabeli wpisów.
Dziś automat nie tworzy zamówienia. Przechodzi sklep tak jak kupujący — strona główna, karta produktu, koszyk przez Store API, strona kasy — i zatrzymuje się przed przyciskiem płatności. Na sklepach z integracjami nowe zamówienie w kilka sekund podnosi księgowość i system mailingowy, a część z nich nadaje numer faktury już przy utworzeniu.
Pliki rdzenia i wtyczek są porównywane z sumami kontrolnymi z wordpress.org. Zgłaszały za dużo: hosting zapisuje php_errorlog w katalogu, z którego wywrócił się skrypt — także w głębi rdzenia; jedna strona ma w rdzeniu stary plik .htaccess, który blokuje dostęp i nic więcej; na innej migracja sprzed lat przestawiła znaki końca linii w kilkudziesięciu plikach. Każdy z tych przypadków dostał własną regułę, a nie wyjątek na całą wtyczkę. Osobno trafiają do raportu pliki, które skaner hostingu sam zdjął do kwarantanny.
W drugą stronę było gorzej. Gdy narzędzie nie zwracało nic, pusta lista rozbieżności wpadała w gałąź „brak zmian” — brak możliwości sprawdzenia był raportowany jako wynik czysty. „Nie udało się sprawdzić” jest teraz osobnym stanem.
Skrypt crona leży w katalogu WordPressa i wtyczka wgrywa go tam sama. Robiła to jednak na zdarzeniu aktualizacji wtyczki i przy wejściu do panelu przez zalogowanego administratora — a hurtowe wgranie przez MainWP ani kopia przez SFTP żadnego z tych zdarzeń nie wywołują. Panel pokazywał nową wersję, nocny przebieg wykonywał kod sprzed kilkunastu wersji i nic tego nie mówiło. Dziś wersja jest porównywana przy każdym przebiegu i przy zwykłym wejściu na stronę, bez logowania.
Napisz, ile jest stron i czy są wśród nich sklepy. Powiemy, co da się puścić automatem, a co i tak zostaje do ręki.
Opisz swoje strony →Albo mailem: info@asymetria.com.pl