الانتقال إلى Checkout Block في WooCommerce دون كسر الدفع

الانتقال إلى Checkout Block في WooCommerce يمكن أن يمنح المتجر مسار دفع أحدث وأسهل في التخصيص، لكنه قد يكشف إضافات أو بوابات دفع تعتمد على الـshortcode القديم. التنفيذ الآمن يبدأ بجدول توافق واختبار كامل على Staging، ثم قياس التحويل والأخطاء قبل اعتماد الصفحة الجديدة.

منذ WooCommerce 8.3 أصبحت كتل Cart وCheckout هي التجربة الافتراضية للتثبيتات الجديدة، بينما ظل الـshortcode متاحًا للمتاجر القديمة والحالات التي لم تكتمل فيها توافقات الإضافات. يشرح هذا الدليل ترحيل Checkout Block في WooCommerce دون كسر الدفع أو الحقول المخصصة أو الشحن.

ما الفرق بين Checkout Block والـshortcode القديم؟

الصفحة التقليدية تستخدم [woocommerce_check​out] وتعتمد غالبًا على PHP hooks وقوالب WooCommerce. أما Checkout Block فيبني تجربة الدفع ككتل ديناميكية تتصل بواجهات Store API وتستخدم JavaScript extensibility. لذلك لا تنتقل كل تخصيصات woocommerce_checkout_* تلقائيًا إلى البلوك.

ليست إحدى التجربتين أفضل دائمًا. القرار الصحيح يعتمد على إضافات المتجر والعملاء والأجهزة. نجاح Checkout Block في WooCommerce يقاس بنسبة إتمام الطلب وصحة الضرائب والشحن والدفع، لا بمظهر الصفحة وحده.

متى يكون الانتقال منطقيًا؟

• بوابات الدفع والشحن الأساسية تعلن توافقها مع Cart and Checkout Blocks.
• لا توجد حقول حرجة مضافة عبر hooks قديمة فقط.
• تريد تجربة Express Checkout أو Local Pickup المبنية للبلوك.
• تملك Staging واختبارات لسيناريوهات الدفع والفشل والاسترداد.
• يمكنك مقارنة بيانات التحويل قبل وبعد التغيير.

إذا كان المتجر يعتمد على إضافة اشتراكات أو Checkout Add-ons أو بوابة محلية قديمة، افحص التوافق أولًا. بعض الإضافات تعرض جزءًا من وظائفها في البلوك وتفقد جزءًا آخر. الانتقال إلى Checkout Block في WooCommerce لا يجب أن يحذف حقلًا قانونيًا أو طريقة دفع مهمة.

الخطوة الأولى: أنشئ مصفوفة توافق

اكتب قائمة بكل مكون يعمل في الدفع: بوابات الدفع، الشحن، الضرائب، العنوان، الحقول المخصصة، الكوبونات، الاشتراكات، النقاط، العملات، مكافحة الاحتيال، Pixels وWebhooks. أمام كل مكون سجل هل يدعم Checkout Block بالكامل أو جزئيًا أو لا يدعمه.

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

الخطوة الثانية: احفظ خط أساس للتحويل

قبل تغيير الصفحة، سجل معدل بدء الدفع، ومعدل الإكمال، وأخطاء البوابة، ومتوسط زمن تحميل checkout، ونسبة الهاتف، وأكثر الحقول التي تسبب Validation errors. افصل البيانات حسب البوابة والجهاز والدولة. من دون خط أساس لن تعرف هل أدى Checkout Block في WooCommerce إلى تحسن حقيقي أم مجرد تصميم مختلف.

استخدم فترة كافية تمثل سلوك المتجر، وتجنب المقارنة بين أسبوع عروض وأسبوع عادي. راجع أيضًا دليل تفعيل الشراء السريع في WooCommerce حتى لا تخلط بين تقليل الخطوات وتغيير تقنية الصفحة. وإذا كان هدفك الأساسي تحسين التحويل قبل تغيير بنية الـCheckout، راجع أيضًا تقليل خطوات الدفع في WooCommerce لتحديد التحسينات ذات الأثر المباشر على تجربة الشراء.

الخطوة الثالثة: جهز صفحة Checkout تجريبية

1. أنشئ نسخة Staging حديثة من المتجر.
2. أنشئ صفحة جديدة وأضف إليها كتلة الدفع.
3. عيّن الصفحة مؤقتًا من WooCommerce ← الإعدادات ← متقدم.
4. لا تحذف صفحة الـshortcode؛ احتفظ بها للرجوع.
5. امسح الكاش واختبر في جلسة خاصة.

يتكون البلوك من Checkout Fields وCheckout Totals وعناصر داخلية ديناميكية. تظهر طرق الدفع المتوافقة فقط. إذا اختفت بوابة فهي ليست مشكلة CSS غالبًا؛ افحص توافقها وإعداداتها والسجل. كما يجب تعيين الصفحة بوصفها Checkout Page حتى تعمل خيارات مثل Local Pickup بطريقة صحيحة.

الخطوة الرابعة: اختبر الحقول والعناوين

يمكن من إعدادات Checkout Fields التحكم في إظهار Company وAddress Line 2 وPhone وتحديد الحقول المطلوبة. لا تحذف حقلًا لمجرد تقليل الخطوات إذا كان الشحن أو الفاتورة أو القانون المحلي يحتاجه. اختبر عناوين قصيرة وطويلة، ورموزًا بريدية مختلفة، وRTL، وإدخال العربية والإنجليزية.

إذا كانت لديك حقول مخصصة، تأكد أنها مبنية لامتدادات Checkout Block أو Additional Checkout Fields API المناسبة، وليست معروضة عبر hook قديم فقط. يجب أن تظهر القيمة في الطلب والبريد والفاتورة وREST API والتصدير. هذا بند حاسم عند ترحيل Checkout Block في WooCommerce.

الخطوة الخامسة: اختبر الدفع كاملًا

نفّذ مصفوفة سيناريوهات بدل طلب ناجح واحد:

• بطاقة ناجحة وبطاقة مرفوضة و3D Secure.
• الدفع عند الاستلام والتحويل البنكي إن كانا متاحين.
• Apple Pay أو Google Pay أو Express Checkout.
• منتج بسيط ومتغير وافتراضي وقابل للتنزيل.
• كوبون صالح وآخر منتهي وحد أدنى للطلب.
• شحن مجاني ومدفوع وLocal Pickup.
• ضريبة حسب عنوان مختلف للفوترة والشحن.
• إعادة تحميل الصفحة والعودة من بوابة خارجية.

في كل حالة تحقق من منع الطلب المكرر، وحالة الطلب، وخصم المخزون، ورسالة البريد، وبيانات المعاملة. إذا ظهر خلل مخزون راجع مشاكل WooCommerce الشائعة قبل اتهام البلوك.

الخطوة السادسة: اختبر الأداء وCore Web Vitals

صفحة الدفع ديناميكية ولا ينبغي تخزينها Page Cache. قس TTFB وحجم JavaScript وLong Tasks وطلبات Store API. اختبر هاتفًا متوسط الأداء وشبكة بطيئة، لأن تحسين الكمبيوتر قد يخفي تأخر الهاتف. راقب النقر على Place Order وتغير طرق الشحن، وليس تحميل الصفحة الأول فقط.

قد تتداخل سكربتات Analytics والدردشة وPixels مع JavaScript الخاص بالدفع. حمّل فقط ما تحتاجه، وتجنب تأخير ملفات WooCommerce الأساسية. راجع دليل حل بطء ووردبريس مع استثناء صفحات Cart وCheckout وMy Account من الكاش.

تخصيص كتلة الدفع بطريقة قابلة للصيانة

ابدأ بإعدادات البلوك والـGlobal Styles. عند الحاجة البرمجية استخدم واجهات WooCommerce الموثقة مثل Filter Registry وBlock Extensibility، ولا تنسخ مكونات داخلية غير عامة. التخصيص الذي يعتمد على class عشوائي قد ينكسر مع تحديث بسيط.

لتغيير نص زر إتمام الطلب مثلًا، استخدم الفلاتر المتاحة للبلوك ضمن JavaScript مسجل بشكل صحيح، وتحقق من السياق والترجمة. لا تعدل ملفات WooCommerce Core، ولا تضع كودًا غير موثق في functions.php دون نسخة احتياطية واختبار.

إطلاق التغيير تدريجيًا

1. اختر فترة منخفضة الحركة.
2. خذ نسخة احتياطية وأكد مسار الرجوع.
3. عيّن صفحة البلوك كصفحة Checkout.
4. امسح Object Cache/CDN مع إبقاء الصفحة مستثناة.
5. نفّذ طلبًا حقيقيًا منخفض القيمة.
6. راقب Payment logs وWooCommerce logs وJavaScript errors.
7. قارن التحويل والأخطاء يوميًا خلال أول أسبوع.

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

سيناريو اختبار Checkout Block قبل الإطلاق

افترض أن المتجر يستخدم بوابتين، وشحنًا حسب المدينة، وحقل رقم ضريبي، وMeta Pixel. ابدأ بطلب بسيط على Checkout Block من هاتف حقيقي. سجّل زمن ظهور طرق الشحن، وزمن استجابة اختيار البوابة، وعدد النقرات حتى Place Order. ثم كرر الاختبار على صفحة الـshortcode بالبيانات نفسها.

في الاختبار الثاني استخدم عنوانًا يغير منطقة الشحن. يجب أن يعيد Checkout Block حساب السعر والضرائب دون تجميد أو فقد الحقول. راقب Network panel بحثًا عن Store API response غير ناجحة، ولا تعتبر spinner الطويل مشكلة تصميم قبل فحص الاستجابة.

في الاختبار الثالث استخدم بطاقة مرفوضة. يجب أن يعرض Checkout Block رسالة مفهومة ويبقي بيانات العميل والسلة، وألا ينشئ طلبات مكررة عند إعادة المحاولة. افحص سجل البوابة وOrder Notes وحدث purchase في Analytics.

أخيرًا اختبر الحقل الضريبي: ظهوره، والتحقق منه، وتخزينه، ووصوله إلى البريد والفاتورة. إذا ظهر على الواجهة ولم يصل إلى الطلب، فالتكامل غير مكتمل حتى لو بدا Checkout Block سليمًا بصريًا.

مقاييس تجربة المستخدم على الهاتف

تأتي نسبة كبيرة من زيارات المتاجر العربية من الهاتف، لذلك يجب اختبار لوحة المفاتيح، واتجاه RTL، ورسائل الخطأ، والتمرير إلى أول حقل غير صالح. يقاس نجاح Checkout Block بزمن إتمام المهمة، لا بسرعة تحميل العنوان فقط.

• الزمن من دخول الصفحة إلى أول تفاعل ممكن.
• الزمن بعد تغيير العنوان حتى تحديث الشحن.
• استجابة زر Place Order وعدم وجود نقرات مكررة.
• عدد أخطاء Validation لكل جلسة.
• نسبة العودة إلى Cart.
• معدل الإكمال حسب نظام التشغيل والبوابة.

إذا كان Checkout Block أبطأ على أجهزة معينة، افحص third-party scripts وحقول العنوان والبوابة، ثم أعد الاختبار. لا تحذف أدوات مكافحة الاحتيال دون تقييم المخاطر؛ حسّن تحميلها أو استخدم تكاملًا متوافقًا.

ضبط Analytics دون تكرار أحداث الشراء

قد تختلف نقاط الربط بين الصفحة التقليدية وCheckout Block. تحقق من أن begin_checkout يطلق مرة واحدة وأن purchase لا يطلق عند إعادة تحميل صفحة الشكر. قارن Order ID والقيمة والعملة بين WooCommerce وGA4 وMeta.

استخدم Preview/Debug modes وسجل رحلة اختبار كاملة. إذا كانت إضافة التتبع تعتمد على selector أو hook قديم، حدّثها أو استخدم التكامل الرسمي. أرقام التحويل الخاطئة قد تجعلك تحكم على Checkout Block بصورة غير دقيقة.

التعامل مع بوابات الدفع غير المتوافقة

إذا كانت بوابة مهمة لا تظهر في Checkout Block، الخيارات الآمنة ثلاثة: تحديث البوابة، التواصل مع المطور لإضافة Block integration، أو إبقاء الـshortcode مؤقتًا. لا تحاول حقن نموذج البوابة القديم داخل البلوك بكود JavaScript سريع؛ قد تفشل الـnonce أو tokenization أو 3DS.

للبوابة المخصصة، اتبع WooCommerce payment method integration للكتل، وسجل scripts وبيانات الإعداد بطريقة صحيحة، ونفّذ معالجة الدفع على الخادم مع sanitization وvalidation. اختبر عدم تخزين بيانات بطاقة حساسة داخل WordPress.

قائمة قبول نهائية قبل تعيين الصفحة

لا تطلق Checkout Block إذا بقي بند حرج غير مكتمل. يمكن قبول اختلاف شكلي مؤقت، لكن لا يمكن قبول فقد طريقة دفع أو حقل قانوني أو حدث شراء. بعد الإطلاق راقب Conversion rate وPayment failures لمدة أسبوع على الأقل.

أخطاء شائعة

أسئلة شائعة

هل Checkout Block أسرع دائمًا؟

لا. يعتمد الأداء على القالب والبوابات والسكربتات والخادم. قس التفاعل وStore API على الهاتف.

لماذا لا تظهر بوابة الدفع؟

قد لا تدعم البلوك، أو لا تتوفر وفق العملة والدولة والسلة، أو يوجد خطأ JavaScript. ابدأ بالسجل ووثائق البوابة.

هل تعمل PHP hooks القديمة؟

بعضها لا ينعكس على البلوك. استخدم واجهات Block Extensibility الرسمية أو نسخة الإضافة المتوافقة.

هل يمكن الرجوع للـshortcode؟

نعم، أعد تعيين الصفحة التقليدية من الإعدادات المتقدمة، بشرط أنك احتفظت بها واختبرتها.

كيف أعرف أن الترحيل ناجح؟

ثبات معدل نجاح الدفع، وعدم فقد الحقول أو البوابات، وتحسن أو ثبات التحويل دون زيادة أخطاء JavaScript والخادم.

مصادر موثوقة

• وثائق Checkout Block الرسمية
• WooCommerce Block Extensibility
• صفحات WooCommerce والـshortcodes

الخلاصة: أفضل طريقة لاعتماد Checkout Block في WooCommerce هي فحص التوافق، وحفظ خط أساس، واختبار كل طرق الدفع والحقول والشحن، ثم الإطلاق مع مسار رجوع فوري. لا تجعل الشكل الجديد يتقدم على موثوقية الطلب والتحويل.