ربط ووردبريس بـ API خارجي: لما الخدمة تتأخر أو تقع

العميل بيقولك «صفحة الدفع بطيئة»، وانت تفتح الموقع تلاقي الرئيسية بتفتح في ثانية. المشكلة غالبًا مش في ووردبريس نفسه، المشكلة في خدمة برّه موقعك: شركة الشحن، أو بوابة الدفع، أو الـ CRM، أو أداة ذكاء اصطناعي. خلّينا نعرف إزاي تخلي موقعك يستحمل لما واحدة منهم تتأخر.

موقعك يستهلك APIs أكثر مما تظن

كل مرة يطلب موقعك من خدمة أخرى بيانات أو تنفيذ مهمة، فهو يستهلك واجهة برمجة التطبيقات (API) الخاصة بها. هذا عكس REST API الخاص بووردبريس، الذي يتيح لغيرك أن يطلب من موقعك.

على موقع مصري أو خليجي عادي ستجد اتصالات مثل:

هذا الجدول هو أول ما تكتبه لكل موقع تديره. قد ترتبه أمامك كقطع البازل: كل قطعة خدمة، ولكل قطعة سؤالان، هل الزائر ينتظرها؟ وماذا يحدث لو لم ترد؟

لماذا يبطئ API واحد بطيء الموقع كله؟

الخادم يعالج طلبات PHP عبر عدد محدود من عمليات PHP (PHP Workers)، وكل عملية تخدم طلبًا واحدًا في كل مرة. حين يرسل نموذج تواصل بيانات الزائر إلى الـ CRM وينتظر الرد، تبقى العملية محجوزة طوال فترة الانتظار، حتى وهي لا تستهلك معالجًا تقريبًا.

لو تأخر الـ CRM بضع ثوانٍ وتكرر ذلك مع عدة زوار، تنشغل كل العمليات. عندها ينتظر زائر يحاول الدفع أو تسجيل الدخول، رغم أن طلبه لا علاقة له بالـ CRM.

ملاحظة: لهذا لا يكفي عدد الزيارات الشهرية لاختيار خطة الاستضافة. اسأل عن عدد عمليات PHP المتاحة، ودعم Cron حقيقي من الخادم، وإتاحة سجلات الأخطاء.

أضف الذكاء الاصطناعي فوق ذلك: توليد رد قد يستغرق وقتًا أطول بكثير من جلب سعر شحن، وسؤال واحد لمساعد الدعم قد يطلق عدة طلبات متتالية. وتوليد أوصاف 50 منتجًا دفعة واحدة قد يصطدم بـ حد معدل الطلبات (Rate Limit) لدى المزود.

الأعطال التي لا تظهر كأعطال

أخطر ما في مشاكل الـ API أن الموقع يبدو سليمًا. الصفحة تفتح، لكن جزءًا من العمل لم يكتمل:

• الدفع: العملية نجحت عند البوابة، لكن الإشعار لم يصل إلى ووردبريس. إعادة المحاولة دون تحقق قد تخصم المبلغ مرتين.
• الـ CRM: الطلب محفوظ في ووردبريس، وفريق المبيعات لا يراه.
• المخزون: التحديثات توقفت، والمتجر يعرض منتجًا نفد.
• الويب هوك (Webhook): البوابة أرسلت الإشعار مرتين، فوصلت العميلَ رسالتا تأكيد أو تكرر تحديث الطلب.

القاعدة عند انتهاء مهلة الاتصال (Timeout): موقعك توقف عن الانتظار، لكن الخدمة الأخرى ربما أكملت العملية. تحقق من النتيجة عندها قبل أن تكرر أي عملية دفع أو إنشاء سجل.

خطة عملية لكل اتصال خارجي

1. اضبط المهلة بنفسك وافحص الخطأ

دوال ووردبريس مثل wp_remote_get() وwp_remote_post() تعيد إما مصفوفة الرد أو كائن WP_Error. المهلة الافتراضية 5 ثوانٍ حسب توثيق الدالة، وهي ليست مناسبة لكل ميزة: اقتراحات البحث تحتاج أقل، واستيراد ليلي يحتمل أكثر.

$response = wp_remote_post( 'https://api.example-crm.com/v1/leads', array(
    'timeout' => 4,
    'headers' => array(
        'Authorization' => 'Bearer ' . MY_CRM_API_KEY, // defined in wp-config.php
        'Content-Type'  => 'application/json',
    ),
    'body'    => wp_json_encode( $lead ),
) );

if ( is_wp_error( $response ) ) {
    error_log( 'CRM request failed: ' . $response->get_error_message() );
    return false;
}

$code = wp_remote_retrieve_response_code( $response );
if ( $code < 200 || $code >= 300 ) {
    error_log( 'CRM returned HTTP ' . $code );
    return false;
}

تنبيه: مفاتيح الـ API السرية مكانها wp-config.php أو متغيرات البيئة على الخادم، بأقل صلاحيات لازمة، وبمفتاح منفصل لبيئة الاختبار. لا تضعها في كود JavaScript ولا تطبعها في السجلات.

2. انقل ما يمكن تأجيله إلى الخلفية

اسأل عن كل اتصال: هل يحتاج الزائر نتيجته الآن؟ إضافة العميل لقائمة البريد لا يجب أن تؤخر صفحة تأكيد الطلب. انقلها إلى مهمة مجدولة، وتأكد أن هناك طريقة لمعرفة إن فشلت، لأن مهمة خلفية تفشل بصمت أسوأ من مهمة بطيئة.

في ووردبريس: WooCommerce يأتي مع مكتبة Action Scheduler لجدولة المهام في الخلفية، ويعرض المهام المعلقة والفاشلة في WooCommerce ← الحالة ← Scheduled Actions. هذا مكان مناسب لمراقبة مهام المزامنة.

3. حدّد عدد مرات إعادة المحاولة

لو ردت الخدمة بأنها مشغولة أو غير متاحة مؤقتًا، أعد المحاولة مع زيادة الانتظار في كل مرة، والتزم بأي مدة انتظار يحددها المزود في رده، وضع حدًا أقصى تتوقف بعده المهمة.

4. امنع التكرار في الدفع والويب هوك

في الدفع، أرسل مفتاح عدم التكرار (Idempotency Key) مع الطلب إن كانت البوابة تدعمه، واستخدم المفتاح نفسه عند إعادة المحاولة. توثيق Stripe مثلًا يشرح أن إعادة الطلب بالمفتاح نفسه تعيد الرد المحفوظ للطلب الأول بدل تنفيذ العملية مرة ثانية، وأن المفاتيح قد تُحذف بعد 24 ساعة على الأقل.

أما الويب هوك فاحفظ معرّف كل حدث يصلك، وتجاهل أي حدث سبق أن عالجته:

function acms_handle_payment_event( $event_id, $payload ) {
    $key = 'acms_evt_' . md5( $event_id );

    if ( get_transient( $key ) ) {
        return; // already processed
    }
    set_transient( $key, 1, DAY_IN_SECONDS );

    // update the order here
}

بصراحة: هذا القسم قراءة للتوثيق وأفضل الممارسات، لا نتيجة اختبار على بوابة بعينها. راجع توثيق بوابتك (Paymob أو Tap أو غيرهما) لمعرفة هل تدعم مفاتيح عدم التكرار، وكيف توقّع إشعاراتها لتتحقق أنها منها فعلًا.

5. خزّن ما لا يتغير كل دقيقة

التوصيات وأسعار الصرف لا تحتاج طلبًا جديدًا مع كل زيارة، أما المخزون فقد يحتاج. استخدم البيانات المؤقتة (Transient) بمدة تناسب سرعة تغيّر البيانات:

$rates = get_transient( 'acms_shipping_zones' );

if ( false === $rates ) {
    $response = wp_remote_get( 'https://api.example-shipping.com/v1/zones', array( 'timeout' => 3 ) );
    if ( ! is_wp_error( $response ) && 200 === wp_remote_retrieve_response_code( $response ) ) {
        $rates = json_decode( wp_remote_retrieve_body( $response ), true );
        set_transient( 'acms_shipping_zones', $rates, 6 * HOUR_IN_SECONDS );
    }
}

6. جهّز رسالة لكل فشل

لو لم ترد خدمة التوصيات، اعرض قائمة منتجات عادية. لو لم تتأكد من نتيجة الدفع، قل للعميل ذلك بوضوح ودلّه على صفحة طلباته. لا تعرض رسالة نجاح قبل أن تتأكد أن العملية اكتملت.

اختبر الفشل قبل أن يحدث

على بيئة الاختبار (Staging) اجعل أحد الاتصالات يتأخر أو تنتهي مهلته عمدًا، وجرّب أثناء ذلك إتمام طلب وتسجيل الدخول. أرسل الويب هوك نفسه مرتين وتأكد أن الطلب تحدّث مرة واحدة. ثم تتبع العملية حتى نهايتها: طلب واحد لا اثنان، والعميل ظهر فعلًا في الـ CRM.

لمعرفة أين يذهب الوقت، أدوات المتصفح تكشف الطلبات التي تخرج من المتصفح فقط. أما ما يفعله الخادم أثناء الانتظار فيحتاج مراقبة من جهة الخادم، مثل أدوات APM التي توفرها بعض الاستضافات المُدارة، أو إضافة مثل Query Monitor التي تعرض طلبات HTTP الصادرة من الصفحة.

في JetEngine: لو موقعك يعرض بيانات من API خارجي في Listing، أو يرسل نموذج JetFormBuilder بياناته عبر إجراء Webhook، فهذه اتصالات تدخل في جدولك أيضًا. اعرف أي منها يعمل أثناء طلب الزائر، واختبره وهو بطيء.

أسئلة لملف كل عميل

احفظ إجابات هذه الأسئلة في توثيق الموقع، مع اسم المسؤول عن كل اتصال:

• ما الخدمات التي يعتمد عليها الموقع، وأيها يوقف الزائر؟
• كم ينتظر كل اتصال قبل أن يستسلم؟ وهل يعيد المحاولة تلقائيًا؟
• هل يمكن أن تسبب إعادة المحاولة خصمًا أو سجلًا أو بريدًا مكررًا؟
• أين المفاتيح السرية، ومن يستطيع تغييرها؟
• أين تتحقق من أن المهام المجدولة والويب هوك اكتملت؟

الأسئلة الشائعة

س: كيف أربط موقع ووردبريس بـ API خارجي بدون إضافة؟
ج: عبر دوال HTTP المدمجة مثل wp_remote_get() وwp_remote_post() داخل إضافة صغيرة أو ملف functions.php في قالب فرعي. اضبط المهلة وافحص is_wp_error() ورمز الحالة في كل طلب.

س: ما المهلة المناسبة لطلبات الـ API في ووردبريس؟
ج: لا يوجد رقم واحد. الطلبات التي ينتظرها الزائر تحتاج مهلة قصيرة مع رسالة واضحة عند الفشل، والمهام الخلفية تحتمل مهلة أطول. الافتراضي في ووردبريس 5 ثوانٍ.

س: لماذا يصلني إشعار الدفع مرتين؟
ج: كثير من البوابات تعيد إرسال الويب هوك إذا لم يصلها رد نجاح سريع من موقعك. احفظ معرّف كل حدث وتجاهل المكرر، ورد على البوابة بسرعة ثم أكمل المعالجة.

س: هل ترقية الاستضافة تحل بطء الـ API؟
ج: أحيانًا، حين تكون عمليات PHP مشغولة فعلًا. لكن افحص أولًا الطلبات غير الضرورية والمهلات الطويلة وإعادات المحاولة المتكررة، لأنها قد تستهلك الموارد المتاحة بالكامل.

الخلاصة

موقع ووردبريس اليوم يعتمد على خدمات خارجية في الدفع والشحن والتسويق والذكاء الاصطناعي، وموثوقيته من موثوقية هذه الاتصالات. حدّد ما ينتظره الزائر، واضبط المهلة، وامنع التكرار، واختبر الفشل قبل أن يحدث.

ابدأ بحاجة واحدة بس: صفحة الدفع أو نموذج التسجيل، وتتبّعها لحد آخرها. ولو محتاج خطة فيها عمليات PHP كفاية وسجلات واضحة، شوف جرّب Hostinger“>استضافة Hostinger.

مراجع إضافية: wp_remote_get() — WordPress Developer Resources، Idempotent requests — Stripe API

مرجع المقال (بالإنجليزية): Every website is becoming an API consumer
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.