Cron, Action Scheduler i staging

Moduł 7: Widoczność w wyszukiwarkach i hosting · Czas czytania: 10 min

Cel lekcji: Po tej lekcji potrafią Państwo wyjaśnić, jak WooCommerce wykonuje zadania w tle, sprawdzić zaplanowane działania i naprawić je w razie problemów, a także przygotować środowisko testowe (staging) dla sklepu tak, aby nie zagrażało ono prawdziwym klientom, płatnościom ani zamówieniom.

Kluczowe pojęcia: WP-Cron, prawdziwy cron, DISABLE_WP_CRON, Action Scheduler, zaplanowane działania, oczekujące, zakończone, nieudane, czyszczenie, staging dla sklepu, tryb testowy operatora płatności, wyłączona poczta, webhooki, integracje, nieprzywracanie bazy danych na wersję produkcyjną

Co się dzieje, gdy nikt nie patrzy

Sklep wykonuje wiele pracy, która nie wynika bezpośrednio z kliknięcia odwiedzającego:

• anulowanie nieopłaconych zamówień po upływie czasu wstrzymania stanu magazynowego (lekcja 3.4);
• wysyłanie e-maili po zmianie statusu oraz webhooków do integracji;
• aktualizowanie raportów i statystyk w panelu;
• usuwanie wygasłych sesji i danych tymczasowych;
• stosowanie okresów przechowywania z ustawień Konta i prywatność (lekcja 2.3);
• przy subskrypcjach lub integracjach księgowych: pobieranie płatności i przekazywanie danych.

Do tego WordPress używa WP-Cron, a WooCommerce dodatkowo Action Scheduler. Jeśli nie działają one prawidłowo, nie zauważą Państwo tego od razu. Zauważą to Państwo, gdy nieopłacone zamówienia nadal blokują stan magazynowy, raporty pozostają puste albo integracja ma kilka dni opóźnienia.

WP-Cron i prawdziwy cron

Jak działa WP-Cron i dlaczego prawdziwe zadanie cron jest lepsze, opisano w kursie WordPress, w lekcji 6.3: WP-Cron uruchamia się przy odwiedzinach, a nie według zegara, co jest zawodne przy małym ruchu i obciążające przy dużym. Rozwiązanie: DISABLE_WP_CRON w pliku wp-config.php oraz zadanie cron w panelu hostingowym, które co kilka minut uruchamia wp-cron.php.

W przypadku sklepu nie jest to optymalizacja, lecz konieczność:

• W nocy, gdy ruch jest mały, nieopłacone zamówienia i tak muszą zostać anulowane na czas.
• Podczas dużej promocji nie chcą Państwo, aby ciężkie zadanie w tle doczepiało się do żądania strony klienta, który chce złożyć zamówienie.

W WebOké takie zadanie tworzą Państwo w DirectAdmin w sekcji Zadania Cron (DA 15.1, KB 48), podając /usr/local/bin/php jako ścieżkę do PHP; u innych dostawców hostingu działa to podobnie w ich ekranie cron. Dla sklepu prosimy wybrać interwał od jednej do pięciu minut, raczej niż dziesięć. Zadanie, które uruchamia się co minutę i nie ma nic do zrobienia, prawie nic nie kosztuje.

Action Scheduler: kolejka WooCommerce

Action Scheduler to kolejka zadań w tle dostarczana razem z WooCommerce i używana także przez wiele innych wtyczek (subskrypcje, integracje księgowe, e-mail marketing). Każde zadanie jest działaniem z określonym czasem i statusem. Kolejka jest przetwarzana przez zadanie WP-Cron (action_scheduler_run_queue), więc i tu obowiązuje zasada: bez niezawodnego crona kolejka zalega.

Wszystko widać w WooCommerce > Status > Zaplanowane działania (Scheduled Actions). Są tam zakładki dla poszczególnych statusów:

Zgodnie z kodem źródłowym Action Scheduler domyślnie usuwa zakończone i anulowane działania po miesiącu, a nieudane po trzech miesiącach. Jeśli tabela mimo to szybko rośnie, prawdopodobnie wiele działań ciągle kończy się niepowodzeniem lub jest tworzonych od nowa. Zamiast tylko opróżniać tabelę, prosimy ustalić, która wtyczka je tworzy (pomocne są kolumna Grupa i nazwa hooka).

Przykład z praktyki w Theehuis Example: po zmianie hasła integracja z programem księgowym umieszczała każde zamówienie w kolejce jako nieudane działanie. Po tygodniu było 400 nieudanych działań i brakowało 60 faktur (lekcja 5.6). Po naprawieniu integracji administrator mógł ponownie uruchomić działania pojedynczo za pomocą Uruchom teraz (Run).

Staging dla sklepu

Czym jest staging, jak go utworzyć i jak go zabezpieczyć (hasło, noindex), opisano w kursie WordPress, w lekcji 8.3. W WebOké można to zrobić przez klonowanie w Installatron (DA 13.7, KB 232) i katalog chroniony hasłem (DA 15.9); inni dostawcy hostingu mają podobne narzędzia. W przypadku sklepu dochodzi do tego kilka kwestii, ponieważ kopia sklepu zawiera prawdziwe dane klientów i może wykonywać prawdziwe działania.

Bezpośrednio po sklonowaniu, zanim zrobią Państwo cokolwiek innego:

1. Operator płatności w trybie testowym, z kluczami testowymi. Staging z kluczami produkcyjnymi może przyjmować prawdziwe płatności lub wykonywać zwroty.
2. Poczta wyłączona lub przekierowana. W przeciwnym razie kopia wyśle potwierdzenia, przypomnienia i e-maile o porzuconym koszyku do prawdziwych klientów. Prosimy użyć wtyczki, która blokuje całą pocztę lub kieruje ją na jeden adres testowy.
3. Integracje i webhooki wyłączone. Księgowość, synchronizacja stanów magazynowych, etykiety wysyłkowe, e-mail marketing: w przeciwnym razie staging zaksięguje faktury lub nada paczki. Prosimy sprawdzić także WooCommerce > Ustawienia > Zaawansowane > Webhooki oraz klucze API.
4. Przejrzenie zaplanowanych działań. Kolejka została skopiowana. Oczekujące działania (e-mail z przypomnieniem, płatność za subskrypcję) w przeciwnym razie wykonają się na stagingu jeszcze raz.
5. Ograniczenie danych osobowych. Jeśli do testów nie potrzebują Państwo prawdziwych danych klientów, prosimy je usunąć lub zanonimizować na stagingu. Staging podlega RODO (GDPR) i często jest gorzej zabezpieczony (lekcja 5.5).

Najważniejsza zasada przy przywracaniu: nigdy nie należy nadpisywać bazą danych ze stagingu działającego sklepu. Między sklonowaniem a przywróceniem pojawiły się nowe zamówienia, klienci, zmiany stanów magazynowych i płatności; wtedy je Państwo utracą. Prosimy wprowadzić zmiany ponownie na wersji produkcyjnej (wiedzą już Państwo, że działają) albo synchronizować tylko pliki. Jeśli baza danych jest jednak konieczna, prosimy robić to wyłącznie w trybie konserwacji sklepu, bezpośrednio po świeżej kopii zapasowej i za pomocą narzędzia, które pomija zamówienia i klientów.

Testowanie aktualizacji na stagingu

Typowa ścieżka dla dużej aktualizacji WooCommerce lub wtyczki płatniczej:

1. Prosimy utworzyć świeży staging (klon wersji produkcyjnej) i ustawić pięć powyższych punktów.
2. Prosimy zaktualizować staging i wykonać aktualizację bazy danych, jeśli WooCommerce o to poprosi.
3. Prosimy złożyć zamówienie testowe w trybie testowym: płatność, niepowodzenie, zwrot (lekcja 4.5).
4. Prosimy sprawdzić w Zaplanowanych działaniach i w dzienniku błędów, czy pojawiły się nowe błędy.
5. Następnie prosimy zaktualizować wersję produkcyjną w spokojnym momencie, z kopią zapasową wykonaną tuż przedtem (lekcja 6.2).

Podsumowanie

• WooCommerce wykonuje wiele pracy w tle; odbywa się to przez WP-Cron i Action Scheduler.
• W sklepie zawsze prosimy używać prawdziwego zadania cron (co jedną do pięciu minut) zamiast WP-Cron uruchamianego przy odwiedzinach.
• Prosimy sprawdzać WooCommerce > Status > Zaplanowane działania: wiele zaległych oczekujących lub nieudanych działań oznacza, że cron lub integracja nie działa.
• Na stagingu: operator płatności w trybie testowym, poczta i integracje wyłączone, przejrzenie zaplanowanych działań, ograniczenie danych osobowych.
• Nigdy nie należy nadpisywać działającego sklepu bazą danych ze stagingu; zmiany prosimy wprowadzić ponownie na wersji produkcyjnej.

Quiz

Zadanie

Zadanie A7.3: Czy Państwa środowisko testowe (staging) jest zabezpieczone? To ta sama kontrola co zadanie A8.3 z kursu WordPress. Najpierw potrzebują Państwo potwierdzenia własności domeny (rekordu TXT _weboke-cursus.<domein> lub pliku /.well-known/weboke-cursus-<code>.txt z otrzymanym kodem). Następnie prosimy podać adres sklepu i adres stagingu (host w tej samej domenie). Program pobiera stronę główną stagingu, bez danych logowania, oraz stronę wersji produkcyjnej. Zielony, jeśli staging wymaga hasła (401) albo ma noindex i używa własnego adresu (punkt wejścia REST wskazuje na host stagingu), a wersja produkcyjna nie ma noindex. Pomarańczowy, jeśli staging ma noindex, ale nie ma hasła, lub nie ma ważnego certyfikatu. Czerwony, jeśli staging jest otwarty i indeksowalny, jeśli staging nadal wskazuje na adres wersji produkcyjnej lub jeśli wersja produkcyjna przez pomyłkę ma noindex.

Pytania do samodzielnej refleksji (niesprawdzane): czy operator płatności na Państwa stagingu jest w trybie testowym? Czy poczta jest wyłączona lub przekierowana? Czy integracje i webhooki są wyłączone? Ile oczekujących i nieudanych działań jest teraz w Zaplanowanych działaniach na wersji produkcyjnej?

Dalsza lektura

Te artykuły opisują kroki w panelach WebOké; w innych panelach działa to podobnie.

• Instrukcja DirectAdmin 15.1: Zadania Cron: automatyczne uruchamianie zadań
• Utworzenie zadania cron (oraz co zrobić, jeśli nie działa)
• Tworzenie środowiska testowego (staging) WordPress
• Instrukcja DirectAdmin 13.7: Klonowanie i tworzenie środowiska testowego (staging)
• Instrukcja DirectAdmin 15.9: Katalogi chronione hasłem
• Darmowy kurs WordPress 8.3: Staging: bezpieczne testowanie
• Darmowy kurs WordPress 6.3: Obrazy, PHP i inne sposoby na zwiększenie szybkości
• Action Scheduler (actionscheduler.org, po angielsku): https://actionscheduler.org/