تحديث ووردبريس: خطة اختبار ورجوع قبل زر التحديث

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

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

حدد ما الذي سيتغير

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

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

النسخة الاحتياطية مش اسم ملف وخلاص

النسخة الكاملة المعتادة تحتاج ملفات الموقع وقاعدة البيانات، حسب دليل النسخ الاحتياطي الرسمي. لكن وجود ملف مكتوب عليه backup مش إثبات إن الاستعادة هتنجح. لازم المسؤول يعرف مكان النسخة، وتاريخها، وصلاحيات الوصول، وإجراء استعادتها واختباره في بيئة آمنة.

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

ابنِ قائمة اختبار من وظائف الموقع

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

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

مثال افتراضي: النموذج ظهر لكنه لا يرسل

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

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

وثّق نهاية التحديث

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

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