Klient składa zamówienie i chce wskazać konkretny dzień dostawy. Niby prosta sprawa: jedno pole, kalendarz i po temacie. Tyle że sklep nie powinien obiecywać terminu, którego nie potrafi później dowieźć. Sam wybór daty to jeszcze nie rezerwacja, nie potwierdzenie i nie magiczny kalendarz, który zna obłożenie firmy, dni wolne oraz możliwości logistyczne.

WooCommerce 11.2.0 wprowadza obsługę pól typu date w Additional Checkout Fields API dla Checkout Block. Można więc zbierać preferowaną datę dostawy, ograniczyć zakres wyboru i skorzystać z natywnego kalendarza przeglądarki, także na telefonie. Trzeba tylko wiedzieć, co ta funkcja faktycznie robi, a czego nie robi. Poniżej przechodzimy przez wdrożenie, ograniczenia i testy bez technicznego dymu.

Co właściwie daje pole daty dostawy w WooCommerce 11.2?

W WooCommerce 11.2.0 pole daty może służyć do zebrania od klienta informacji: „Najlepiej dostarczcie moje zamówienie tego dnia”. To przydatne, gdy termin ma znaczenie dla odbiorcy, a sklep chce mieć tę preferencję zapisaną razem z zamówieniem. Klient wybiera dzień albo wpisuje go w polu, a wartość trafia do danych zamówienia.

Ważne: opisywana funkcja dotyczy Checkout Block i wdrożenia przez Additional Checkout Fields API. Nie jest to uniwersalny przełącznik, który automatycznie pojawi się w każdym sklepie WooCommerce. Research nie potwierdza też identycznego działania w klasycznym checkoutcie opartym na shortcode. Najpierw trzeba więc sprawdzić, z jakiego checkoutu korzysta sklep.

Preferowana data to nie obietnica dostawy

Największa mina jest prosta do opisania: klient wybiera datę, a sklep traktuje ją jak zatwierdzony termin. Tymczasem pole zbiera preferencję. Nie sprawdza samo z siebie obłożenia firmy, dostępności kuriera, dni wolnych ani wyjątków logistycznych. Nie rezerwuje terminu i nie podejmuje za zespół decyzji, czy zamówienie rzeczywiście da się wtedy przygotować i dostarczyć.

Dlatego komunikat przy polu powinien być zrozumiały. Jeśli sklep może dopiero potwierdzić wybrany dzień, warto mówić o preferowanej dacie, a nie o gwarantowanej dostawie. To mała różnica w tekście, ale duża różnica w oczekiwaniach klienta.

Jak dodać pole daty dostawy w Checkout Block

Od strony technicznej dodatkowe pole rejestruje się przez funkcję woocommerce_register_additional_checkout_field(). Właściciel sklepu nie musi znać kodu na pamięć, ale powinien wiedzieć, co osoba wdrażająca ma skonfigurować. To nie jest kwestia zaznaczenia jednej opcji w każdym panelu. Potrzebne jest wdrożenie przez API albo rozwiązanie, które z tego API korzysta.

Podstawą jest pole typu date. Do tego dochodzi unikalne id, etykieta widoczna dla klienta oraz lokalizacja. Dla preferowanej daty dostawy sensowna jest lokalizacja order, czyli sekcja informacji o zamówieniu. Wartość zostaje wtedy zapisana przy konkretnym zamówieniu, a nie jako element zapisanych danych adresowych klienta.

Można również określić, czy pole ma być wymagane. Ustawienie required na true oznacza, że klient będzie musiał podać datę, aby przejść dalej. Czy to dobry pomysł? Zależy od procesu sklepu. Jeśli data jest tylko opcjonalną wskazówką, wymaganie jej od każdego kupującego może niepotrzebnie utrudnić zakup. Jeśli sklep bez tej informacji nie potrafi obsłużyć zamówienia, obowiązkowość może mieć sens, ale trzeba ją przetestować w całym checkoutcie.

Co powinno znaleźć się w konfiguracji pola

• Typ pola: date, czyli dzień bez godziny.
• Unikalny identyfikator: potrzebny do rozpoznania pola w zamówieniu i dalszej obsłudze.
• Etykieta: jasna informacja, że klient wybiera preferowaną datę dostawy.
• Lokalizacja: order, aby wartość była związana z informacjami o zamówieniu.
• Wymagalność: ustawiana zależnie od procesu sklepu, a nie z automatu.

Samo wyświetlenie pola nie wystarczy. Trzeba jeszcze sprawdzić, czy wybrana wartość trafia do miejsc, w których pracuje zespół: szczegółów zamówienia, wiadomości e-mail oraz ewentualnych integracji.

Od jutra, nie od wczoraj: ograniczanie zakresu dat

Jeśli klient ma wybierać tylko realne terminy, pole daty można ograniczyć przez opcje min i max. Pozwalają one określić początek i koniec zakresu. Można wskazać konkretną datę w formacie YYYY-MM-DD albo użyć okresu względnego, zależnego od bieżącego dnia.

Przykładowo zakres może zaczynać się od jutra i kończyć maksymalnie 30 dni później. W dokumentacji jako przykłady pojawiają się okresy P1D oraz P30D. Pierwszy oznacza od jutra, drugi maksymalnie 30 dni od dziś. Przy datach zależnych od aktualnego dnia nie należy samodzielnie wyliczać konkretnej daty w momencie rejestracji pola. Lepiej przekazać okres względny, aby WooCommerce ocenił go podczas wyświetlania i wysyłania formularza.

Tu warto zachować czujność. Jeśli ograniczenia min i max stworzą nieprawidłowy zakres, WooCommerce może pominąć te ograniczenia i zapisać ostrzeżenie w logach. W efekcie właściciel sklepu może zobaczyć szerzej otwarty wybór, niż planował. Zakres trzeba więc sprawdzić nie tylko oczami w kalendarzu, ale także podczas walidacji formularza.

Zakres dat a kalendarz dostaw

Zakres od-do nie jest pełnym kalendarzem dostaw. Min i max powiedzą: „wybierz dzień między tym początkiem a tym końcem”. Nie oznaczają automatycznego wykluczania sobót, świąt, dni wolnych, konkretnych dni tygodnia ani terminów, które są już zajęte.

Jeśli sklep potrzebuje takich reguł, potrzebna będzie osobna logika albo rozwiązanie, które je obsługuje. Dotyczy to także limitu zamówień na dzień, obłożenia firmy i wyjątków logistycznych. Samo pole date nie wie, ile zamówień zespół ma już na dany termin. I całe szczęście, bo formularz nie prowadzi magazynu ani grafiku pracy.

Czy pole daty działa na telefonie?

Tak, pole korzysta z natywnego date pickera przeglądarki. WooCommerce opisuje również mobilne kontrolki dostępne w przeglądarce, więc klient może wybrać datę na telefonie bez konieczności korzystania z rozbudowanego, osobnego kalendarza dodanego przez sklep.

Dokładny wygląd kontrolki może zależeć od urządzenia, systemu i przeglądarki. Na jednym telefonie pojawi się określony kalendarz, na innym interfejs może wyglądać inaczej. To normalne przy natywnych kontrolkach. Nie warto obiecywać identycznego wyglądu na każdym ekranie.

Kalendarz wygląda lokalnie, zapis jest uporządkowany

Użytkownik może widzieć datę zgodnie z ustawieniami lokalnymi przeglądarki. WooCommerce zapisuje jednak wartość w bazie w uporządkowanym formacie YYYY-MM-DD. To ważne, bo wygląd daty na ekranie nie musi być taki sam jak sposób jej przechowywania.

Wdrożenie trzeba sprawdzić na realnym telefonie, a nie tylko w widoku mobilnym komputera. Warto wybrać poprawną datę, sprawdzić datę spoza zakresu i zobaczyć, czy formularz poprawnie reaguje na oba przypadki.

Co dzieje się z wybraną datą po złożeniu zamówienia?

Jeśli pole ma lokalizację order, jego wartość jest zapisywana przy zamówieniu. Nie staje się elementem zapisanych danych adresowych klienta. To logiczne: preferowana data dotyczy konkretnego zakupu, a nie stałego adresu przypisanego do osoby.

Wartość w bazie ma format YYYY-MM-DD. W szczegółach zamówienia, wiadomościach e-mail i innych miejscach renderowania data może być jednak prezentowana zgodnie z formatem ustawionym dla witryny. Zespół może więc zobaczyć ją w formie przyjaznej dla użytkownika, choć pod spodem pozostaje uporządkowana wartość kalendarzowa.

Data musi trafić do procesu, nie tylko do formularza

Najczęstszy błąd przy takich wdrożeniach? Test kończy się na zdaniu: „Pole widać, działa”. To dopiero połowa roboty. Osoba obsługująca zamówienie musi znaleźć wybraną datę. Trzeba sprawdzić panel zamówienia, wiadomości e-mail oraz integracje wykorzystywane przy realizacji.

Dotyczy to także bramki płatniczej, wtyczek kurierskich, integracji magazynowych i innych rozszerzeń checkoutu. Pole może poprawnie wyświetlać się klientowi, ale jego wartość niekoniecznie będzie automatycznie wykorzystywana przez każde dodatkowe narzędzie. Dlatego test powinien przejść przez cały proces: wybór daty, złożenie zamówienia, płatność, odczyt w panelu i sprawdzenie komunikacji do zespołu.

Najczęstsza mina: wybrana data nie oznacza dostawy potwierdzonej

Wybór dnia przez klienta jest informacją dla sklepu. Nie jest automatycznym potwierdzeniem, że paczka dotrze właśnie wtedy. Pole nie kontroluje samo z siebie dni wolnych, świąt, obłożenia firmy, możliwości przewoźnika ani nietypowych sytuacji.

Sklep powinien ustalić, kto sprawdza wybraną datę i co dzieje się, gdy realizacja nie jest możliwa. Bez takiego procesu klient może dostać w formularzu poczucie pewności, którego sklep nie jest w stanie spełnić. Lepiej jasno rozdzielić preferencję od potwierdzenia niż później tłumaczyć, że kalendarz był tylko sugestią.

Co warto ustalić przed publikacją pola

• Jaki zakres dat rzeczywiście odpowiada możliwościom firmy.
• Kto sprawdza wybraną datę po złożeniu zamówienia.
• Jak obsługiwane są dni niedostępne, wyjątki i zmiany terminu.
• Gdzie zespół odczytuje preferencję klienta.
• Jak komunikowana jest różnica między preferowaną datą a potwierdzonym terminem.

Jeśli sklep potrzebuje dostawy na konkretny dzień i godzinę, trzeba pamiętać, że opisywane pole dotyczy daty kalendarzowej bez komponentu czasu. Dzień to nie to samo co przedział godzinowy.

Bezpieczne wdrożenie bez rozwalenia checkoutu

WooCommerce 11.2.0 zawiera także poprawki bezpieczeństwa, ale aktualizacja produkcyjnego sklepu nadal wymaga przygotowania. Nowe pole może być przydatne, jednak nie warto wrzucać go na żywy checkout bez sprawdzenia zgodności reszty środowiska.

Przed aktualizacją wykonaj kopię zapasową plików i bazy. Następnie przetestuj zmianę na kopii stagingowej. Sprawdź motyw, bramkę płatniczą, wtyczki kurierskie, integracje magazynowe i inne rozszerzenia checkoutu. Szczególnie ważne jest to, czy data nie ginie po drodze i czy nie psuje walidacji formularza.

Krótka checklista przed publikacją

1. Wykonaj kopię zapasową plików oraz bazy danych.
2. Sprawdź zmianę na środowisku stagingowym.
3. Potwierdź, że sklep korzysta z Checkout Block.
4. Przetestuj poprawną datę oraz datę spoza zakresu min i max.
5. Sprawdź wybór daty na realnym telefonie.
6. Zobacz, jak data wygląda w panelu zamówienia i wiadomościach e-mail.
7. Zweryfikuj płatność oraz działanie istotnych integracji.
8. Ustal, kto obsługuje preferencję i wyjątki logistyczne.

Po wdrożeniu nie kończ testów na samym kalendarzu. Sprawdź również walidację po stronie formularza, bo ograniczenie widoczne w przeglądarce nie powinno być jedynym zabezpieczeniem. Jeśli konfiguracja zakresu jest błędna, trzeba to zauważyć zanim klient zacznie wybierać daty, których sklep nie jest w stanie obsłużyć.

Pole daty dostawy w Checkout Block WooCommerce 11.2 może uporządkować zbieranie preferencji klienta i ograniczyć wybór do określonego przedziału. Nie tworzy jednak samo z siebie kalendarza dostępności, nie wyklucza automatycznie świąt i nie potwierdza terminu doręczenia. Najważniejsze jest połączenie konfiguracji z realnym procesem obsługi zamówień, testem na telefonie oraz sprawdzeniem integracji. Masz stronę, sklep albo materiały graficzne, które proszą się o ogarnięcie? Napisz do INB Marketing i zobaczymy, co da się z tym sensownie zrobić.