Kontakt forma ne radi? Evo kako da zaista utvrdite zašto

"Moja kontakt forma ne radi" obično znači jednu od otprilike šest stvari, a nagađanje koja od njih troši više vremena nego provera. Ispravan pristup je da prođete kroz uzroke po redosledu verovatnoće, počevši od onoga što vam u najkraćem vremenu daje najviše informacija: šta se zapravo desilo sa zahtevom kada je napustio pregledač.

1. Proverite šta je zahtev zapravo uradio

Otvorite stranicu, otvorite devtools, pređite na tab Network i sami pošaljite formu. Dve stvari ovde stalno pucaju:

• action URL je pogrešan - pogrešno otkucan API ključ, URL kopiran sa stare forme koji nikad nije ažuriran, ili (neugodno često) i dalje pokazuje na localhost iz lokalnog razvoja i nikad nije prebačen na produkciju.
• Zahtev ode, ali se vrati sa statusom greške. Ne morate znati tačno značenje svakog koda - odgovor 4xx ili 5xx je dovoljan da znate da je problem na strani primaoca, a ne u vašem HTML-u.

Ako se zahtev uopšte ne šalje, ili ide na domen koji očigledno nije vaš form backend, to je bug, pronađen za manje od minuta - pre nego što uopšte počnete da tražite igde drugde.

2. Potvrdite da se zaista šalje kao POST

<form> bez eksplicitnog method="POST" podrazumevano koristi GET, koji vaša polja dodaje URL-u kao query string umesto da pošalje telo zahteva - endpoint form backenda to obično neće prihvatiti kao pravi unos. Prvo proverite sam tag.

Ako se forma šalje preko JavaScript-a umesto native POST metode pregledača, češći problem je handler koji poziva e.preventDefault() da zaustavi podrazumevanu navigaciju, a onda zapravo ništa ne šalje - pokvaren fetch poziv, greška u kucanju endpointa unutar handlera, ili tihi prevremeni return. preventDefault() bez funkcionalnog zahteva iza njega za posetioca je nerazlučiv od mrtve forme: stranica prosto... ne radi ništa.

3. Isključite konzolu, ne samo mrežu

Za bilo koji unos zasnovan na fetch-u, otvorite tab Console pored Network-a. CORS greška, blokiran mixed-content zahtev (slanje na http:// sa stranice na https://), ili neuhvaćena izuzetak (exception) unutar submit handlera - svaki od ovih potpuno zaustavlja zahtev, i nijedan od njih ne proizvodi vidljivu grešku za posetioca. Sve to izgleda kao tišina, tačno onako kako pokvarena forma izgleda spolja.

4. Proverite gde je obaveštenje zapravo završilo

Ako se zahtev iz koraka 1 vratio sa statusom uspeha, unos je stigao do backenda - preostalo pitanje je samo gde je otišlo obaveštenje. Prvo proverite fascikle za spam i promocije; to je daleko najčešći razlog zašto "nestalo" obaveštenje zapravo nije nestalo. Ako šaljete sa prilagođenog verifikovanog domena umesto podrazumevanog pošiljaoca, pogrešno podešen SPF ili DKIM zapis dovešće do toga da imejlove tiho filtrira ili odbije mejl server primaoca - što sa vaše strane izgleda potpuno isto kao "ništa nije poslato".

5. Razmotrite tihо odbijanje - ograničenje broja zahteva i pokvaren honeypot

Legitimni unosi se povremeno tretiraju kao sumnjivi. Ponovljeno brzo testiranje sa iste IP adrese tokom debagovanja je tačno onaj obrazac koji ograničenje broja zahteva treba da uhvati, i može da se aktivira bez ikakve zlonamerne namere sa vaše strane. Sačekajte nekoliko minuta i probajte ponovo pre nego što pretpostavite da je nešto pokvareno.

Suptilniji i zaista čest bug: honeypot polje. Većina zaštite od spama uključuje skriveno polje koje pravi posetioci nikad ne vide niti popunjavaju - ako ga popuni bot, unos se tiho odbacuje. CSS regresija (preimenovana klasa, stylesheet koji se ne učita, promena rasporeda koja "otkrije" pogrešan element) može učiniti to polje vidljivim pravim korisnicima, koji se onda ili zbune zbog dodatnog polja, ili - gore - dobiju ga automatski popunjeno od strane menadžera lozinki, što aktivira isti filter namenjen botovima. Ako su unosi počeli da otkazuju odmah posle redizajna ili CSS promene, to je prva stvar koju treba proveriti.

Proverite dashboard, ne samo svoj inbox

Opšta pouka iz svega navedenog: "da li sam dobio imejl" nije isto pitanje kao "da li je unos stigao", i mešanje ta dva je razlog zašto ovakav bug traje danima umesto minuta da se pronađe. Kod Formhooka, svaki unos koji zaista stigne do backenda pojavljuje se na dashboardu bez obzira na to da li je imejl sa obaveštenjem isporučen - tako da je prva korisna provera, pre svih koraka iznad, jednostavno da se prijavite i pogledate. Ako je unos tu, problem je na strani obaveštenja (koraci 4-5). Ako nije, problem je uzvodno, pre nego što je zahtev uopšte stigao do backenda (koraci 1-3).

Vredi raditi redovno, ne samo kad nešto pukne: kontrolna lista za testiranje pre lansiranja pokriva onaj petnaestominutni prolaz koji uhvati većinu ovoga pre nego što na to naiđe pravi posetilac. A ako procenjujete form backend i želite da vidite kako izgleda sistem koji radi od početka do kraja, dokumentacija i stranica cenovnika pokrivaju podešavanje i besplatni paket.