تفعيل HPOS في WooCommerce: ترحيل الطلبات بأمان

تفعيل HPOS في WooCommerce ينقل بيانات الطلبات من الاعتماد الأساسي على جدولي posts وpostmeta إلى جداول مخصصة للطلبات. الفائدة هي استعلامات أوضح وقابلية توسع أفضل، لكن الانتقال في متجر قائم يجب أن يسبقه فحص توافق الإضافات، ومزامنة كاملة، ونسخة احتياطية قابلة للاستعادة.

لا تتعامل مع HPOS كزر تسريع فوري. قد يتحسن أداء إدارة الطلبات والتقارير في المتاجر الكبيرة، لكن النتيجة تعتمد على حجم البيانات وطريقة كتابة الإضافات والاستعلامات. يقدم هذا الدليل طريقة آمنة لـتفعيل HPOS في WooCommerce مع اختبار قبل وبعد وخطة رجوع تمنع فقد الطلبات.

ما هو HPOS في WooCommerce؟

HPOS اختصار High-Performance Order Storage، وكان معروفًا أثناء التطوير باسم Custom Order Tables. بدل تخزين كل طلب كـCustom Post وحقوله في wp_postmeta، يستخدم WooCommerce جداول مخصصة مثل wp_wc_orders وwp_wc_order_addresses وwp_wc_order_operational_data وwp_wc_orders_meta. بادئة الجداول قد تختلف إذا كانت بادئة WordPress لديك ليست wp_.

منذ WooCommerce 8.2 أصبح HPOS مستقرًا ومفعّلًا افتراضيًا في التثبيتات الجديدة. أما المتاجر القديمة فتحتاج إلى مزامنة البيانات وفحص توافق الإضافات قبل التحويل. لهذا السبب يجب أن يكون تفعيل HPOS في WooCommerce مشروع ترحيل صغيرًا، لا تعديلًا سريعًا في وقت الذروة.

متى يكون تفعيل HPOS مفيدًا؟

• المتجر يملك عددًا كبيرًا من الطلبات ويعاني بطء البحث أو شاشة الطلبات.
• جدول postmeta ضخم وتوجد استعلامات مكلفة مرتبطة بالطلبات.
• التكاملات الحديثة تستخدم WooCommerce CRUD ولا تستعلم عن posts مباشرة.
• تحتاج إلى فصل منطقي أوضح بين محتوى WordPress وبيانات التجارة.
• لديك بيئة Staging تستطيع محاكاة الدفع والشحن والاسترداد عليها.

إذا كان المتجر صغيرًا ومستقرًا فلن يكون التحسن بالضرورة ملحوظًا للمستخدم. القرار الصحيح لـتفعيل HPOS في WooCommerce يعتمد على قياس زمن استعلامات الطلبات وحجم الجداول، لا على وعود عامة. ابدأ بخط أساس من Query Monitor وسجلات MySQL وزمن فتح قائمة الطلبات.

المتطلبات قبل التفعيل

1. نسخة حديثة مستقرة من WordPress وWooCommerce.
2. نسخة احتياطية كاملة للملفات وقاعدة البيانات، مع تجربة استعادة.
3. بيئة Staging حديثة لا تستقبل طلبات حقيقية.
4. قائمة بكل إضافات الدفع والشحن والفواتير والاشتراكات والتقارير.
5. وقت صيانة منخفض الحركة وخطة تواصل عند الحاجة.
6. وصول إلى WooCommerce logs وPHP error log وقاعدة البيانات.

ابدأ بمراجعة منهج صيانة المتاجر، ولا تستخدم نسخة Staging قديمة لأن اختبار التوافق عليها يعطي نتيجة مضللة. يجب أن تحتوي النسخة التجريبية على بنية الطلبات والإضافات نفسها مع إخفاء البيانات الحساسة.

الخطوة الأولى: افحص توافق الإضافات

انتقل إلى WooCommerce ← الإعدادات ← متقدم ← الميزات. إذا أظهر WooCommerce إضافات غير متوافقة مع HPOS، فلا تتجاوز التحذير. حدّث الإضافة وابحث في changelog عن HPOS compatibility أو تواصل مع المطور. أخطر الإضافات هي التي تقرأ الطلبات مباشرة من wp_posts أو تكتب حقولًا في postmeta دون استخدام CRUD.

افحص خصوصًا بوابات الدفع، إضافات الشحن، طباعة الفواتير، CRM، ERP، الاشتراكات، نقاط الولاء، التصدير المحاسبي وأدوات التقارير. قد ينجح إنشاء الطلب بينما تفشل مرحلة لاحقة بصمت. لذلك لا يكتمل تفعيل HPOS في WooCommerce باختبار زر «إتمام الطلب» فقط.

اختبار برمجي سريع

في الإضافات المخصصة، استخدم WooCommerce CRUD مثل wc_get_order() وطرق كائن الطلب. تجنب الاستعلامات التي تفترض أن ID الطلب هو post من نوع shop_order. ويمكن فحص تفعيل HPOS برمجيًا دون الاعتماد على قيمة option ثابتة:

<?php
use Automattic\WooCommerce\Utilities\OrderUtil;

if ( class_exists( OrderUtil::class ) && OrderUtil::custom_orders_table_usage_is_enabled() ) {
    // Custom order tables are enabled. Use WooCommerce CRUD APIs.
}

ضع هذا النوع من الفحص داخل إضافة مخصصة أو MU Plugin وفق الحاجة، ولا تعدل WooCommerce Core أو ملفات القالب الأب.

الخطوة الثانية: فعّل Compatibility Mode والمزامنة

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

راقب WooCommerce ← الحالة ← الإجراءات المجدولة. إذا تراكمت المهام أو فشلت، أصلح Action Scheduler وWP-Cron أولًا. تشغيل تفعيل HPOS في WooCommerce فوق طابور متعطل قد يترك نسختين غير متزامنتين من بيانات الطلبات.

الخطوة الثالثة: تحقق من تطابق البيانات

لا تكتفِ برسالة «Sync complete». اختر عينة تشمل طلبات جديدة وقديمة، حالات مختلفة، طلبًا مستردًا، طلبًا يحتوي كوبونًا، وطلبًا ببيانات شحن منفصلة. قارن:

• رقم الطلب والتاريخ والحالة والعملة والإجمالي.
• بيانات العميل والفوترة والشحن.
• بنود المنتجات والضرائب والشحن والخصومات.
• الملاحظات وTransaction ID والحقول المخصصة الضرورية.
• التقارير والتصدير والفاتورة وربط النظام الخارجي.

إذا ظهر اختلاف، أوقف الانتقال وحدد الإضافة أو الحقل الذي لم تتم مزامنته. لا تستخدم استعلام UPDATE عام لتصحيح آلاف الصفوف قبل فهم المصدر. راجع تشخيص أعطال قاعدة بيانات ووردبريس إذا ظهرت timeouts أو أخطاء اتصال أثناء المزامنة.

الخطوة الرابعة: فعّل HPOS على Staging

بعد اكتمال المزامنة اختر High-Performance Order Storage كمصدر أساسي للطلبات، واترك Compatibility Mode مفعّلًا مؤقتًا. نفّذ سيناريوهات حقيقية بدل اختبار واحد:

1. طلب كزائر باستخدام بوابة دفع Online.
2. طلب مسجل الدخول مع كوبون وشحن.
3. دفع فاشل ثم إعادة المحاولة.
4. تغيير الحالة وإرسال الرسائل.
5. استرداد كامل وجزئي.
6. تعديل المخزون وإلغاء الطلب.
7. تصدير الطلب إلى CRM أو ERP.
8. تشغيل تقرير المبيعات والضرائب.

سجّل نتيجة كل سيناريو قبل تفعيل HPOS في WooCommerce وبعده. إذا تغيرت النتيجة، التقط WooCommerce log وstack trace واسم الإضافة. راجع أيضًا مشاكل WooCommerce الشائعة للفصل بين عطل قديم وعطل سببه الانتقال.

الخطوة الخامسة: قس الأداء بطريقة صحيحة

قارن زمن فتح قائمة الطلبات والبحث عن عميل وتصفية الحالة وإنشاء طلب وتحديثه. استخدم العدد نفسه من الطلبات والنسخة نفسها من الكاش. راقب slow query log ووقت PHP والذاكرة، ولا تعتمد على سرعة انطباعية من جلسة واحدة.

قد لا يتغير TTFB للواجهة الأمامية كثيرًا لأن HPOS يستهدف الطلبات أكثر من صفحات المحتوى. هذا طبيعي. الفائدة الحقيقية تظهر في قابلية التوسع وعمليات الإدارة والتكاملات.

خطة الانتقال إلى الموقع الحي

1. حدد نافذة صيانة قصيرة منخفضة الطلبات.
2. خذ نسخة احتياطية جديدة واختبر الوصول إليها.
3. حدّث Staging بالطلبات الجديدة أو أعد الاختبار على نسخة حديثة.
4. فعّل Compatibility Mode وانتظر المزامنة الكاملة.
5. تحقق من عينة طلبات وحالة Scheduled Actions.
6. فعّل التخزين المخصص واترك المزامنة الثنائية مؤقتًا.
7. نفّذ طلبًا حقيقيًا منخفض القيمة ثم استرداده إن أمكن.
8. راقب السجلات والتقارير والتكاملات 48 إلى 72 ساعة.

بعد استقرار الترحيل يمكنك تقييم إيقاف Compatibility Mode. لا توقفه في اللحظة نفسها إذا كانت خطة الرجوع تعتمد على بقاء التخزين التقليدي محدثًا.

متى يجب الرجوع؟

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

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

سيناريو ترحيل متجر يملك مئات الآلاف من الطلبات

في متجر كبير لا تتوقع أن تنتهي المزامنة فورًا. يبدأ WooCommerce بدفعات محدودة حتى لا يحتجز قاعدة البيانات. سجّل عدد الطلبات الكلي وعدد الطلبات غير المتزامنة ومعدل الدفعات في الساعة. إذا كان المعدل ثابتًا ولا توجد Failed Actions، اترك العملية تعمل بدل زيادة الحجم عشوائيًا.

إذا تباطأت الدفعات، افحص Action Scheduler وWP-Cron وPHP workers وslow query log. قد يكون السبب إضافة تنفذ منطقًا ثقيلًا عند تحديث كل طلب. على Staging يمكنك تعطيل التكامل غير الضروري مؤقتًا لإثبات السبب، لكن لا تفعل ذلك على الإنتاج إذا كان مسؤولًا عن الفواتير أو المخزون.

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

فحص المطور للتوافق مع تخزين الطلبات المخصص

ابحث في الإضافة المخصصة عن WP_Query على shop_order، والوصول المباشر إلى postmeta، واستخدام get_post() مع IDs الطلبات. هذه أنماط تحتاج مراجعة. البديل هو wc_get_orders() وwc_get_order() وطرق CRUD مثل get_billing_email() وupdate_meta_data() ثم save().

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

<?php
add_action(
    'before_woocommerce_init',
    static function () {
        if ( class_exists( \Automattic\WooCommerce\Utilities\FeaturesUtil::class ) ) {
            \Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility(
                'custom_order_tables',
                __FILE__,
                true
            );
        }
    }
);

هذا الإعلان مناسب داخل ملف الإضافة الرئيسي بعد اختبارات شاملة. لا تضفه إلى functions.php لإجبار إضافة خارجية على الظهور كمتوافقة.

مراقبة البيانات بعد الانتقال

أنشئ قائمة تحقق يومية خلال أول أسبوع: عدد الطلبات، إجمالي المبيعات، عدد الاستردادات، الطلبات دون عنوان، أخطاء المزامنة، وFailed Scheduled Actions. قارن النتائج بتقارير البوابة ونظام المحاسبة، لا بلوحة WooCommerce وحدها.

خطة رجوع لا تفقد الطلبات الجديدة

قبل الإطلاق سجل وقت التحويل وآخر رقم طلب، واترك Compatibility Mode يعمل. عند ظهور مشكلة، أوقف التغييرات الثانوية وحدد هل البيانات لا تزال متزامنة. إذا كانت كذلك، أعد التخزين التقليدي كمصدر أساسي ثم اختبر الطلبات التي وصلت بعد التحويل.

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

تحسينات مكملة بعد استقرار الترحيل

• راجع الفهارس والاستعلامات المخصصة بدل إضافة indexes عشوائية.
• نظف سجلات قديمة وفق سياسة احتفاظ قانونية وتشغيلية.
• حدّث تكاملات التقارير لتستخدم WooCommerce APIs.
• راقب حجم جداول الطلبات ووقت النسخ الاحتياطي.
• اختبر الاستعادة الجزئية للطلبات على بيئة منفصلة.
• وثق الإضافات المتوافقة وإصداراتها داخل سجل الصيانة.

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

أسئلة شائعة

هل HPOS يسرّع كل صفحات المتجر؟

لا بالضرورة. التحسن الأكبر يرتبط بعمليات الطلبات والاستعلامات والتوسع، وليس كل صفحة منتج أو تصنيف.

هل يمكن تفعيل HPOS دون Compatibility Mode؟

في متجر قديم يجب مزامنة الطلبات أولًا. وضع التوافق يمنح مسارًا أكثر أمانًا للاختبار والرجوع.

لماذا يمنع WooCommerce التفعيل؟

غالبًا توجد طلبات غير متزامنة أو إضافة معلنة كغير متوافقة. عالج السبب بدل تجاوز التحذير.

هل يجب تعديل استعلامات الإضافة المخصصة؟

نعم إذا كانت تعتمد على wp_posts وpostmeta. استخدم WooCommerce CRUD وواجهات الاستعلام الرسمية.

متى أوقف Compatibility Mode؟

بعد نجاح كل السيناريوهات واستقرار السجلات والتكاملات عدة أيام ووجود نسخة احتياطية حديثة.

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

مصادر موثوقة

• وثائق WooCommerce الرسمية عن HPOS
• طريقة تفعيل HPOS ومزامنة الطلبات

الخلاصة: ينجح تفعيل HPOS في WooCommerce عندما تتعامل معه كترحيل بيانات: توافق، مزامنة، تحقق، اختبار، قياس، ثم مراقبة. التدرج وCompatibility Mode أهم من السرعة، خصوصًا في متجر حي يعتمد على بوابات دفع وتكاملات خارجية.