النسخ نادراً ما يكون ما يكسر نقل WordPress. ما يكسره هو ما لم يكتبه أحد: cron، وwebhook، وإضافة خبزت اسم المضيف القديم في صف، وصندوق ما زال يخرج من الخادم القديم. أتعامل مع الجرد بوصفه الترحيل. نقل الملفات هو العصر السهل الذي يأتي بعده.
اكتب النظام قبل أن تلمسه
قبل أن يتحرك ملف أكتب صفحة يستطيع غريب استخدامها. إصدار PHP. حجم قاعدة البيانات. أسطر cron والإجراءات المجدولة داخل WordPress، وليست القائمة نفسها. البريد: من يرسل، وعبر ماذا، وهل يسمي SPF ذلك المستضيف أصلاً. كل تكامل ينادي الموقع أو يناديه الموقع. webhook الدفع ومزامنة CRM هي المفاجآت المعتادة، لأنها تعيش في إعداد إضافة لم يصدّره أحد.
أكتب أيضاً ماذا تعني «تعمل» لهذا المتجر بعينه. دفع منتج مادي واحد. دفع منتج افتراضي واحد. تسجيل الدخول. إعادة تعيين كلمة المرور. نموذج التواصل، بما فيه البريد الذي ينبغي أن يصل. البحث، إن كان الكتالوج يعتمد عليه. إن لم أستطع تسمية المسار فلست مستعداً لتغيير DNS.
| سطر | لماذا هو هنا |
|---|---|
| PHP وحجم القاعدة وذاكرة الكائنات | المضيف الجديد قد يكون «قائمًا» ويظل بيئة التشغيل الخطأ. |
| Cron والإجراءات المجدولة | مهمة ليلية فائتة تبدو سليمة حتى يصير تقرير الصباح فارغًا. |
| مسار البريد | قد يُحمَّل الموقع بينما يموت كل بريد طلب على الجهاز الجديد. |
| Webhooks وواجهات خارجة | عادة غير موثّقة، وتلاحظ اسم المضيف أولًا. |
| المسارات الخمسة التي تجني المال | فحص الصفحة الرئيسية لا يسلكها. |
اخفض TTL في اليوم السابق
اضبطوا TTL لـ DNS على 300 ثانية قبل التبديل بيوم. إن تجاوزتم ذلك وكان المستضيف الجديد خاطئاً، يحتفظ جزء من الجمهور بالسجل القديم لساعات. لا يمكنكم استعجال ذاكرة مؤقتة لم تقصروها. أفضّل الانتظار يوماً عن قصد على اكتشاف الانتظار أثناء انقطاع.
رابط التجريب ليس اسم المضيف الحقيقي
أرفع الخادم الجديد وأوجّه إليه آلتي فقط، باستثناء في ملف hosts، بينما DNS العام ما زال يخدم المستضيف القديم. ثم أسير المسارات على الاسم الحقيقي. عنوان staging يخفي الإضافات التي خزنت نطاق الإنتاج في قاعدة البيانات. تتصرف إلى أن يكون الاسم الحقيقي في الطلب، وهو بالضبط اللحظة التي لم تعودوا تريدون فيها مفاجأة.
إن لم يُسلك المسار الحرج على اسم المضيف الحقيقي، فالترحيل لم يُختبر.
أبقِ المضيف القديم دافئًا
لا ألغي الاستضافة القديمة في أسبوع النقل. تبقى قائمة، للقراءة فقط، أسبوعين على الأقل. تكلفتها قليلة. هي الرجوع الوحيد الذي لا يعتمد على نسخة لم أضطر إلى استخدامها بعد. إن أساء المستضيف الجديد التصرف في اليوم الثالث، فالسجل القديم ما زال يعني شيئاً.
البريد هو الفحص الذي يُنسى
قد يبدو الموقع منتهياً بينما يموت كل بريد طلب على الآلة الجديدة. أكتب عنوان From، والـ relay، وهل المنفذ 25 مفتوح أصلاً. على أكثر من مستضيف ليس مفتوحاً، والطريق الوحيد الذي يعمل هو relay مصدَّق على 587. لدى SPF سجل واحد أصلاً. لا أضيف ثانياً. سجلّا SPF لا يندمجان. يصير كلاهما غير صالح، والبريد الذي كان يصل يبدأ بالاختفاء في الأسبوع الذي يلي نقلاً سار فيما عدا ذلك على ما يرام.
أرسل بريداً حقيقياً عن طلب وإعادة تعيين كلمة مرور من المستضيف الجديد إلى صندوق أتحكم فيه، قبل أن أسمي النقل منتهياً. سطر سجل يقول “sent” ليس رسالة في الصندوق. الثاني هو الاختبار.
HTTPS على الـ apex وعلى www. الشهادة تتجدد وحدها. البريد ما زال يخرج. المسارات الخمسة ما زالت تكتمل. ثم أراقب سجل الأخطاء يوماً، لا الصفحة الرئيسية. الصفحة الرئيسية هي ما يهنئكم به المراقب أصلاً. السجل هو حيث بدأ webhook يرد بـ 404 على مزود دفع.
النقل بهذه الطريقة ممل. هذا هو المقصود. القصص الشيّقة عن الترحيل تكاد كلها تكون عن سطر كان ناقصاً من الجرد.
