نقل أتمتة Zapier أو Make إلى مضيف ترميز جغرافي جديد
تحتاج عمليات الأتمتة دون شيفرة المبنية على خطوة ترميز جغرافي إلى نهج ترحيل مختلف عن الشيفرة المخصصة. إليك كيفية التعامل مع هذا التحويل.
نقل إضافة WordPress من واجهة API مدفوعة للترميز الجغرافي
تُبنى إضافات WordPress التي تستدعي واجهة API للترميز الجغرافي، سواء كانت أداة للعثور على المتاجر أو أداة للتحقق من مناطق التوصيل أو خريطة لقوائم العقارات، عادةً على مفتاح مزود محدد يُدخل مرة واحدة في صفحة الإعدادات ويُستخدم في كل موضع تحتاج فيه الإضافة إلى استعلام عن موقع. وحقل الإعدادات الواحد هذا مريح لأصحاب المواقع، لكنه يعني أيضًا أن مزود الترميز الجغرافي كثيرًا ما يكون مدمجًا في شيفرة الإضافة بعمق أكبر مما توحي به نظرة سريعة على صفحة الإعدادات.
أول ما يجب تحديده هو ما إذا كنت تنقل إضافة تتولى صيانتها بنفسك، أم إضافة من طرف ثالث تكتفي بضبط إعداداتها. وهاتان حالتان مختلفتان فعلًا:
إذا كنت تتولى صيانة الإضافة، فالانتقال تغيير عادي في الشيفرة: اعثر على كل دالة تستدعي واجهة API للترميز الجغرافي (البحث في شيفرة الإضافة عن اسم مضيف المزود أو عن اسم معامل المفتاح الخاص به هو عادةً أسرع طريقة لتحديد كل موضع استدعاء)، وحدّث تلك الدوال لتستدعي المضيف الجديد بمفتاح جديد. وبما أن PHP هي اللغة الطبيعية هنا، وبما أن مضيفات التوافق في My Geocode تعيد إنتاج الشكل الدقيق لاستجابة مزود مألوف، فإذا كانت شيفرة الإضافة الحالية تحلل أصلًا الصيغة الخاصة بذلك المزود، فإن تحديث مضيف الطلب والمصادقة فقط، دون منطق تحليل الاستجابة، يكفي في كثير من الأحيان. وتدعم المصادقة الترويسة X-API-Key أو Authorization: Bearer أو مصادقة HTTP Basic أو معامل استعلام، لذا فأيًا كان الأسلوب الذي تستخدمه الإضافة حاليًا لإرسال مفتاحها، فله مقابل مباشر.
إذا كنت تكتفي بضبط إعدادات إضافة من طرف ثالث، فخياراتك تعتمد كليًا على ما تتيحه صفحة إعدادات الإضافة. فبعض الإضافات تسمح بضبط نقطة نهاية API مخصصة إلى جانب المفتاح، وفي هذه الحالة قد يعمل توجيه هذا الإعداد إلى مضيف توافق مطابق، إن وُجد للمزود الذي بُنيت الإضافة له أصلًا، دون أي تغيير في الشيفرة على الإطلاق، لأن الإضافة من منظورها لا تزال تتحدث إلى واجهة API بالشكل نفسه. وإضافات أخرى تثبّت اسم مضيف المزود في الشيفرة بالكامل، وفي هذه الحالة تنحصر خياراتك في التواصل مع مطور الإضافة، أو البحث عن نسخة متفرعة أو تحديث يضيف مرونة، أو، في حالة الاعتماد الحرج، التفكير في تعديل مخصص صغير إذا كان ترخيص الإضافة يسمح بذلك.
بعض الملاحظات العملية لكلتا الحالتين:
- اختبر أي تغيير على نسخة تجريبية (staging) من الموقع أولًا، ولا تختبره أبدًا مباشرة على تثبيت WordPress حي، لأن شيفرة الإضافة التي تتعامل مع قاعدة بيانات حية تحمل مخاطر أكبر مما يحمله تغيير معزول في الشيفرة في مكان آخر
- تحقق مما إذا كانت الإضافة تخزّن نتائج الترميز الجغرافي مؤقتًا في جدول خاص بها في قاعدة البيانات، لأن تبديل المزود قد يتطلب مسح هذه الذاكرة المؤقتة أو إعادة التحقق منها بشكل منفصل عن تغيير الشيفرة نفسه
- تأكد من أن معالجة الأخطاء في الإضافة تتعامل بسلاسة مع شكل استجابة غير متوقع، لأن موقع WordPress يعرض خطأ PHP خامًا لزائر الموقع بسبب استجابة API غير مطابقة نتيجةٌ أسوأ من مجرد غياب ميزة الترميز الجغرافي للحظة
بالنسبة إلى موقع شركة صغيرة يعتمد على إضافة واحدة لأداة العثور على المتاجر أو ميزة مشابهة، فإن الحصة اليومية المجانية، 2,500 طلب دون أي مفتاح على الإطلاق، أو 2,500 طلب لكل حساب يوميًا تتشاركها جميع مفاتيحه، كثيرًا ما تغطي بارتياح الزيارات التي يولدها موقع صغير نموذجي، ومن المفيد التحقق من ذلك مقابل الحجم الفعلي للزوار والاستعلامات في موقعك قبل افتراض أن خطة مدفوعة ضرورية أصلًا.