¶ Walidacja formularzy - błędy widoczne od razu, mniej porzuconych zamówień
Walidacja formularzy w Hummerce sprawdza dane, które klient wpisuje w rejestracji, koncie, adresie, zamówieniu, kontakcie, newsletterze i zwrocie - najpierw w przeglądarce, na bieżąco, a potem ponownie w sklepie po wysłaniu. Dzięki temu klient poprawia błąd w miejscu, w którym go popełnił, a do sklepu trafiają dane, z którymi da się pracować: poprawny e-mail, telefon, kod pocztowy czy zaakceptowany regulamin.
Stan na wersję Hummerce 2.35 (ostatnie zmiany w module: 2.35.21), aktualizacja 2026-09-28.
¶ Korzyści i zastosowania
- Klient poprawia błąd od razu, w miejscu, w którym go zrobił - bez ponownego ładowania strony i bez utraty wpisanych danych.
- Mniej zamówień z błędnym telefonem albo kodem pocztowym - mniej telefonów do klientów i zwrotów przesyłek.
- Sklep sam oznacza pole jako wymagane albo dodaje prostą regułę (długość, wzór) w ustawieniach parametru - bez zlecenia programistycznego.
- Treść komunikatów sklep zmienia sam w Edytorze komunikatów, np. żeby dopasować ton do marki.
- Błędy są oznaczone także dla czytników ekranu, co pomaga spełnić wymagania dostępności formularzy - zob. Dostępność cyfrowa.
¶ Jak to wygląda
Zrzuty ze sklepu demonstracyjnego Hummerce (szablon Bootstrap 5).
¶ Rejestracja - błędy w trakcie wpisywania
¶ Zamówienie - wysłanie pustego formularza
¶ Zamówienie - błędny e-mail, telefon i kod pocztowy
¶ Zasady działania
¶ Kiedy i gdzie jest sprawdzane pole
¶ W przeglądarce (szablon Bootstrap 5)
- Pole jest sprawdzane przy każdej zmianie - w trakcie wpisywania. Pola wyboru (zgody, listy) - po zaznaczeniu lub zmianie.
- Po kliknięciu przycisku wysyłki formularz sprawdza wszystkie widoczne pola. Przy błędzie formularz nie jest wysyłany.
- Komunikat pojawia się pod polem, a pole ma czerwoną ramkę. Poprawnie wypełnione pole ma zieloną ramkę.
- Błędne pole jest oznaczone także dla czytnika ekranu, a komunikat jest z polem powiązany - czytnik odczytuje go razem z nazwą pola (zob. Dostępność cyfrowa).
- Gdy w formularzu zostają puste pola wymagane, przycisk wysyłki jest nieaktywny, dopóki klient ich nie uzupełni.
- Sklep nie przewija strony i nie przenosi kursora do pierwszego błędnego pola - klient widzi oznaczenia przy polach.
- Pola firmy (nazwa firmy, NIP) są sprawdzane tylko wtedy, gdy klient wybierze zakup lub konto Firma.
¶ Reguły w przeglądarce
| Pole | Co jest sprawdzane |
|---|---|
| Pola wymagane (oznaczone *) | nie mogą być puste |
| E-mail, login | poprawna budowa adresu e-mail |
| Hasło i jego powtórzenie | zgodność obu haseł |
| Telefon (kupującego i dostawy) | tylko cyfry, bez spacji i znaku +; dla Polski dokładnie 9 cyfr |
| Kod pocztowy (kupującego i dostawy) | dla Polski format 00-000; dla innych krajów tylko wypełnienie |
| Regulamin i zgody obowiązkowe | muszą być zaznaczone |
| Pola z własną regułą w parametrze | długość, wzorzec, zakres - zob. niżej |
| reCAPTCHA (gdy włączona) | wymagana przed wysłaniem |
¶ Skąd biorą się reguły
- Parametr pola - w panelu, w ustawieniach parametru:
- Pole obowiązkowe - pole ma gwiazdkę i musi być wypełnione w formularzu,
- Walidacja - dodatkowa reguła wpisana w postaci atrybutów pola, np.
minlength="6" maxlength="30"albopattern="[0-9]{2}-[0-9]{3}", - Format danych - podpowiedź w pustym polu, np. przy kodzie pocztowym.
- Szablon sklepu - reguły wspólne dla formularzy: e-mail, hasło, telefon i kod pocztowy wg kraju, regulamin. Ich zmiana wymaga wdrożenia.
- Typ pola - pole e-mail sprawdza budowę adresu.
- Które pola są w formularzu i w jakiej kolejności - decydują lokacje parametrów (Parametry i lokacje).
¶ Po wysłaniu - w sklepie (serwer)
- Sklep sprawdza dane ponownie, niezależnie od przeglądarki. Gdy coś się nie zgadza, formularz wraca z komunikatem przy polu (albo nad formularzem) i z danymi, które klient już wpisał.
- W standardowej konfiguracji sklep sprawdza m.in.:
- rejestrację i dane konta - imię, nazwisko, telefon, ulicę, kod pocztowy, miasto; format e-maila, telefonu, kodu pocztowego i NIP; zgodność obu haseł i minimalną siłę hasła; czy konto o tym loginie już istnieje; przy koncie firmowym - nazwę firmy i NIP razem,
- zamówienie - dane kupującego i adres dostawy, e-mail gościa, zgodność sposobu dostawy i płatności z koszykiem i krajem, dostępne ilości towarów, termin dostawy (gdy sklep go używa),
- książkę adresową - imię, nazwisko, ulicę, kod pocztowy, miasto i kraj adresu (zob. Książka adresowa),
- formularz kontaktowy - imię, nazwisko, e-mail oraz załączniki (wymagalność, rozmiar), gdy formularz je ma,
- newsletter - adres e-mail i zgodę,
- zwrot - wybrane pozycje i ilości, oświadczenie o odstąpieniu, numer IBAN przy zwrocie przelewem (zob. Zwroty - odstąpienie od umowy).
- NIP - sklep sprawdza jego format. Dane firmy po numerze NIP pobiera z GUS, a numer VAT UE sprawdza w VIES - zob. Dane firmy z GUS i VIES i Konta firmowe B2B.
- Reguły w przeglądarce i na serwerze ustawiamy tak, żeby się uzupełniały: przeglądarka podpowiada, serwer ma ostatnie słowo. Przy zmianie wymagalności pola zmieniamy oba miejsca.
¶ reCAPTCHA
Formularze rejestracji, logowania, zamówienia, kontaktu, newslettera i zwrotu mogą być chronione reCAPTCHA Google (wersja 2 albo 3). reCAPTCHA jest sprawdzana w przeglądarce przed wysłaniem i ponownie w sklepie - konfiguracja w ustawieniach bezpieczeństwa.
¶ Bootstrap 5 i Bootstrap 4
| Element | BS5 | BS4 |
|---|---|---|
| Sprawdzanie przy wpisywaniu i przed wysłaniem | tak | tak |
| Komunikat pod polem, kolor ramki | tak | tak |
| Błędne pole oznaczone dla czytnika ekranu | tak | nie |
| Przewinięcie do pierwszego błędu po powrocie z błędami | nie | tak |
| Powtórzenie hasła sprawdzane w przeglądarce | tak | nie - dopiero po wysłaniu |
| E-mail adresu dostawy wymagany w przeglądarce | tak | nie |
| Reguła z parametru (Pole obowiązkowe, Walidacja) | tak | tak |
¶ Wersja
- Walidacja w szablonie Bootstrap 5 działa od wersji 2.33, razem z samym szablonem.
- Sprawdzanie danych po wysłaniu (na serwerze) jest częścią platformy we wszystkich wersjach.
- Ostatnie zmiany w module: wersja 2.35.21.
¶ Zależności
- Szablon Bootstrap 5 w aktualnej wersji. W Bootstrap 4 walidacja działa, ale bez części elementów - zob. porównanie wyżej.
- Pola formularzy to parametry w lokacjach - zob. Parametry i lokacje.
- reCAPTCHA wymaga kluczy Google w konfiguracji sklepu (ustawienia bezpieczeństwa).
- Siła hasła - ustawienia w konfiguracji bezpieczeństwa haseł.
- Pobieranie danych firmy po NIP - moduł GUS (Dane firmy z GUS i VIES).
¶ Wdrożenie
- Działa po aktualizacji - walidacja jest częścią szablonu Bootstrap 5 i platformy. Wdrożenie jest potrzebne, gdy sklep chce zmienić reguły, których nie ustawi w parametrze. Zakres:
- zmiana reguł wspólnych w szablonie, np. telefon z numerem kierunkowym, kody pocztowe innych krajów, NIP zagraniczny,
- zmiana listy pól wymaganych i formatów sprawdzanych po wysłaniu - spójnie z regułami w przeglądarce,
- reguły zależne od innych pól (kraj, konto firmowe, sposób dostawy),
- komunikaty i tłumaczenia nowych reguł,
- testy formularzy rejestracji, konta, adresu i zamówienia.
- Minimalny szacowany czas:
- szablon Bootstrap 5 - od 3 h,
- szablon Bootstrap 4 - od 4 h.
- Czas konkretnego wdrożenia zależy od jego zakresu - wyceniamy go indywidualnie.
- Od czego zależy czas:
- liczba formularzy i pól objętych zmianą,
- reguły zależne od kraju - liczba krajów sprzedaży,
- szablon (BS5, BS4, indywidualny) i stopień indywidualizacji formularzy,
- liczba języków,
- wersja sklepu - aktualizacja wyceniana osobno.
¶ Ograniczenia
- Reguły wspólne (telefon, kod pocztowy, hasło, e-mail) są zapisane w szablonie - sklep nie zmieni ich w panelu.
- Telefon w przeglądarce przyjmuje tylko cyfry - bez spacji, myślników i numeru kierunkowego z
+. Klienci zagraniczni wpisują numer bez znaku+. - Format kodu pocztowego w przeglądarce jest sprawdzany tylko dla Polski. Dla innych krajów przeglądarka sprawdza wyłącznie, czy pole jest wypełnione - sprzedaż zagraniczna wymaga dopasowania reguł (wdrożenie).
- NIP jest sprawdzany tylko pod względem formatu, bez sumy kontrolnej. Poprawność firmy potwierdza GUS lub VIES, gdy sklep ma ten moduł.
- Ustawienie Pole obowiązkowe w parametrze działa w formularzu w przeglądarce. Żeby sklep sprawdzał pole także po wysłaniu, pole musi być w regułach formularza po stronie serwera - to zmiana we wdrożeniu.
- Reguły w przeglądarce i na serwerze nie są w pełni identyczne - dopracowuje się je razem przy wdrożeniu, żeby przeglądarka i sklep akceptowały te same dane.
- Po błędzie kursor nie przechodzi sam do pierwszego błędnego pola, a strona się nie przewija.
- Ogólne komunikaty biblioteki walidacji ("pole nie może być puste", "poprawny adres e-mail") nie są w Edytorze komunikatów.
- Formularz logowania nie ma podpowiedzi w przeglądarce - błędne dane sklep zgłasza po wysłaniu.
- Formularz kontaktowy nie sprawdza w przeglądarce budowy adresu e-mail - tylko wypełnienie pól wymaganych.
- Nie weryfikujemy konfiguracji pod kątem zgodności z prawem - to sklep decyduje, które zgody są obowiązkowe, jakie dane zbiera w formularzach i jak informuje o ich przetwarzaniu (RODO, regulamin).
¶ Potencjał rozwoju
- Przeniesienie kursora do pierwszego błędnego pola i przewinięcie do niego po wysłaniu formularza.
- Numer telefonu w formacie międzynarodowym (z numerem kierunkowym) i reguły kodu pocztowego dla kolejnych krajów.
- Sprawdzanie sumy kontrolnej NIP w przeglądarce.
- Jedno źródło reguł dla przeglądarki i serwera - wymagalność ustawiona w parametrze sprawdzana także po wysłaniu.
- Reguły formularzy po stronie serwera do edycji w panelu.
- Podpowiedzi w formularzu logowania i sprawdzanie adresu e-mail w formularzu kontaktowym.
¶ Najczęstsze pytania
Czy klient widzi błąd w formularzu, zanim go wyśle?
Tak. W szablonie Bootstrap 5 pole jest sprawdzane na bieżąco, w trakcie wpisywania, a komunikat pojawia się pod polem z czerwoną ramką.
Czy sklep sprawdza dane także po stronie serwera, nie tylko w przeglądarce?
Tak. Każde zgłoszenie formularza jest sprawdzane ponownie w sklepie, niezależnie od przeglądarki klienta - tego sprawdzenia klient nie pominie.
Czy można dodać własną regułę do pola bez zlecenia programistycznego?
Częściowo. Sklep sam ustawi pole jako wymagane albo doda prostą regułę długości lub wzorca w ustawieniach parametru. Reguły wspólne dla wszystkich formularzy, np. format telefonu, są zapisane w szablonie i wymagają wdrożenia.
Czy walidacja działa tak samo w starszym szablonie Bootstrap 4?
Częściowo. Podstawowe sprawdzanie działa w obu szablonach, ale Bootstrap 5 dodatkowo oznacza błędne pola dla czytników ekranu i sprawdza w przeglądarce więcej pól - zob. porównanie w sekcji Zasady działania.
Ile trwa zmiana reguł walidacji w formularzu?
Najprostsza zmiana, np. nowy wzorzec pola - od 3 h w szablonie Bootstrap 5, od 4 h w Bootstrap 4.
Czy przeglądarka i sklep zawsze sprawdzają dane tak samo?
Nie zawsze. Reguły w obu miejscach są utrzymywane osobno - przy zmianie wymagalności pola trzeba zaktualizować oba miejsca, inaczej klient może zobaczyć błąd dopiero po wysłaniu formularza.
¶ Powiązane
- Dostępność cyfrowa - oznaczenia błędów dla czytników ekranu.
- Parametry i lokacje, Dane firmy z GUS i VIES, Konta firmowe B2B, Zwroty - odstąpienie od umowy.
- Sprzedaż B2C - formularze rejestracji i zamówienia to część ścieżki zakupowej klienta.
Chcesz sprawdzić, jak walidacja formularzy działa w Waszym sklepie? Umów bezpłatną prezentację.
¶ Szczegóły konfiguracji
¶ Dostęp w panelu
- Parametry: ustawienia parametru - Pole obowiązkowe, Walidacja, Format danych, Opis (podpowiedź przy polu).
- Lokacje parametrów: które pola są w formularzach rejestracji, konta, zamówienia, newslettera i kontaktu (Parametry i lokacje).
- Konfiguracja: ustawienia reCAPTCHA i siły hasła (ustawienia bezpieczeństwa).
¶ REST API i MCP
Reguły sprawdzane po wysłaniu formularza (na serwerze) nie są dostępne w panelu ani przez REST API czy asystenta AI (MCP) - to konfiguracja zmieniana przy wdrożeniu.
¶ Komunikaty sklepu
Komunikaty walidacji zmienia się w Edytorze komunikatów, a wymagalność pól i własne reguły - w ustawieniach parametru (Parametry i lokacje). Wartości domyślne są po polsku i po angielsku, chyba że w tabeli zaznaczono inaczej. Ogólne komunikaty biblioteki walidacji (np. "pole nie może być puste") nie są w Edytorze komunikatów, a ich zmiana wymaga wdrożenia.
¶ Formularze - w przeglądarce
| Klucz | Wartość domyślna |
|---|---|
error.incorrectLoginFormat |
Login niepoprawny. Login musi być poprawnym adresem e-mail. |
error.incorrectEmailFormat |
Podano niepoprawny adres e-mail. |
error.passwordsDoNotMatch |
Hasła nie pokrywają się |
error.must.accept |
Akceptacja regulaminu jest wymagana. |
error.formvalidation.phone.integer |
Dozwolone są tylko cyfry |
error.formvalidation.phone.max |
Sprawdź, czy numer składa się z 9 cyfr |
error.formvalidation.postcode.format |
Wpisz kod pocztowy w formacie xx-xxx |
msg.forms.reCaptcha.required |
reCaptcha jest wymagana! |
¶ Formularze - po wysłaniu
| Klucz | Wartość domyślna |
|---|---|
error.nofield |
Pole {0} jest wymagane. |
error.minLength |
Pole {0} musi mieć przynajmniej {1} znaków. |
error.maxLength |
Pole {0} nie może mieć więcej niż {1} znaków. |
error.syntaxError |
Pole {0} ma nieprawidłową składnię. |
error.diffpasswords |
Podane hasła różnią się. |
error.password.weak |
Podane hasło jest za słabe, wybierz trudniejsze. |
error.incorrectLoginSyntax.customer |
Nieprawidłowa składnia loginu |
error.existingUser.customer |
Klient o loginie {0} już istnieje, wybierz inny login. |
error.recaptcha.invalid |
Weryfikacja reCAPTCHA nie powiodła się. |
msg.general.errorsMessage |
Formularz zawiera błędy, które zostały wymienione poniżej: |
msg.general.requiredFields |
pola są wymagane |
{0}to nazwa pola (nazwa parametru), a{1}- liczba znaków.
¶ Siła hasła
| Klucz | Wartość domyślna (EN) |
|---|---|
msg.passwordStrength.tooShort |
Password is too short |
msg.passwordStrength.digit |
Password should contain at least one digit |
msg.passwordStrength.uppercaseLetter |
Password should contain at least one uppercase letter |
msg.passwordStrength.lowercaseLetter |
Password should contain at least one lowercase letter |
msg.passwordStrength.specialCharacter |
Password should contain at least one special character |
msg.passwordStrength.custom |
Password is too weak |
¶ Newsletter i zwroty
| Klucz | Wartość domyślna |
|---|---|
error.newsletter.emailIsEmpty |
Pole e-mail jest puste. Podaj poprawny adres e-mail i spróbuj ponownie. |
error.newsletter.wrongEmailFormat |
Adres email jest niepoprawny lub ma niepoprawny format. |
error.return.noItems |
Zaznacz przynajmniej jedną pozycję do zwrotu. |
error.return.agreementRequired |
Musisz zaakceptować oświadczenie o odstąpieniu. |
error.return.ibanRequired |
Podaj numer IBAN do zwrotu przelewem bankowym. |
error.return.ibanInvalid |
Podany numer IBAN jest nieprawidłowy. |
¶ Parametry
| Symbol | Obiekt | Etykieta |
|---|---|---|
_mandatory |
parametr | Pole obowiązkowe |
_validation |
parametr | Walidacja |
_format |
parametr | Format danych |