Dodawanie niestandardowego kodu po zakończeniu zamówienia

W wersji Easy Digital Downloads 3.2.0 wprowadzono akcje after order actions, aby zastąpić przestarzałe akcje after payment actions. Ten hook zapewnia programistom sposób na wykonywanie intensywnych akcji po zakończeniu płatności, nie wpływając na szybkość i wydajność procesu zakupu przez użytkownika końcowego. To jest przewodnik, jak dodać akcję po zamówieniu.

Wprowadzenie do akcji po zamówieniu

Jeśli chcesz wykonać dodatkowe akcje po oznaczeniu zamówienia jako „zakończone”, zaleca się użycie hooka edd_after_order_actions zamiast hooka edd_complete_purchase. Jaka jest różnica między tymi dwoma hookami?

• edd_complete_purchase – Uruchamiany podczas procesu zakupu po kliknięciu przez użytkownika przycisku „Zakończ zakup” i przed załadowaniem strony „Potwierdzenie zakupu”. Ten hook powinien być używany do zadań „krytycznych dla misji”, ponieważ wpłynie na postrzegany czas potrzebny użytkownikowi na dokończenie zakupu. Przykłady użycia tego hooka to zadania takie jak tworzenie kluczy licencyjnych, generowanie subskrypcji lub wszystko, co użytkownik musi mieć widoczne na stronie paragonu.
• edd_after_order_actions – Uruchamiany około 30 sekund po zakończeniu zakupu, za pośrednictwem systemu WP_Cron. Ten hook powinien być używany do wykonywania dodatkowych wywołań API, kosztownych zapytań do bazy danych i zadań, które powinny być uważane za niekrytyczne dla użytkownika w celu dokończenia zakupu. Doskonałymi przykładami są dodawanie użytkowników do list mailingowych, obliczanie statystyk dla użytkownika, aktualizowanie pamięci podręcznej itp.

Jakie argumenty są przekazywane do hooka?

Hook edd_after_order_actions wysyła trzy argumenty:

• ID zamówienia jako liczba całkowita
• Obiekt EDD\Orders\Order
• Obiekt EDD_Customer

Jakie statusy zamówień są uwzględnione w „zakończonych”?

Easy Digital Downloads używa statusu complete do oznaczenia zamówienia jako zakończonego. Jeśli integrujesz się lub używasz rozszerzenia Recurring Payments, status edd_subscription jest również uważany za „zakończone” zamówienie. Jeśli chcesz uruchomić swoją akcję tylko dla pierwotnego zakupu (i zignorować odnowienia subskrypcji), będziesz musiał sprawdzić $order->status pod kątem wartości complete przed kontynuowaniem integracji.

Dlaczego to wymaga WP_Cron?

WP_Cron to proces w tle, którego używa Twoja witryna WordPress do wykonywania zadań bez wpływu na doświadczenie użytkownika podczas przeglądania witryny. Gdy na Twojej stronie generowany jest ruch, zanim strona się załaduje, WordPress określa, czy istnieją jakieś zadania w tle, które wymagają wykonania. Jeśli tak, uruchomi proces w tle, aby obsłużyć te oczekujące zadania.

Co jeśli mój hosting wyłączy WP_Cron?

Chociaż dokładamy wszelkich starań, aby wykryć, czy WP_Cron działa, może zdarzyć się przypadek, w którym nie będziemy w stanie prawidłowo tego wykryć. Jeśli Twój hosting lub serwer ma wyłączony WP_Cron lub zmodyfikowany do uruchamiania z określoną częstotliwością, może być konieczne ręczne wyłączenie tej funkcji. Istnieje filtr, jeśli zdecydujesz się nie używać haków po akcjach, w takim przypadku EDD powróci do wykonywania akcji w momencie zakończenia i uniknie opóźnionego procesu.

UWAGA: Ponieważ ten system po akcjach zamówienia jest zależny od WP_Cron, nie należy go używać do rzeczy uważanych za „krytyczne dla misji”. Jest to po prostu sposób na odciążenie kosztownych integracji z API i dużymi zestawami danych, które nie wpływają bezpośrednio na dane zakupu.

Kluczowe punkty dotyczące akcji po zamówieniu

• Wyzwalane przez WP_Cron
• Możliwość wyłączenia za pomocą filtra (edd_use_after_payment_actions)
• Domyślnie jest zaplanowane na 30 sekund po zakupie, ale można to zmienić za pomocą filtra.
• Tabela bazy danych zamówień zawiera kolumnę określającą czas ukończenia akcji.

Czy jest przykład?

Stworzyliśmy „szablon” do integracji z hakiem edd_after_order_actions w naszej bibliotece WP Code. Można go zobaczyć tutaj:

Migracja kodu z edd_after_payment_actions

Jeśli wcześniej integrowałeś się z hakiem edd_after_payment_actions, dobra wiadomość jest taka, że migracja do tego nowego, bardziej wydajnego haka jest całkiem łatwa.

Główna różnica polega na zmianie drugiego parametru. Zamiast przesyłania płatności jako obiektu EDD_Payment, będzie przesyłany obiekt Order.