Zapier या Make ऑटोमेशन को नए जियोकोडिंग होस्ट पर माइग्रेट करना
जियोकोडिंग चरण पर बने नो-कोड ऑटोमेशन के लिए कस्टम कोड से अलग माइग्रेशन तरीका चाहिए। यह बदलाव कैसे संभालें, यहाँ बताया गया है।
सशुल्क जियोकोडिंग API से WordPress प्लगइन को माइग्रेट करना
जियोकोडिंग API को कॉल करने वाले WordPress प्लगइन, जैसे स्टोर लोकेटर, डिलीवरी ज़ोन चेकर या प्रॉपर्टी लिस्टिंग मैप, आम तौर पर इस तरह बनाए जाते हैं कि किसी खास प्रोवाइडर की कुंजी सेटिंग पेज में एक बार डाली जाती है और प्लगइन को जहाँ भी लोकेशन लुकअप की ज़रूरत होती है, वहाँ इस्तेमाल होती है। साइट मालिकों के लिए वह एक सेटिंग फ़ील्ड सुविधाजनक है, लेकिन इसका मतलब यह भी है कि जियोकोडिंग प्रोवाइडर अक्सर प्लगइन के कोड में उससे कहीं ज़्यादा गहराई से जुड़ा होता है जितना सेटिंग पेज पर सरसरी नज़र से लगता है।
सबसे पहले यह तय करें कि आप ऐसा प्लगइन माइग्रेट कर रहे हैं जिसे आप खुद मेंटेन करते हैं, या कोई थर्ड-पार्टी प्लगइन जिसे आप केवल कॉन्फ़िगर करते हैं। ये सच में अलग-अलग स्थितियाँ हैं:
अगर आप प्लगइन मेंटेन करते हैं, तो माइग्रेशन एक सामान्य कोड बदलाव है: जियोकोडिंग API को कॉल करने वाला हर फ़ंक्शन खोजें (प्लगइन के कोडबेस में प्रोवाइडर का होस्टनेम या उसकी कुंजी वाले पैरामीटर का खास नाम खोजना आम तौर पर हर कॉल की जगह ढूँढने का सबसे तेज़ तरीका है), और उन फ़ंक्शन को नई कुंजी के साथ नए होस्ट को कॉल करने के लिए अपडेट करें। चूँकि यहाँ PHP स्वाभाविक भाषा है और My Geocode के कम्पैटिबिलिटी होस्ट किसी जाने-पहचाने प्रोवाइडर की रिस्पॉन्स संरचना को ठीक वैसा ही दोहराते हैं, अगर प्लगइन का मौजूदा कोड पहले से उस प्रोवाइडर के खास फ़ॉर्मेट को पार्स करता है, तो रिस्पॉन्स पार्स करने के लॉजिक के बजाय केवल अनुरोध का होस्ट और ऑथेंटिकेशन अपडेट करना अक्सर काफ़ी होता है। ऑथेंटिकेशन X-API-Key हेडर, Authorization: Bearer, HTTP Basic auth या क्वेरी पैरामीटर को सपोर्ट करता है, इसलिए प्लगइन अभी अपनी कुंजी जिस भी तरीके से भेजता है, उसका सीधा समकक्ष मौजूद है।
अगर आप केवल किसी थर्ड-पार्टी प्लगइन को कॉन्फ़िगर करते हैं, तो आपके विकल्प पूरी तरह इस पर निर्भर करते हैं कि प्लगइन का सेटिंग पेज क्या उपलब्ध कराता है। कुछ प्लगइन कुंजी के साथ एक कस्टम API एंडपॉइंट कॉन्फ़िगर करने देते हैं, और ऐसे में उस सेटिंग को मेल खाने वाले कम्पैटिबिलिटी होस्ट पर पॉइंट करना, अगर उस प्रोवाइडर के लिए कोई होस्ट मौजूद है जिसके लिए प्लगइन मूल रूप से बनाया गया था, बिना किसी कोड बदलाव के काम कर सकता है, क्योंकि प्लगइन के नज़रिए से वह अब भी उसी संरचना वाले API से बात कर रहा है। दूसरे प्लगइन प्रोवाइडर का होस्टनेम पूरी तरह कोड में तय कर देते हैं, और ऐसे में आपके विकल्प सीमित हैं: प्लगइन के डेवलपर से संपर्क करना, कोई ऐसा फ़ोर्क या अपडेट खोजना जो लचीलापन जोड़ता हो, या किसी अहम निर्भरता के लिए, अगर प्लगइन का लाइसेंस अनुमति देता है, तो एक छोटे कस्टम बदलाव पर विचार करना।
दोनों स्थितियों के लिए कुछ व्यावहारिक बातें:
- कोई भी बदलाव पहले साइट की स्टेजिंग कॉपी पर टेस्ट करें, कभी सीधे लाइव WordPress इंस्टॉलेशन पर नहीं, क्योंकि लाइव डेटाबेस के साथ काम करने वाले प्लगइन कोड में कहीं और किए गए अलग-थलग कोड बदलाव से ज़्यादा जोखिम होता है
- जाँचें कि क्या प्लगइन जियोकोडिंग परिणामों को अपनी डेटाबेस टेबल में कैश करता है, क्योंकि प्रोवाइडर बदलने पर उस कैश को कोड बदलाव से अलग साफ़ करने या फिर से सत्यापित करने की ज़रूरत पड़ सकती है
- पक्का करें कि प्लगइन की एरर हैंडलिंग अप्रत्याशित रिस्पॉन्स संरचना को ठीक से संभालती है, क्योंकि मेल न खाने वाले API रिस्पॉन्स की वजह से किसी विज़िटर को कच्ची PHP एरर दिखाने वाली WordPress साइट, जियोकोडिंग फ़ीचर के कुछ पल के लिए न दिखने से कहीं बुरा नतीजा है
स्टोर लोकेटर या ऐसे ही किसी फ़ीचर के लिए एक ही प्लगइन पर निर्भर छोटे बिज़नेस की साइट के लिए, मुफ़्त दैनिक कोटा, यानी बिना किसी कुंजी के 2,500 अनुरोध, या प्रति खाता प्रतिदिन 2,500 जो उसकी सभी कुंजियों में साझा होते हैं, अक्सर एक सामान्य छोटी साइट के ट्रैफ़िक को आराम से कवर कर लेता है। यह मानने से पहले कि सशुल्क प्लान ज़रूरी है ही, इसे अपनी साइट के असली विज़िटर और लुकअप वॉल्यूम से मिलाकर देखना फ़ायदेमंद है।