الترحيل الفاشل لـ PrestaShop يظهر فورًا: سلة لم تعد تظهر، دفع يعرض خطأ، لوحة تحكم يتعذّر الوصول إليها. أما الترحيل الناجح فلا يلاحظه أحد. إليك المنهجية التي نطبّقها للانتقال بمتجر من الإصدار 1.7 إلى PrestaShop 8 أو 9.
1. الجرد قبل لمس أي شيء
أعدّ قائمة بكل وحدة مثبّتة، وناشرها، وإصدارها، وتوافقها المعلن مع الإصدار المستهدف. حدّد الوحدات المهجورة: فهي التي تعيق معظم عمليات الترحيل. وأعدّ أيضًا قائمة بالـ overrides الموجودة في المجلد override/: فكل واحد منها نقطة انكسار محتملة.
2. التحقق من إصدار PHP
لا يقبل PrestaShop 8 وPrestaShop 9 إصدارات PHP نفسها التي يقبلها الإصدار 1.7. تحقّق من توافق الإصدار المستهدف في الوثائق الرسمية، ثم تأكّد من أن استضافتك توفّره. والتطويرات الخاصة المكتوبة لـ PHP 7 هي غالبًا التي تتطلب أكبر قدر من التصحيحات.
3. العمل على نسخة، وليس على الموقع الفعلي أبدًا
انسخ المتجر (الملفات وقاعدة البيانات) إلى بيئة ما قبل إنتاج محمية. وعطّل الرسائل الإلكترونية الصادرة والمهام المجدولة التي قد تتواصل مع عملائك أو مع شركات التوصيل.
4. معالجة القالب والوحدات
- حدّث الوحدات غير المتوافقة أو استبدلها؛ وأعد كتابة التطويرات الخاصة بالاعتماد على الخطافات (hooks) بدلًا من الـ overrides.
- افحص القالب: القالب الفرعي المبني على Classic يُرحَّل بسهولة، أما القالب المعدَّل بشكل كبير فقد يتطلب إعادة تصميم جزئية.
- تحقّق من صفحات الإدارة الخاصة بالوحدات المطوّرة داخليًا، والتي نُقلت تدريجيًا إلى Symfony في الإصدارات الحديثة.
5. اختبار ما يدرّ الأرباح
أتمت المسارات الحساسة: إنشاء حساب، الإضافة إلى السلة، تطبيق رمز تخفيض، اختيار شركة التوصيل، الدفع في وضع الاختبار، واستلام رسالة التأكيد. والاختبارات الشاملة (end-to-end)، باستخدام Playwright مثلًا، يُعاد تشغيلها في بضع دقائق بعد كل تصحيح.
6. التحضير للانتقال
خطّط للإطلاق في وقت تكون فيه حركة الزيارات منخفضة، وجمّد تعديلات الكتالوج أثناء العملية، واحتفظ بنسخة احتياطية قابلة للاسترجاع وبخطة تراجع مكتوبة. ثم راقب سجلات الأخطاء والطلبيات طوال 48 ساعة.
هل تحضّر لعملية ترحيل؟ يتيح التدقيق التقني تقدير تكلفة العمل بدقة قبل أن تلتزم.