Panduan

Panduan14 menit baca

Cara kerja pengiriman formulir HTML

Apa yang dilakukan browser saat formulir dikirim: field mana yang dikirim, bagaimana di-encode, apa yang seharusnya dijawab server, dan bagaimana Ikiform menjawab.

Preet SutharPendiri, Ikiform

Saat seseorang menekan tombol kirim, browser memeriksa batasan formulir, mengumpulkan setiap kontrol yang punya nama dan aktif, meng-encode-nya dengan enctype formulir, dan mengirimnya ke URL action dengan method formulir. Server menjawab seperti memuat halaman biasa, dan server yang baik menjawab POST yang berhasil dengan redirect 303, jadi refresh tidak mengirim formulir dua kali. Arahkan action ke backend formulir seperti Ikiform dan Anda mendapat redirect itu, validasi field, dan penyaringan spam tanpa server sendiri.

Formulir HTML lebih tua dari JavaScript dan masih menjadi cara paling andal untuk mengirim data dari halaman web. Formulir bekerja dengan script mati, di ponsel lambat, dan di setiap builder yang mengizinkan Anda menempel markup. Kebanyakan bug formulir berasal dari ketidaktahuan tentang apa yang dilakukan browser dengan sendirinya, jadi panduan ini membahas pengiriman langkah demi langkah, lalu menunjukkan di mana backend formulir berperan.

Apa yang terjadi saat Anda menekan kirim

Pengiriman adalah navigasi biasa dengan body terlampir. Browser melakukan empat hal sebelum apa pun meninggalkan halaman, lalu menyerahkan request ke jaringan dan memuat apa pun yang kembali.

Apa yang dilakukan browser antara klik kirim dan halaman berikutnyadi browserlewat jaringankirimtombol, Enter,ataurequestSubmit()pemeriksaanbatasanrequired,type, pattern,min, dan maxform datasethanya kontrolbernama danaktifencodeurlencodedataumultipartpesan difieldtidak adayang dikirimPOST keactionSec-Fetch-Mode:navigateservermenjawab303 SeeOtherGETLocationhalamanterima kasihvalidtidak validikutiApa yang dilakukan browser antara klik kirim dan halaman berikutnyadi browserlewat jaringankirimtombol, Enter, ataurequestSubmit()pemeriksaanbatasanrequired, type,pattern, min, dan maxform data sethanya kontrolbernama dan aktifencodeurlencoded ataumultipartpesan difieldtidak adayangdikirimPOST ke actionSec-Fetch-Mode:navigateserver menjawab303 See OtherGET Locationhalaman terimakasihvalidikutitidak valid
  1. Tombol submit, tombol Enter di field teks, atau form.requestSubmit() memulai pengiriman dan memicu event submit.
  2. Kecuali formulir punya novalidate, browser memeriksa batasan setiap kontrol. Yang pertama tidak valid mendapat pesan dan tidak ada yang dikirim.
  3. Browser menyusun form data set dari setiap kontrol yang punya nama dan tidak disabled.
  4. Browser meng-encode set itu dengan enctype formulir, urlencoded kecuali Anda menentukan lain.
  5. Browser bernavigasi ke URL action dengan method formulir, sambil mengirim body.
  6. Server menjawab. 303 memberi tahu browser untuk memuat URL lain dengan GET, yang menjadi halaman tempat pengunjung berakhir.
Semua yang di atas garis terjadi tanpa jaringan sama sekali. Listener event submit bisa menghentikan alur di langkah pertama dan mengambil alih dengan fetch.

Atribut yang menentukan request

Lima atribut di <form> menentukan ke mana data pergi dan bagaimana caranya. Masing-masing bisa ditimpa untuk satu tombol dengan atribut form* yang sesuai, begitulah satu formulir bisa punya tombol Send dan Save draft yang berperilaku berbeda.

AtributDefaultFungsinyaOverride di tombol
actionURL halaman itu sendiriURL yang menerima data. Nilai relatif di-resolve terhadap halaman. Lihat atribut actionformaction
methodgetget menaruh field di query string URL. post mengirimnya sebagai body. dialog menutup <dialog> tanpa mengirim apa punformmethod
enctypeapplication/x-www-form-urlencodedCara body post di-encode. multipart/form-data dibutuhkan untuk file. text/plain dimaksudkan untuk debuggingformenctype
novalidateMatiMelewati pemeriksaan batasan browser saat submitformnovalidate
target_selfTempat respons dimuat. _blank membuka tab baru, iframe bernama membuat halaman tetap di tempatformtarget

Dua tombol, dua perilaku. Yang kedua melewati validasi, dan name serta value tombol yang diklik ditambahkan ke data, jadi server tahu mana yang ditekan:

Dua tombol submit
<form action="https://ikiform.com/f/frm_xxxxxxxxxxxxxxxx" method="post">
  <input name="email" type="email" required />
  <textarea name="details" required></textarea>
  <button name="intent" value="report">Send report</button>
  <button name="intent" value="draft" formnovalidate>Save as draft</button>
</form>

Kontrol mana yang dikirim

Browser hanya mengirim apa yang disebut spesifikasi HTML sebagai form data set. Kebanyakan kejutan di log kiriman berasal dari aturan ini:

  • Kontrol butuh name. id saja tidak mengirim apa pun.
  • Kontrol disabled dilewati. Gunakan readonly jika Anda ingin nilai ditampilkan, dikunci, dan dikirim.
  • Checkbox atau radio yang tidak dicentang sama sekali tidak mengirim apa pun, bukan false. Checkbox tercentang tanpa value mengirim on.
  • Hanya tombol yang mengirim formulir yang disertakan, dengan name dan value-nya.
  • <select multiple> dan grup checkbox yang berbagi nama mengirim satu pasangan per nilai yang dipilih.
  • Input di luar elemen <form> bisa bergabung dengan atribut form yang menyebut id formulir.

Cara body di-encode

Dengan enctype default, body adalah satu baris pasangan name=value yang digabung dengan &, spasi menjadi +, dan semua karakter di luar set aman di-percent-encode. Ini request sungguhan untuk formulir laporan di bawah, seperti yang dikirim browser:

application/x-www-form-urlencoded
POST /f/frm_xxxxxxxxxxxxxxxx HTTP/1.1
Host: ikiform.com
Content-Type: application/x-www-form-urlencoded
Origin: https://example.com
Sec-Fetch-Mode: navigate

email=ada%40example.com&page=https%3A%2F%2Fexample.com%2Fpricing&severity=broken&details=The+annual+toggle+does+nothing&_redirect=https%3A%2F%2Fexample.com%2Freport-sent&_gotcha=

multipart/form-data membungkus setiap field dalam bagiannya sendiri dengan string boundary yang dipilih browser. Ukurannya lebih besar, tetapi bisa membawa file. Ikiform membaca keduanya. text/plain tidak punya cara andal untuk menandai akhir sebuah nilai, jadi Ikiform menolaknya dengan 415 unsupported_media_type.

multipart/form-data
POST /f/frm_xxxxxxxxxxxxxxxx HTTP/1.1
Host: ikiform.com
Content-Type: multipart/form-data; boundary=----formdata7f3a

------formdata7f3a
Content-Disposition: form-data; name="email"

ada@example.com
------formdata7f3a
Content-Disposition: form-data; name="severity"

broken
------formdata7f3a--
Apa pun encoding-nya, pertahankan halaman dalam UTF-8. Ikiform men-decode setiap body sebagai UTF-8 dan menolak charset lain dengan 415 unsupported_charset. Upload file belum didukung. Kiriman dengan file mendapat 422 files_not_supported.

Empat cara mengirim formulir

Post biasa hanyalah satu pilihan. Setiap pendekatan di bawah adalah pilihan yang wajar di suatu tempat; yang berubah adalah siapa yang menangani jawaban dan apa yang terjadi saat script mati.

PendekatanUnggul dalamKekurangan
method="post" biasa dengan redirectBekerja tanpa JavaScript, di builder mana pun. Browser menangani status loading, back, dan refreshMuat ulang halaman penuh. Error field butuh halaman yang dirender server, atau halaman error dari backend
fetch dengan FormDataTanpa reload. Anda yang menentukan tampilan sukses dan setiap error fieldAnda yang menangani status loading, error jaringan, dan fokus. Tanpa kehati-hatian, ini rusak saat script mati. Lihat tanpa reload halaman
Form action framework, seperti server action Next.js atau form action SvelteKitServer Anda melihat post lebih dulu, dan formulir yang sama bekerja sebelum dan sesudah hydrationAnda butuh server runtime, dan request ke backend berangkat dari server Anda, yang mengubah rate limit dan pemeriksaan origin
method="get"Formulir pencarian dan filter. Hasilnya punya URL yang bisa dibagikanField masuk ke URL, riwayat, dan log server. Jangan pernah untuk data pribadi atau apa pun yang mengubah state

Mulailah dengan post biasa lalu tambahkan fetch di atasnya. Dengan begitu formulir tetap bekerja saat script gagal dimuat, yang terjadi lebih sering daripada yang ditunjukkan kebanyakan analytics.

Apa yang seharusnya dijawab server

Browser memperlakukan jawaban atas POST sebagai halaman baru. Jika halaman itu adalah respons itu sendiri, dengan status 200, browser mengingat bahwa halaman itu berasal dari POST. Tekan refresh dan browser menawarkan untuk mengirim formulir lagi; tekan back lalu forward dan beberapa browser melakukan hal yang sama. Begitulah orang membayar dua kali dan tim support menerima pesan yang sama tiga kali.

Solusinya adalah pola Post/Redirect/Get. Server menangani POST, lalu menjawab 303 See Other dengan header Location. Browser memuat URL itu dengan GET, dan halaman yang dilihat pengunjung berasal dari GET, jadi refresh tidak berbahaya.

Menjawab POST dengan halaman dibandingkan dengan menjawabnya dengan redirect 303jawab dengan halaman (200)jawab dengan redirect (303)POST/reportHTMLterimakasih 200halamanberasal dariPOSTrefresh"Confirm formresubmission"POST lagiduplikatPOST/report303 SeeOtherLocation:/report-sentGET/report-sentrefreshhanya memuatulang GETMenjawab POST dengan halaman dibandingkan dengan menjawabnya dengan redirect 303jawab dengan halaman (200)jawab dengan redirect (303)POST /reportHTML terima kasih 200halaman berasal dari POSTrefresh"Confirm form resubmission"POST lagiduplikatPOST /report303 See OtherLocation: /report-sentGET /report-sentrefreshhanya memuat ulang GET
  1. Dengan jawaban 200, browser mengirim formulir dan menampilkan body respons sebagai halaman.
  2. Halaman itu terikat pada POST, jadi refresh meminta kirim ulang dan konfirmasi mengirim data lagi.
  3. Dengan jawaban 303, browser mengirim formulir dan diminta memuat URL lain.
  4. Browser memuat URL itu dengan GET. Refresh hanya mengulang GET, jadi tidak ada yang terkirim dua kali.
Ikiform selalu menjawab post dari browser dengan 303, jadi formulir Anda mendapat perilaku ini secara gratis.
StatusApa yang dilakukan browser berikutnyaGunakan untuk
303 See OtherGET ke Location, body dibuangSetelah form post apa pun yang berhasil
302 FoundDalam praktiknya browser beralih ke GET, tetapi spesifikasi mengizinkan method tetapServer lama. Lebih baik 303
307 dan 308Mengulang POST yang sama dengan body yang sama di URL baruMemindahkan endpoint, bukan halaman terima kasih
200 dengan HTMLTampilkan halaman; refresh menawarkan kirim ulangMenampilkan ulang formulir dengan error
4xx dengan HTMLTampilkan halaman errorError yang bisa diperbaiki pengunjung dengan kembali
Post/Redirect/Get
HTTP/1.1 303 See Other
Location: https://example.com/report-sent
X-Request-Id: req_01k7v2c9t3e8m5q4x6z0a1b2c3

GET /report-sent HTTP/1.1
Host: example.com

Cara Ikiform menjawab

Satu endpoint, https://ikiform.com/f/<formId>, menjawab browser maupun kode. Endpoint memutuskan per request apakah menjawab dengan halaman atau JSON, dari header yang diatur browser dengan sendirinya:

RequestJawaban
Accept mencakup application/jsonJSON
Body berupa JSONJSON
Sec-Fetch-Mode: navigate, yaitu setiap form post biasaRedirect atau halaman hosted
Sec-Fetch-Mode lainnya, seperti cors dari fetchJSON
Tanpa Sec-Fetch-Mode, dan Accept mencakup text/htmlRedirect atau halaman hosted
Lainnya, seperti curlJSON

Sec-Fetch-Mode adalah header yang diatur browser dan tidak bisa diubah script halaman. Form post yang menavigasi tab mengirim navigate; panggilan fetch mengirim cors untuk request lintas situs. Jadi formulir yang sama mendapat redirect saat dikirim dengan cara biasa dan JSON saat script Anda yang mengirimnya, tanpa sakelar apa pun di sisi Anda. Tabel lengkapnya ada di JSON atau redirect.

Endpoint Ikiform yang sama menjawab form post biasa dan panggilan fetchkiriman formulir biasafetch, atau Accept: application/jsonbrowserbernavigasiSec-Fetch-Mode:navigateIkiformmode halaman303 ke halamanAndaatau halaman terimakasih hostedhalaman errorhostedmasalah per label field,status asliscript mengirimSec-Fetch-Mode: corsIkiformmode JSON201 dengan id{ ok: true, id }error JSONerror.fields per idfieldditolakditolakEndpoint Ikiform yang sama menjawab form post biasa dan panggilan fetchkiriman formulir biasafetch, atau Accept: application/jsonbrowserbernavigasiSec-Fetch-Mode:navigateIkiformmode halaman303 ke halamanAndaatau halaman terimakasih hostedhalamanerrorhostedmasalah perlabelfield,status asliscript mengirimSec-Fetch-Mode:corsIkiformmode JSON201 dengan id{ ok: true, id }errorJSONerror.fieldsper idfieldditolakditolak
  1. Form post biasa menavigasi tab, jadi browser mengirim Sec-Fetch-Mode: navigate.
  2. Ikiform menjawab dalam mode halaman: redirect 303 saat sukses, atau halaman error hosted dengan status asli error tersebut.
  3. Panggilan fetch mengirim Sec-Fetch-Mode: cors, atau kode Anda meminta JSON dengan header Accept.
  4. Ikiform menjawab dalam mode JSON: 201 dengan id kiriman, atau envelope error dengan error field yang dikunci per id field.
Anda tidak mengonfigurasi mode. Mode mengikuti cara request dibuat.

Ke mana post yang berhasil mendarat

Post browser yang berhasil mendapat 303. Ikiform memilih tujuan dengan urutan ini:

  1. Pengaturan Redirect after submit formulir di dashboard. URL http: atau https: apa pun bisa, karena hanya workspace Anda yang bisa mengaturnya.
  2. Field _redirect di post, atau _next jika tidak ada _redirect, saat berupa URL https: tanpa username, password, atau port kustom, di salah satu Allowed domains formulir atau subdomainnya.
  3. Jika tidak, halaman terima kasih hosted di /f/<formId>/thanks. Jika post datang dari halaman https: di domain yang diizinkan, halaman itu menautkan kembali ke sana.

_redirect yang melanggar aturan diabaikan, tidak pernah menjadi error, dan formulir tanpa allowed domains mengabaikan _redirect sepenuhnya. Itu mencegah siapa pun memakai formulir Anda untuk melempar pengunjung ke situs pilihan mereka. Redirect setelah submit membahas halaman terima kasih secara mendalam, dan aturan lengkapnya ada di formulir HTML.

Saat post ditolak

Dalam mode halaman, post yang ditolak menampilkan halaman error hosted dengan status HTTP asli error tersebut. Untuk error validasi, halaman itu mencantumkan setiap masalah di bawah label field Anda dan menautkan ke halaman asal post. Tombol Back browser biasanya kembali ke formulir dengan isian pengunjung masih ada; tautannya memuat halaman dari awal. Dalam mode JSON, error yang sama kembali sebagai satu envelope. Setiap kode ada di Errors.

422 dalam mode JSON
{
  "ok": false,
  "error": {
    "code": "validation_failed",
    "message": "Some fields are invalid.",
    "fields": {
      "page": ["Enter a valid URL"],
      "details": ["Must be at least 20 characters"]
    }
  },
  "request_id": "req_01k7v2c9t3e8m5q4x6z0a1b2c3"
}

Spam adalah satu-satunya hal yang tidak pernah terlihat seperti error. Post yang dinilai spam mendapat 303 atau 201 yang sama seperti yang asli, jadi bot tidak belajar apa pun, dan tidak ada email atau webhook yang dikirim.

Formulir di stack Anda

Berikut formulir sungguhan, laporan halaman rusak, di setiap stack. Pilih milik Anda; pilihan itu berlaku untuk setiap contoh kode di panduan ini. Definisi field di bawah sama dengan yang ditegakkan Ikiform di server, jadi cobalah: buat detailnya pendek atau ketik example sebagai alamat dan Anda mendapat 422 yang akan didapat formulir Anda.

Pratinjau

Menjalankan validator Ikiform di browser Anda. Tidak ada yang dikirim.

Tempel definisi ini di tab Fields formulir di dashboard dan Ikiform memvalidasi setiap post terhadapnya. Lihat Field dan validasi.

Tanpa script sama sekali. Browser memeriksa required, type, dan minlength, mengirim field sebagai teks urlencoded, mengikuti 303 dari Ikiform ke halaman _redirect Anda, dan menampilkan halaman error Ikiform jika server menolak post.

report.html
<form action="https://ikiform.com/f/frm_xxxxxxxxxxxxxxxx" method="post">
  <label for="email">Your email</label>
  <input id="email" name="email" type="email" autocomplete="email" required />

  <label for="page">Page address</label>
  <input id="page" name="page" type="url" required placeholder="https://example.com/pricing" />

  <label for="severity">How bad is it</label>
  <select id="severity" name="severity">
    <option value="cosmetic">Looks wrong</option>
    <option value="broken">Something doesn't work</option>
    <option value="blocking">I can't continue</option>
  </select>

  <label for="details">What happened</label>
  <textarea id="details" name="details" rows="5" minlength="20" maxlength="4000" required></textarea>

  <input type="hidden" name="_redirect" value="https://example.com/report-sent" />
  <input name="_gotcha" type="text" tabindex="-1" autocomplete="off" hidden />
  <button>Send report</button>
</form>
Versi sisi server mengirim dengan secret key, sehingga Ikiform melewati Allowed domains dan pemeriksaan manusianya. Semua kiriman lalu datang dari IP server Anda, dan batas Standard 5 per menit per pengunjung menghitung semua pengunjung Anda sebagai satu. Pilih rate limit Relaxed atau Custom untuk formulir yang Anda kirim lewat server, dan simpan IKIFORM_SECRET_KEY di environment variable khusus server.

Setiap versi server meneruskan header Origin dari browser jika ada, karena fetch sisi server tidak mengirimnya dan Ikiform memakainya untuk mengenali uji gratis dari localhost di workspace tanpa paket.

  • Setiap versi mempertahankan method sungguhan dan, jika mengirim langsung ke Ikiform, action sungguhan. Dengan script mati formulir tetap terkirim dan mendapat 303.
  • name setiap input adalah id field dalam definisi. Ketidakcocokan, seperti url alih-alih page, mendapat 422 dengan Unknown field "url".
  • Input _gotcha tersembunyi adalah honeypot. Bot yang mengisinya disimpan sebagai spam, diam-diam.
  • Versi JavaScript menampilkan error.fields di bawah setiap input, memakai pesan pertama untuk setiap field. Versi HTML biasa menyerahkannya ke halaman error Ikiform.

Dokumentasi membahas lebih dalam per framework: Next.js, Astro, SvelteKit, Nuxt, React, Vue, dan dari server.

Dua lapis validasi

Validasi browser dan validasi server punya tugas berbeda. Pemeriksaan batasan browser (required, type="email", minlength, pattern) memberi umpan balik instan, tetapi siapa pun bisa melewatinya: bot mengirim langsung, dan script bisa memanggil form.submit(), yang tidak pernah menjalankan pemeriksaan. Server adalah satu-satunya tempat aturan benar-benar berlaku.

AturanDi browserDi definisi field Ikiform
Wajibrequired"required": true
Emailtype="email""type": "email", dengan allowed_domains opsional
URLtype="url""type": "url", dengan https_only opsional
Panjangminlength, maxlengthvalidation.min_length, max_length
Hanya pilihan yang tercantum<select>, yang diabaikan botoptions; yang lain ditolak
Tanpa field tambahanTidak mungkinField apa pun yang tidak ada di definisi ditolak

Tanpa definisi, Ikiform menerima field apa pun dan menyimpannya apa adanya. Publikasikan definisi dan Ikiform memvalidasi, menyimpan angka dan checkbox sebagai angka dan boolean sungguhan, serta menolak post dengan 422 validation_failed sebelum apa pun disimpan. Validasi menunjukkan cara menjaga kedua lapis tetap konsisten.

Mengirim dengan JavaScript

Agar pengunjung tetap di halaman, dengarkan submit, panggil preventDefault(), dan kirim new FormData(form) dengan fetch. Beberapa detail menentukan apakah itu langsung berhasil:

  • Jangan atur Content-Type sendiri saat body berupa FormData. Browser mengatur multipart/form-data beserta boundary-nya; header yang ditulis manual tidak punya boundary dan body tidak bisa di-parse.
  • Kirim Accept: application/json. Ikiform toh akan memilih JSON dari Sec-Fetch-Mode, tetapi header ini membuatnya eksplisit, dan termasuk header request yang bisa dikirim browser lintas situs tanpa preflight.
  • Body FormData atau URLSearchParams adalah request lintas situs sederhana, jadi tidak ada preflight. Body JSON dengan Content-Type: application/json memicu preflight lebih dulu; Ikiform menjawabnya, tetapi itu menambah satu perjalanan pulang-pergi.
  • form.submit() melewati validasi dan event submit. form.requestSubmit() menjalankan keduanya, seperti klik.
  • Berikan tombol yang diklik sebagai argumen kedua, new FormData(form, event.submitter), jika name dan value-nya penting.

Pola lengkapnya, dengan status loading, fokus, dan error jaringan, ada di tanpa reload halaman. Dokumentasi JavaScript dan fetch mencantumkan setiap header dan format body yang diterima endpoint.

Pilih situasi Anda

Setiap halaman ini mengambil satu bagian dari pengiriman dan membahasnya lebih jauh dari ringkasan di atas, dengan kode untuk kasus itu.

Pastikan berfungsi

Jalankan ini sekali per formulir, di jendela privat. Ikiform tidak punya paket gratis. Pengujian gratis: workspace tanpa paket menerima 50 kiriman uji per bulan dari localhost. Untuk live, pilih Pro mulai $6/bln untuk 500 kiriman, atau bayar sekali: 10.000 kiriman seharga $49 atau 50.000 kiriman seharga $149, dengan kredit yang tidak pernah kedaluwarsa. Lihat harga.

  1. Di Allowed domains formulir, tambahkan domain situs Anda, ditambah localhost selama pengembangan. Biarkan kosong untuk menerima kiriman dari mana saja.
  2. Matikan JavaScript di developer tools browser Anda dan kirim formulir. Formulir tetap harus mendarat di halaman terima kasih Anda dengan 303.
  3. Dengan JavaScript aktif, buka panel Network dan kirim lagi. Request ke /f/<formId> seharusnya menjawab 201 dengan JSON, dan halaman tidak dimuat ulang.
  4. Kirim dengan pesan yang terlalu pendek. Post biasa menampilkan halaman error Ikiform dengan label field Anda; versi script menampilkan pesan di bawah field.
  5. Di halaman terima kasih, tekan refresh. Tidak boleh ada yang terkirim ulang, dan tidak boleh muncul kiriman kedua.
  6. Buka Submissions di dashboard. Kiriman baru ada di sana dengan setiap field yang Anda kirim.
  7. Kirim dengan honeypot terisi, _gotcha=bot. Kiriman tetap mendapat jawaban sukses, tetapi disimpan sebagai spam dan tidak memicu email atau webhook.

Pemecahan masalah

MasalahYang harus dilakukan
405 Method Not Allowed setelah submitFormulir mengirim ke host statis Anda sendiri, yang tidak bisa menerima POST. Periksa action: harus berupa URL lengkap https://ikiform.com/f/<formId>, bukan path relatif atau kosong.
Membuka endpoint di tab menampilkan 404 not_foundItu wajar. Tab mengirim GET, dan endpoint hanya menerima POST. Pastikan method formulir adalah post; formulir tanpa method mengirim GET dengan field di URL.
415 unsupported_media_typeFormulir punya enctype="text/plain", atau script mengirim tipe yang tidak dibaca Ikiform. Hapus enctype, atau gunakan multipart/form-data.
422 validation_failedKiriman tidak cocok dengan definisi field formulir. error.fields menyebutkan setiap field dan alasannya. Samakan name input dengan ID field.
Browser mendarat di halaman terima kasih Ikiform, bukan halaman Anda_redirect diabaikan kecuali domainnya ada di Allowed domains dan berupa URL https:. Tambahkan domainnya, atau atur Redirect after submit di pengaturan formulir sebagai gantinya.
Sebuah field hilang dari kirimanField itu tidak punya name, berstatus disabled, atau berupa checkbox yang tidak dicentang. Beri name, gunakan readonly alih-alih disabled, atau definisikan field checkbox agar kotak yang tidak dicentang disimpan sebagai false.
Refresh meminta kirim ulang formulirHalaman menjawab POST dengan 200. Post langsung ke Ikiform selalu mendapat 303; jika server Anda sendiri berada di antaranya, lakukan redirect setelah menangani post.
403 origin_not_allowed, atau setiap kiriman masuk ke spamDomain halaman tidak ada di Allowed domains formulir. Tambahkan, ditambah localhost untuk uji lokal. Subdomain dari domain yang terdaftar diizinkan.

Pertanyaan

Mentok di salah satu langkah, atau ingin panduan untuk situasi Anda? Email hello@ikiform.com.