محتويات الدليل
القاعدة الذهبية
طريقة التحديث حسب كيف حصلت على الملفات
إذا كان المشروع مرتبطاً بـ Git
cd /var/www/html/WorkUp
git status # تأكد أنه لا توجد تعديلات محلية غير محفوظة
git pull origin main
git pull يسحب كل التعديلات الجديدة تلقائياً ويدمجها بالملفات الموجودة. إن ظهرت رسالة "conflict" (تعارض)، توقف واطلب مساعدة قبل المتابعة — هذا يعني أن نفس الملف تم تعديله محلياً وبالتحديث الجديد معاً.
إذا كنت ترفع الملفات يدوياً (بدون Git)
لا تستبدل المجلد بأكمله دفعة واحدة! بعض الملفات يجب ألا تُلمَس أبداً لأنها تحتوي إعداداتك الخاصة:
includes/config.php (بيانات قاعدة بياناتك) و.htaccess (مسار include_path الخاص بسيرفرك). كذلك لا تلمس مجلد files/ (صور ومرفقات حقيقية للموظفين).
ارفع فقط الملفات/المجلدات الفعلية المتغيّرة بالتحديث (يخبرك بها من أرسل لك التحديث عادة)، عبر FileZilla أو scp، مع استثناء الملفات أعلاه صراحة.
هل يحتاج التحديث تعديل قاعدة البيانات؟
ensureSchema) — لا تحتاج أنت لتنفيذ أي أمر SQL يدوياً في أغلب الحالات. لكن إن أُرفق مع التحديث ملف باسم مشابه لـ update.sql أو تعليمات صريحة بـ"شغّل هذا الاستعلام"، نفّذه هكذا:
تنفيذ ملف تحديث قاعدة بيانات (فقط إن طُلب منك ذلك صراحة)
mysql -u workup_user -p workup < update.sql
لا تُنفّذ هذا الأمر "تحسباً" بدون سبب — فقط عندما تعرف تحديداً أن هناك ملف تحديث لقاعدة البيانات مرفق مع النسخة الجديدة من الكود.
اختبار سريع بعد كل تحديث
قبل أن تُعلن "خلاص انتهينا"، جرّب هذا
sudo tail -f /var/log/apache2/error.logapi/).خطة التراجع (Rollback)
التراجع حسب الطريقة المستخدمة
مع Git: ارجع لآخر نقطة كانت تعمل (commit سابق):
git log --oneline -5 # شاهد آخر 5 تحديثات ومعرّف كل واحد
git reset --hard رقم_الكوميت_السابق
مع الرفع اليدوي: إن كنت أخذت نسخة من الملفات القديمة قبل الاستبدال (يُفضّل دائماً أخذ نسخة قبل أي تحديث يدوي)، أعد رفعها كما كانت.
في الحالتين: إن كان التحديث قد لمس قاعدة البيانات، استعد نسخة قاعدة البيانات الاحتياطية التي أخذتها قبل التحديث (راجع دليل الاستعادة).