صيانة متجر WooCommerce: ما الذي يختلف عن موقع ووردبريس عادي؟

إذا تعطّل موقع ووردبريس تعريفي لساعة، فالخسارة غالبًا صورة سيئة أمام بعض الزوار. أما إذا تعطّلت صفحة الدفع في متجرك لساعة، فالخسارة طلبات لم تكتمل وأموال لم تصل. لهذا لا تُعامَل صيانة WooCommerce كنسخة مكررة من صيانة أي موقع ووردبريس: الأساسيات واحدة (تحديثات، نسخ احتياطي، مراقبة)، لكن طريقة تنفيذها في المتجر مختلفة جذريًا.

في هذا المقال نركّز على ما يخص المتاجر فعلًا: التحديثات التي تكسر صفحة الدفع، وبيئة الاختبار (staging) قبل كل تحديث، ومراقبة الطلبات الفاشلة، والنسخ الاحتياطي لقاعدة بيانات تتغير كل دقيقة. وفي النهاية قائمة بما يجب فحصه في كل زيارة صيانة.

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

لماذا لا تكفي صيانة ووردبريس العادية لمتجر WooCommerce؟

الموقع العادي في معظمه محتوى ثابت: صفحات ومقالات تتغير بين حين وآخر.
المتجر نظام حيّ: سلة، ودفع، ومخزون، وشحن، وضرائب، ورسائل بريد، وبوابات دفع خارجية تتواصل مع موقعك في الخلفية.
كل إضافة من هذه الإضافات تُحدَّث وفق جدولها الخاص، وأي تعارض بينها يظهر غالبًا في أكثر مكان حساس: صفحة الدفع.

الخلاصة: في المتجر، السؤال ليس «هل الموقع يعمل؟» بل «هل يعمل مسار الشراء من أول نقرة حتى وصول رسالة تأكيد الطلب؟».

التحديثات التي تكسر صفحة الدفع

أغلب أعطال المتاجر لا تأتي من اختراق أو ضغط زيارات، بل من تحديث عادي جدًا. وأشهر مصادرها:

• إضافات بوابات الدفع: تحديث بوابة الدفع قد يغيّر طريقة تحميل نموذج البطاقة أو طريقة استقبال تأكيد الدفع (webhook). النتيجة: عميل يدفع، والطلب يبقى «بانتظار الدفع».

• قوالب WooCommerce المعدَّلة في الثيم: كثير من الثيمات تستبدل ملفات قوالب WooCommerce بنسخها الخاصة. عندما يُحدَّث WooCommerce وتبقى نسخة الثيم قديمة، قد تختفي حقول أو تتعطل خطوات. يعرض تقرير حالة النظام في WooCommerce هذه القوالب القديمة صراحةً، كما توضح الوثائق الرسمية لتقرير حالة النظام.

• الانتقال بين صفحة الدفع التقليدية وصفحة الدفع المبنية بالمكوّنات (Blocks): بعض الإضافات القديمة لا تدعم الأسلوب الجديد، فتختفي حقولها أو خيارات الشحن التي تضيفها دون أي رسالة خطأ.

• إضافات التخزين المؤقت والأداء: إعداد خاطئ بعد تحديث قد يجعل السلة أو صفحة الدفع تُخزَّن مؤقتًا، فيرى عميلٌ سلةَ عميل آخر أو تفشل عملية الدفع.

• تعارضات JavaScript: تحديث إضافة واحدة قد يكسر سكربت صفحة الدفع، فيضغط العميل «إتمام الطلب» ولا يحدث شيء.

كيف تُحدَّث إضافات المتجر بأمان؟

1. لا تفعّل التحديث التلقائي لإضافات الدفع والشحن و WooCommerce نفسه. هذه تحديثات تُطبَّق بقرار وبعد اختبار.

2. حدّث الإضافات الحساسة واحدة تلو الأخرى، حتى إذا ظهر عطل تعرف فورًا من سببه.

3. اتبع إيقاعًا منتظمًا: توصي WooCommerce في دليل تحديث WooCommerce بإيقاع شهري يناسب أغلب المتاجر، مع تسريع تحديثات الأمان.

4. اختر وقت التحديث بعناية: بعيدًا عن ساعات الذروة والعروض والحملات الإعلانية.

بيئة staging قبل كل تحديث: ليست رفاهية

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

قواعد لا يجب كسرها في staging المتاجر

• حوّل بوابات الدفع إلى وضع الاختبار (sandbox) حتى لا تُسحب مبالغ حقيقية أثناء التجربة.

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

• لا تنقل قاعدة البيانات من staging إلى المتجر الحي أبدًا. خلال فترة الاختبار دخلت طلبات جديدة إلى المتجر الحقيقي، ونقل قاعدة بيانات staging فوقه يمحوها. ما يُنقل بعد نجاح الاختبار هو التحديثات نفسها، لا البيانات.

• امنع محركات البحث من فهرسة نسخة الاختبار حتى لا تظهر نسخة مكررة من متجرك في النتائج.

ماذا تختبر على staging؟

• إضافة منتج بسيط ومنتج متغيّر (مقاسات/ألوان) إلى السلة.

• تطبيق كوبون خصم.

• حساب الشحن والضرائب لأكثر من عنوان.

• إتمام طلب تجريبي بكل بوابة دفع مفعّلة.

• وصول رسالة تأكيد الطلب للعميل وإشعار الطلب للإدارة.

• ظهور الطلب بشكل صحيح في لوحة التحكم، وتجربة الاسترداد إن أمكن.

وعند تطبيق التحديث على المتجر الحي، توصي WooCommerce بوضع المتجر في وضع «قريبًا» (Coming soon) خلال نافذة التحديث القصيرة، حتى لا يدخل عميل في منتصف عملية دفع بينما تتغير الملفات وقاعدة البيانات.

مراقبة الطلبات الفاشلة: المؤشر الذي لا تراه مراقبة التوفّر

أداة مراقبة التوفّر (uptime) تسأل سؤالًا واحدًا: هل الصفحة الرئيسية ترد؟ وقد ترد الصفحة بشكل طبيعي تمامًا بينما لا يستطيع أي عميل إتمام الدفع. لذلك مراقبة المتجر تحتاج طبقة إضافية تنظر إلى الطلبات نفسها:

• نسبة الطلبات «الفاشلة» (Failed): ارتفاع مفاجئ بعد تحديث يعني غالبًا مشكلة في بوابة الدفع.

• تراكم الطلبات «بانتظار الدفع» (Pending payment): إذا كان العملاء يدفعون والطلبات لا تتحول إلى «قيد التنفيذ»، فالأرجح أن تأكيدات الدفع (webhooks) لا تصل إلى موقعك.

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

• سجلات WooCommerce: قسم السجلات (Logs) في صفحة حالة النظام يحفظ الأخطاء الفادحة وسجلات بوابات الدفع، وهو أول مكان تُفتح فيه القضية.

• المهام المجدولة: يعتمد WooCommerce على مهام مجدولة في الخلفية (رسائل، تحديث مخزون، اشتراكات). تراكم المهام الفاشلة أو المتأخرة يعني أن شيئًا في الخلفية متوقف.

الفكرة الأساسية: قارن دائمًا بخط الأساس الطبيعي لمتجرك. الرقم وحده لا يقول شيئًا، أما التغيّر المفاجئ بعد تحديث أو تعديل فهو ما يكشف العطل مبكرًا.

لمراقبة التوفّر وشهادات SSL والنطاقات والتحديثات المعلّقة لعدة مواقع من لوحة واحدة، نعمل على Pomnex Pulse. وحتى إطلاقه، المراقبة جزء من خطة الصيانة لدينا.

النسخ الاحتياطي لقاعدة بيانات تتغير كل دقيقة

في الموقع العادي، نسخة احتياطية يومية تعني أنك في أسوأ الأحوال تخسر مقالًا أو تعديلًا. في المتجر، النسخة اليومية تعني أن استعادتها قد تمحو كل الطلبات التي دخلت منذ آخر نسخة: أسماء العملاء، والعناوين، والمبالغ المدفوعة، وحالة المخزون.

ما الذي يتغيّر في استراتيجية النسخ الاحتياطي للمتجر؟

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

• تأكد أن جداول الطلبات مشمولة: في المتاجر الحديثة تُخزَّن الطلبات في جداول مخصصة ضمن ميزة تخزين الطلبات عالي الأداء (HPOS). أي أداة نسخ تستثني الجداول غير القياسية ستعطيك نسخة ناقصة دون أن تنتبه.

• نسخة قبل كل تحديث: لا يُطبَّق أي تحديث على المتجر الحي قبل نسخة احتياطية حديثة من الملفات وقاعدة البيانات.

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

• اختبر الاستعادة فعليًا: النسخة التي لم تُجرَّب استعادتها مجرد افتراض.

الاستعادة في متجر ليست زرًا واحدًا

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

ما يُفحص في كل زيارة صيانة لمتجر WooCommerce

هذه القائمة التي نوصي بها لكل جولة صيانة في متجر:

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

2. تحديث WooCommerce والإضافات والثيم بترتيب مدروس، والإضافات الحساسة (الدفع، الشحن، الاشتراكات) كلٌّ على حدة.

3. فحص تقرير حالة النظام: قوالب الثيم القديمة، وتحديثات قاعدة البيانات المطلوبة، والتحذيرات.

4. طلب تجريبي كامل بعد التحديث: سلة، كوبون، شحن، دفع، رسالة تأكيد.

5. مراجعة الطلبات الفاشلة والمعلّقة منذ الزيارة السابقة ومقارنتها بالمعدل الطبيعي.

6. مراجعة سجلات الأخطاء والمهام المجدولة المتأخرة أو الفاشلة.

7. فحص أمني: تغييرات ملفات غير متوقعة، وثغرات معروفة في الإضافات المثبتة.

8. فحص الأداء: زمن تحميل صفحات المنتجات والسلة والدفع، لأن البطء في الدفع يعني سلات متروكة.

9. ملخص مكتوب: ما حُدِّث، وما اكتُشف، وما يحتاج قرارًا من صاحب المتجر.

هذا بالضبط نوع العمل الذي تتولاه خدمة صيانة ورعاية ووردبريس من Pomnex: تحديثات النواة والإضافات والثيمات، ونسخ احتياطية مجدولة للملفات وقاعدة البيانات، ومراقبة الأمان والتوفّر والأداء، وفحص الموقع بعد كل جولة تحديث، وإصلاح ما يكسره التحديث ضمن الخطة لا كفاتورة إضافية. متاجر WooCommerce مشمولة في الخطة القياسية مع عناية إضافية حول التحديثات، أما المتاجر الكبيرة وصفحات الدفع المعقدة فتُسعَّر بشكل منفصل. ويمكنك الاطلاع على طريقة عملنا قبل أن تقرر.

متى يحتاج متجرك أكثر من الصيانة؟

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

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

هل تختلف صيانة WooCommerce عن صيانة ووردبريس العادية؟

نعم. الأدوات نفسها تقريبًا، لكن المتجر يحتاج اختبار مسار الشراء بعد كل تحديث، ونسخًا احتياطية أكثر تكرارًا لقاعدة البيانات، ومراقبة للطلبات الفاشلة لا لتوفّر الموقع فقط.

هل يمكن تفعيل التحديث التلقائي لإضافات المتجر؟

يمكن لبعض الإضافات منخفضة المخاطر، لكن لا يُنصح به لـ WooCommerce نفسه ولا لإضافات الدفع والشحن والاشتراكات. هذه تُحدَّث بعد اختبار على بيئة staging.

كم مرة يجب أخذ نسخة احتياطية لمتجر WooCommerce؟

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

الموقع يعمل لكن الطلبات توقفت، من أين أبدأ؟

ابدأ بسجلات WooCommerce وسجل بوابة الدفع، ثم تحقق من الطلبات العالقة في حالة «بانتظار الدفع»، ثم راجع آخر تحديث طُبّق على المتجر. في أغلب الحالات يكون السبب واحدًا من هذه الثلاثة.

الخلاصة

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

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