📑 المحتويات
التحديثات ضرورية للأمان — فالإضافة غير المحدَّثة أشيع سبب لاختراق المواقع. لكن التحديث في الوقت نفسه أكثر عملية قد تُعطّل موقعك. والحل ليس تأجيل التحديث، بل التحديث مع نقطة يمكنك العودة إليها .
لماذا يتعطّل الموقع عند التحديث تحديدًا؟
- عدم التوافق: قد يتعارض الإصدار الجديد مع إضافة أو قالب آخر تستخدمه.
- فارق إصدار PHP: قد يتطلّب الإصدار الجديد PHP أحدث؛ وإذا كان خادمك قديمًا ظهر خطأ.
- ترحيل قاعدة البيانات: بعض التحديثات تغيّر بنية قاعدة البيانات وقد تتوقّف العملية في منتصفها.
- طمس التخصيصات: تُمحى التعديلات التي أجريتها مباشرةً في ملفات القالب عند التحديث.
🎯 القاعدة الذهبية
خذ نسخة كاملة يدوية قبل التحديث مباشرةً . فإذا كانت نسختك المجدولة تعمل ليلًا وأنت تُحدّث صباحًا، فكل ما بينهما بلا نسخة. والنسخة اليدوية تسدّ هذه الفجوة.
الترتيب الآمن للتحديث
- خذ نسخة كاملة. نسخة تشمل الملفات وقاعدة البيانات معًا وتعود إلى تلك اللحظة بالذات.
- حدّث واحدًا تلو الآخر. فإن حدّثت الكل دفعةً واحدة ثم تعطّل شيء، لن تعرف أيها السبب.
- تحقّق بعد كل خطوة. الصفحة الرئيسية، وصفحة داخلية، وإرسال نموذج، ومسار الدفع إن وُجد.
- الإضافات أولًا ثم النواة — أو العكس؛ المهم أن يبقى الترتيب ثابتًا وأن تُجري تغييرًا واحدًا في كل مرة.
- إن ظهرت مشكلة فارجع. ولأن لديك نسخة أُخذت قبل قليل، تبقى الخسارة محصورة في دقائق.
ما هي بيئة الاختبار (staging)؟
بيئة الاختبار هي نسخة منفصلة من موقعك الحيّ. تجرّب التحديث فيها أولًا، ولا تطبّقه على الموقع الحيّ إلا بعد أن ترى أن كل شيء يعمل. ولا يرى زوّارك هذه النسخة، وحتى لو تعطّل فيها شيء فلن يتأثر موقعك الحيّ.
وتكون بيئة الاختبار قيّمة خصوصًا في هذه الحالات:
- القفزات الكبيرة في الإصدارات (مثلًا إصداران رئيسيان دفعةً واحدة).
- المواقع التي تستقبل مدفوعات — فمسار دفع معطّل خسارة إيراد مباشرة.
- تغيير القالب أو تحديث تصميم واسع.
- الحالات التي يلزم فيها تحديث عدة إضافات في آنٍ واحد.
🧪 نسخة اختبار بنقرة واحدة
تستطيع Yedekalma استنساخ موقعك الحيّ إلى نسخة اختبار منفصلة: الملفات إلى دليل مستقل وقاعدة البيانات إلى جداول ببادئة مستقلة. تجرّب التحديث هناك أولًا ثم تنتقل إلى الحيّ. وللتفاصيل راجع صفحة النسخ الاحتياطي لووردبريس .
ما ينبغي الانتباه له عند استخدام بيئة الاختبار
- أغلقها أمام محركات البحث. فإذا فُهرست نسخة الاختبار نشأت مشكلة محتوى مكرّر.
- عطّل المدفوعات والبريد الصادر. كي لا تصل رسالة طلب إلى عميل حقيقي من بيئة الاختبار.
- نسخة الاختبار تتقادم. فالموقع الحيّ يستمر في التغيّر؛ لا تُطِل اختبارك كثيرًا.
- لا تنسخ التغيير إلى الموقع الحيّ. تحقّق في بيئة الاختبار ثم كرّر الخطوات نفسها في الموقع الحيّ. فالكتابة بقاعدة بيانات الاختبار فوق الحيّ تمحو الطلبات البينيّة.
قائمة التحقق بعد التحديث
بعد كل تحديث تحقّق على الأقل مما يلي: هل تُفتح الصفحة الرئيسية وبضع صفحات داخلية، وهل يمكن الدخول إلى لوحة الإدارة، وهل يُرسَل نموذج الاتصال ويخرج البريد، وإن كنت تستقبل مدفوعات هل يمرّ طلب تجريبي، وهل تعطّل العرض على الهاتف.
وتأكّد أيضًا من أن نسختك التالية تشمل هذه الحالة المحدَّثة — كي تستطيع عند مشكلة لاحقة العودة إلى نقطة حديثة.
الأسئلة الشائعة
هل يجب حتمًا أخذ نسخة قبل التحديث؟
نعم، ويُفضَّل نسخة يدوية قبل التحديث مباشرةً. فإذا كانت نسختك المجدولة تعمل ليلًا وأنت تُحدّث صباحًا، بقي كل ما بينهما بلا نسخة. والنسخة اليدوية تسدّ هذه الفجوة وتُنزل خسارتك عند المشكلة إلى دقائق.
ما هي بيئة الاختبار (staging)؟
هي نسخة منفصلة من موقعك الحيّ. تجرّب فيها أولًا التحديث أو تغيير القالب أو إضافة جديدة؛ ولا يراها زوّارك، وحتى لو تعطّل شيء فلن يتأثر موقعك الحيّ. وهي قيّمة خصوصًا في المواقع التي تستقبل مدفوعات وفي القفزات الكبيرة بين الإصدارات.
هل تحديث كل الإضافات دفعةً واحدة أمر محفوف بالمخاطر؟
نعم. فإن حدّثتها كلها معًا وتعطّل شيء صار من الصعب جدًا معرفة أيها السبب. أما التحديث واحدًا تلو الآخر مع فحص الموقع بعد كل خطوة فيمكّنك من التقاط المشكلة فورًا وفي مكانها الصحيح.
كيف أنقل تغييرًا من بيئة الاختبار إلى الموقع الحيّ؟
لا تكتب قاعدة بيانات الاختبار فوق الحيّ؛ فذلك يمحو الطلبات والمحتويات التي وردت أثناء الاختبار. والطريقة الصحيحة هي تكرار الخطوات التي تحقّقت منها في بيئة الاختبار على الموقع الحيّ. فبيئة الاختبار ليست أداة نقل بل بيئة تحقّق.
التحديث عطّل موقعي، ماذا أفعل؟
إن كانت لديك نسخة من قبل التحديث فالعودة إليها أسرع حل؛ وتبقى الخسارة محصورة في المدة المنقضية منذ ذلك الحين. وإن لم تكن لديك نسخة فجرّب أولًا تعطيل الإضافة أو القالب المسبّب؛ ففي معظم الحالات يعود الموقع عند هذه الخطوة.