कॉन्टैक्ट फ़ॉर्म काम नहीं कर रहा? असल वजह कैसे पता करें

"मेरा कॉन्टैक्ट फ़ॉर्म काम नहीं कर रहा" का आमतौर पर मतलब लगभग छह चीज़ों में से एक होता है, और यह अंदाज़ा लगाना कि कौन-सी, जाँच करने से ज़्यादा समय बर्बाद करता है। सही तरीक़ा है वजहों को संभावना के क्रम में जाँचना, और सबसे पहले उस चीज़ से शुरू करना जो सबसे कम समय में सबसे ज़्यादा बताती है: रिक्वेस्ट के ब्राउज़र छोड़ते ही उसके साथ असल में क्या हुआ।

1. जाँचें कि रिक्वेस्ट ने असल में क्या किया

पेज खोलें, devtools खोलें, Network टैब पर जाएँ, और ख़ुद फ़ॉर्म सबमिट करें। यहाँ लगातार दो चीज़ें ख़राब होती हैं:

• action URL ग़लत है - ग़लत टाइप हुई API key, किसी पुराने फ़ॉर्म से कॉपी किया गया और कभी अपडेट न हुआ URL, या (शर्मनाक हद तक आम) लोकल डेवलपमेंट से अभी भी localhost की ओर इशारा करता हुआ और कभी प्रोडक्शन पर स्विच न किया गया।
• रिक्वेस्ट जाती है लेकिन एरर स्टेटस के साथ वापस आती है। आपको हर कोड का सटीक मतलब जानने की ज़रूरत नहीं - एक 4xx या 5xx रिस्पॉन्स ही यह बताने के लिए काफ़ी है कि समस्या प्राप्तकर्ता की तरफ़ है, आपके HTML में नहीं।

अगर रिक्वेस्ट कभी जाती ही नहीं, या किसी ऐसे डोमेन पर जाती है जो साफ़ तौर पर आपका फ़ॉर्म बैकएंड नहीं है, तो यही बग है - एक मिनट से भी कम में मिल गया, इससे पहले कि आप कहीं और खोजना शुरू करें।

2. पुष्टि करें कि यह असल में POST के रूप में भेजी जा रही है

बिना स्पष्ट method="POST" वाला <form> डिफ़ॉल्ट रूप से GET इस्तेमाल करता है, जो आपके फ़ील्ड्स को बॉडी भेजने के बजाय URL में क्वेरी स्ट्रिंग के रूप में जोड़ देता है - एक फ़ॉर्म बैकएंड एंडपॉइंट आमतौर पर इसे असली सबमिशन के रूप में स्वीकार नहीं करेगा। पहले टैग को ही जाँचें।

अगर फ़ॉर्म ब्राउज़र के नेटिव POST की बजाय JavaScript के ज़रिए सबमिट होता है, तो ज़्यादा आम गड़बड़ी एक ऐसा हैंडलर है जो डिफ़ॉल्ट नेविगेशन रोकने के लिए e.preventDefault() कॉल करता है और फिर असल में कुछ भेजता ही नहीं - एक टूटा हुआ fetch कॉल, हैंडलर के अंदर एंडपॉइंट में टाइपो, या एक ख़ामोश early return। किसी काम करती रिक्वेस्ट के बिना preventDefault(), विज़िटर के लिए एक मरे हुए फ़ॉर्म से अलग नहीं दिखता: पेज बस... कुछ नहीं करता।

3. सिर्फ़ नेटवर्क नहीं, कंसोल को भी खारिज करें

किसी भी fetch-आधारित सबमिशन के लिए, Network के साथ Console टैब भी खोलें। एक CORS एरर, एक ब्लॉक किया गया mixed-content रिक्वेस्ट (https:// पेज से http:// पर सबमिट करना), या सबमिट हैंडलर के अंदर एक अनकॉट exception - ये सब रिक्वेस्ट को पूरी तरह रोक देते हैं, और इनमें से कोई भी विज़िटर के लिए कोई दिखाई देने वाली एरर पैदा नहीं करता। यह बस ख़ामोशी जैसा दिखता है, ठीक वैसा ही जैसा एक टूटा फ़ॉर्म बाहर से दिखता है।

4. जाँचें कि नोटिफ़िकेशन असल में कहाँ पहुँचा

अगर स्टेप 1 की रिक्वेस्ट सफलता के स्टेटस के साथ वापस आई, तो सबमिशन बैकएंड तक पहुँच गया - बचा हुआ सवाल बस यह है कि अलर्ट कहाँ गया। पहले स्पैम और प्रोमोशन फ़ोल्डर जाँचें; यह सबसे आम वजह है जिसके कारण एक "गुम" नोटिफ़िकेशन असल में गुम नहीं होता। अगर आप डिफ़ॉल्ट सेंडर के बजाय किसी कस्टम वेरिफ़ाइड डोमेन से भेज रहे हैं, तो एक ग़लत कॉन्फ़िगर किया गया SPF या DKIM रिकॉर्ड ईमेल को प्राप्तकर्ता के मेल सर्वर द्वारा चुपचाप फ़िल्टर या बाउंस करवा देगा, जो आपकी तरफ़ से बिल्कुल "कुछ भेजा ही नहीं गया" जैसा दिखता है।

5. एक ख़ामोश रिजेक्शन पर भी विचार करें - रेट लिमिट और टूटा हुआ honeypot

वैध सबमिशन कभी-कभी संदिग्ध मान लिए जाते हैं। डीबगिंग के दौरान एक ही IP से बार-बार तेज़ी से टेस्ट करना ठीक वही पैटर्न है जिसे पकड़ने के लिए रेट लिमिटिंग बनी है, और यह बिना किसी दुर्भावना के भी आप पर लागू हो सकती है। कुछ मिनट इंतज़ार करें और फिर से कोशिश करें, इससे पहले कि मान लें कुछ टूटा है।

एक ज़्यादा सूक्ष्म और सचमुच आम बग: honeypot फ़ील्ड। ज़्यादातर स्पैम प्रोटेक्शन में एक छिपा हुआ फ़ील्ड होता है जिसे असली विज़िटर कभी देखते या भरते नहीं - अगर कोई बॉट इसे भर देता है, तो सबमिशन चुपचाप हटा दिया जाता है। एक CSS रिग्रेशन (एक रीनेम हुई क्लास, लोड न हो पाई स्टाइलशीट, एक लेआउट बदलाव जो ग़लत एलिमेंट को "अनहाइड" कर दे) इस फ़ील्ड को असली यूज़र्स के लिए दिखा सकता है, जो या तो एक अतिरिक्त फ़ील्ड से उलझ जाते हैं, या - इससे भी बुरा - इसे किसी पासवर्ड मैनेजर द्वारा ऑटो-फ़िल होते पाते हैं, जो बॉट्स के लिए बनाए गए उसी फ़िल्टर को ट्रिगर कर देता है। अगर सबमिशन किसी रीडिज़ाइन या CSS बदलाव के ठीक बाद फ़ेल होने लगे, तो सबसे पहले यही जाँचना चाहिए।

डैशबोर्ड जाँचें, सिर्फ़ अपना इनबॉक्स नहीं

ऊपर की सारी बातों का सार यह है: "क्या मुझे ईमेल मिला" और "क्या सबमिशन पहुँचा" एक जैसा सवाल नहीं है, और इन दोनों को गड्डमड्ड करना ही इस तरह के बग को मिनटों के बजाय दिनों में ढूँढने लायक़ बना देता है। Formhook के साथ, बैकएंड तक असल में पहुँचने वाला हर सबमिशन डैशबोर्ड में दिखता है, चाहे नोटिफ़िकेशन ईमेल पहुँचा हो या नहीं - इसलिए ऊपर दिए किसी भी स्टेप से पहले पहली उपयोगी जाँच बस लॉग इन करके देखना है। अगर वह वहाँ है, तो समस्या नोटिफ़िकेशन की तरफ़ है (स्टेप 4-5)। अगर वह वहाँ नहीं है, तो समस्या पहले की है, इससे पहले कि रिक्वेस्ट बैकएंड तक पहुँचे ही (स्टेप 1-3)।

यह नियमित रूप से करने लायक़ है, सिर्फ़ तब नहीं जब कुछ टूट जाए: प्री-लॉन्च टेस्टिंग चेकलिस्ट उस पंद्रह-मिनट के पास को कवर करती है जो असली विज़िटर के इसे झेलने से पहले ही इनमें से ज़्यादातर पकड़ लेता है। और अगर आप कोई फ़ॉर्म बैकएंड आज़मा रहे हैं और देखना चाहते हैं कि शुरू से आख़िर तक काम करने वाला सिस्टम कैसा दिखता है, तो डॉक्स और प्राइसिंग पेज सेटअप और फ़्री टियर के बारे में बताते हैं।