الخطر الحقيقي: قاعدتا بيانات تفترقان
يتكوّن موقع ووردبريس من ملفات يمكن نسخها بأمان، ومن قاعدة بيانات تتغير مع كل زيارة: طلب، تسجيل، تعليق، إدخال نموذج، سلة مشتريات. بمجرد تصدير القاعدة تواصل القاعدة القديمة الكتابة وتصبح نسختك قديمة. وما دام DNS يشير إلى الخادم القديم فلا يظهر هذا الفارق. أما يوم التحويل فيتحول إلى خسارة: كل ما وصل بعد التصدير موجود في الخادم القديم وحده.
تختصر الطريقة في جملة واحدة: إعداد النسخة واختبارها مسبقًا، ثم تجميد الكتابة، وإجراء مرحلة أخيرة لنسخ الملفات والقاعدة، وعندها فقط تغيير DNS. أما الترتيب العام لتغيير الاستضافة (TTL والبريد والنطاق) فتتناوله مقالة أخرى؛ وهذه المقالة تعالج ما يخص ووردبريس.
قبل 7 أيام: جرد الموقع
دوّن إصدار PHP، والإضافات التي تكتب (المتجر، النماذج، الحجوزات، الاشتراكات)، والمهام المجدولة، وبوابات الدفع مع عناوين الاستدعاء الخاصة بها.
wp core versionwp plugin list --status=activewp cron event list
ودوّن أيضًا مكان البريد الإلكتروني: فهو لن ينتقل.قبل 3 أيام: خفض TTL
اجعل TTL لسجلات A وAAAA الخاصة بالموقع 300 ثانية، قبل التحويل بمدة لا تقل عن مدة TTL القديمة. لا تلمس سجلات MX ولا TXT.
قبل يومين: أول نسخة كاملة
الملفات:
rsync -az --info=progress2 user@old-server:/path/to/site/ /path/to/site/
قاعدة البيانات:wp db export site.sql --single-transactionعلى الخادم القديم، ثمwp db import site.sqlعلى الجديد. قِس مدة العمليتين: فهذه المدة تحدد حجم نافذة التجميد.قبل يومين: عزل النسخة
في النسخة، أضف
define('DISABLE_WP_CRON', true);إلىwp-config.phpوأوقف رسائل المتجر. فالنسخة تضم عملاء حقيقيين، وإعادة تشغيل حدث مجدول سترسل رسائل مكررة.قبل يوم: الاختبار عبر ملف hosts
تصفّح النسخة بالاسم الحقيقي دون المساس بـ DNS العام (القسم المخصص أدناه). دوّن كل خلل، وأصلحه، وأعد الاختبار.
يوم التحويل، وقت الهدوء: التجميد وأخذ آخر فارق
ضع المصدر في وضع الصيانة بالأمر
wp maintenance-mode activate، وأعد تصدير القاعدة، وزامن الملفات بأمرrsyncنفسه، ثم استورد وأعد الاختبار عبر hosts.يوم التحويل: تغيير DNS وإصدار الشهادة
استبدل سجلات A وAAAA بعناوين الخادم الجديد دون المساس بـ MX. أصدر الشهادة فور أن يشير الاسم إلى الوجهة، ثم أزل
DISABLE_WP_CRON.من يوم التحويل إلى 14 يومًا بعده: التحقق والاحتفاظ ثم الإيقاف
راجع سجلات الخادم القديم وقائمة التحقق أدناه. أبقِ الخادم القديم في وضع الصيانة دون تعديل أسبوعين على الأقل قبل إلغائه.
نسخ الملفات والقاعدة ثم ضبط wp-config.php
انسخ الملفات بالأمر rsync بدل أرشيف يُرفع يدويًا: فهو يحافظ على الصلاحيات ويستأنف بعد الانقطاع ولا يعيد نقل إلا ما تغيّر، مما يجعل المرحلة الأخيرة قصيرة جدًا. وللقاعدة، فضّل wp db export أو mysqldump --single-transaction اللذين ينتجان تصديرًا متسقًا دون قفل جداول InnoDB.
على الخادم الجديد يكون wp-config.php أول ملف تعيد قراءته. يجب أن تطابق DB_NAME وDB_USER وDB_PASSWORD القاعدة المُنشأة في الوجهة. وغالبًا تكون DB_HOST هي localhost، لكن بعض الاستضافات تفرض مضيفًا مستقلًا أو منفذًا (host:3307) أو مقبسًا. تحقق كذلك من $table_prefix الذي يجب أن يطابق بادئة الجداول المستوردة، وإلا ظن ووردبريس أن التثبيت فارغ. وأخيرًا، إن كانت WP_HOME وWP_SITEURL معرّفتين في الملف فإنهما تتقدمان على القاعدة: قيمة قديمة منسية هنا تعيد كل زائر إلى العنوان القديم.
استبدال الروابط في القاعدة دون إتلاف البيانات المُسلسَلة
يخزّن ووردبريس عناوين مطلقة في المقالات والخيارات والقوائم وإعدادات القوالب والإضافات، وغالبًا داخل قيم مُسلسَلة يُكتب طولها في البيانات نفسها. والأمر sed على ملف التصدير يغيّر طول السلسلة دون تصحيح هذا العداد، فتصبح القيمة غير مقروءة: ودجات فارغة وقالب أُعيد ضبطه. أما wp search-replace فيقرأ هذه البنى ويعيد كتابتها بشكل صحيح.
لا يلزم الاستبدال إلا إذا تغيّر العنوان: اسم نطاق جديد، أو الانتقال من http إلى https، أو نسخة أُعدّت على عنوان مؤقت. وإن اختبرت عبر ملف hosts بالاسم الحقيقي فلا شيء يُستبدل. ابدأ دائمًا بالأمر wp search-replace 'http://old.your-domain.com' 'https://your-domain.com' --all-tables --skip-columns=guid --dry-run الذي يحصي الاستبدالات دون كتابة شيء. فإذا فاجأك الرقم فتوقف. ثم أعد التشغيل دون --dry-run على النسخة لا على المصدر أبدًا، وبعده wp cache flush. ويترك الخيار --skip-columns=guid معرّفات المقالات كما هي، وهي ما تستخدمه قارئات RSS للتعرف على محتوى سبق أن قرأته.
اختبار النسخة قبل DNS عبر ملف hosts
يخبر ملف hosts في حاسوبك جهازك وحده إلى أين يوجّه اسم النطاق، دون المساس بـ DNS العام. أضف سطرًا 203.0.113.10 your-domain.com www.your-domain.com (عنوان الخادم الجديد) في /etc/hosts، أو في C:\Windows\System32\drivers\etc\hosts على ويندوز. ولطلب واحد، يؤدي الأمر curl --resolve your-domain.com:443:203.0.113.10 -I https://your-domain.com/ الغرض نفسه دون تعديل الجهاز. أفرغ ذاكرة المتصفح المؤقتة لأنها تحتفظ بالتحليل السابق.
اختبر مسارات كاملة لا الصفحة الرئيسية: الدخول إلى لوحة الإدارة، وصفحة عميقة (تكشف الروابط الدائمة)، ورفع ملف وسائط، والبحث، وفي المتجر سلة تصل إلى صفحة الدفع. قد لا تكون شهادة النسخة صادرة بعد (انظر أدناه): فالتحذير متوقع حينها، أما الصفحة البيضاء أو خطأ PHP فغير متوقعين. ثم أزل سطر hosts: فالسطر المنسي يوهمك أسابيع بأن التحويل لم يحدث.
تجميد الكتابة للمواقع التي فيها طلبات ونماذج
يمكن لموقع تعريفي أن يتحول دون تجميد أي شيء: فأقصى خسارة تعليق. أما حين يستقبل الموقع مدفوعات أو طلبات فلا بد من نافذة بلا كتابة. والتسلسل: الإعلان عن صيانة قصيرة، ووضع المصدر في الصيانة، وإعادة تصدير القاعدة، ومزامنة الملفات (يكتفي rsync الآن بنقل الفارق، وغالبًا الوسائط المضافة فقط)، والاستيراد في الوجهة، وإعادة search-replace إن وُجد، والاختبار عبر hosts، ثم تغيير DNS. ويبقى الخادم القديم في الصيانة حتى النهاية.
تستغرق هذه النافذة بضع دقائق لقاعدة بحجم معتاد، وهي مدة يجب قياسها أثناء النسخة الأولى. وتمثل بوابات الدفع حالة خاصة: فهي ترسل إشعاراتها إلى العنوان المضبوط وتعيد الفاشل منها وفق سياستها الخاصة، وهو ما يجب التأكد منه في وثائقها. تحقق في لوحتها من أن الاستدعاءات المرفوضة أثناء الصيانة تُعاد بعد أن يصبح الموقع الجديد متاحًا.
ما الذي يكتب أثناء النافذة وكيف توقفه
- طلبات WooCommerce — يمنعها وضع الصيانة في المصدر؛ والعميل الذي فتح سلته مسبقًا يجد الموقع غير متاح، ومن هنا ضرورة الإعلان المسبق.
- نماذج الاتصال وطلب عرض السعر — بحسب الإضافة قد تُخزَّن الإدخالات في القاعدة أو في ملف أو تُرسل بالبريد فقط؛ حدد أين يكتب كل نموذج، لأن إدخالًا يُخزَّن في الخادم القديم بعد التصدير يضيع.
- التعليقات والتسجيلات — أغلقها من إعدادات النقاش والتسجيل طوال النافذة إن تعذّر وضع الصيانة.
- المهام المجدولة — يسردها
wp cron event list؛ ولا يجوز أن تنفذ النسخة المهام نفسها التي ينفذها المصدر قبل التحويل، وإلا خرجت التذكيرات ورسائل التجديد مرتين. - الويب هوك الواردة — بوابات الدفع وأنظمة CRM وأدوات الشحن: عنوانها يشير إلى اسم نطاق، أي إلى الخادم الجديد بعد التحويل؛ تحقق من نسخ مفاتيح التوقيع السرية مع الإعدادات.
- زوار ما زالوا يصلون إلى المصدر — يرسلهم إليه محلّل ذو ذاكرة مؤقتة طويلة بعد التحويل؛ ويمكن للخادم القديم تمريرهم إلى الجديد مع الإبقاء على ترويسة
Host، وهو إجراء لمن يتقن الوكيل العكسي.
أعراض ما بعد التحويل وأسبابها
مرّر الجدول أفقيًا
| العرَض | السبب المحتمل | الحل |
|---|---|---|
| حلقة إعادة توجيه (`ERR_TOO_MANY_REDIRECTS`) | يفرض ووردبريس `https` لكنه لا يرى سوى `http`: وكيل أو CDN أو موزّع أحمال ينهي TLS، أو وضع SSL في CDN هو Flexible | وضع Full (strict) في CDN، أو قراءة `X-Forwarded-Proto` في `wp-config.php` لضبط `$_SERVER['HTTPS']` |
| Error establishing a database connection | خطأ في `DB_HOST` أو بيانات الدخول أو صلاحيات المستخدم؛ أو خادم MySQL متوقف | `wp db check`، ثم اختبار يدوي بالأمر `mysql -h host -u user -p`؛ ومنح الصلاحيات على القاعدة |
| تثبيت فارغ أو شاشة التثبيت | `$table_prefix` يختلف عن البادئة الفعلية للجداول | مطابقة البادئة مع ناتج `SHOW TABLES` |
| محتوى مختلط: قفل مشطوب وصور محظورة | عناوين `http://` بقيت في المقالات أو الخيارات | `wp search-replace` من `http://` إلى `https://` بعد `--dry-run` |
| المقالات تعطي 404 والرئيسية سليمة | غياب قواعد إعادة الكتابة: `.htaccess` لم يُنسخ أو لا يُقرأ، أو nginx بلا `try_files` | `wp rewrite flush --hard`؛ وفي nginx: `try_files $uri $uri/ /index.php?$args;` |
| القوائم أو الودجات أو القالب أُعيد ضبطها | قيم مُسلسَلة أتلفها استبدال أعمى | إعادة استيراد التصدير ثم تكرار الاستبدال بالأمر `wp search-replace` |
| عناوين قديمة ما زالت في الصفحات | `WP_HOME` أو `WP_SITEURL` ثابتتان، أو ذاكرة الصفحات المؤقتة لم تُفرَّغ | تصحيح الثوابت، و`wp cache flush`، وتفريغ ذاكرة الصفحات |
البريد والشهادة: موضوعان لا يتبعان الموقع
استضافة الويب والبريد الإلكتروني خدمتان منفصلتان تعتمدان على سجلات DNS مختلفة: MX للاستقبال وTXT (SPF وDKIM وDMARC) للإرسال. ويجب ألا يغيّر نقل الويب سجلات MX ولا صناديق البريد. تحقق من ذلك قبل النقل وبعده بالأمرين dig MX your-domain.com +short وdig TXT your-domain.com +short: يجب أن يتطابق الناتجان. والفخ في الإرسال: إذا كان SPF يذكر عنوان الخادم القديم (ip4:) وأصبح ووردبريس يرسل رسائله من الجديد، فإن إشعارات الطلبات تصل إلى البريد المزعج. أضف العنوان الجديد إلى SPF، أو الأفضل أن تمرّر ووردبريس عبر SMTP موثَّق.
تتبع الشهادة العنوان. ففي التحقق عبر HTTP (certbot --nginx أو AutoSSL في cPanel) يجب أن تصل سلطة الشهادات إلى الخادم الجديد بالاسم الحقيقي، وهذا غير ممكن إلا بعد التحويل: أصدرها فورًا وتوقّع تحذيرًا قبل ذلك، بما في ذلك أثناء اختباراتك عبر hosts. وإن كان هذا التأخير غير مقبول فإن التحقق عبر DNS يتيح إصدار الشهادة قبل التحويل، مقابل صلاحية وصول API إلى المنطقة. ثم تحقق من تاريخ الانتهاء بالأمر curl -vI https://your-domain.com/ 2>&1 | grep -i expire.
ما يجب التحقق منه قبل إيقاف الخادم القديم
- الحركة انتقلت فعلًا — تابع سجلات الدخول في الخادم القديم بالأمر
tail -f: يجب ألا يظهر فيها سوى الروبوتات والمحللات ذات الذاكرة المؤقتة الطويلة، ثم لا أحد. - الكتابة تصل إلى المكان الصحيح — أجرِ طلبًا مع بوابة الدفع في وضع الاختبار، وأرسل نموذجًا، وابحث عن الاثنين في القاعدة وفي البريد.
- الأحجام متقاربة — قارن عدد الصفوف في الجداول الرئيسية (
wp db query "SELECT COUNT(*) FROM wp_posts"مع تعديل البادئة) وحجمwp-content/uploadsمع المصدر. - المهام المجدولة تعمل — يجب أن ينفَّذ
wp cron event run --due-nowدون أخطاء؛ واربط cron حقيقيًا للنظام إذا كانت الزيارات قليلة. - البريد سليم — MX وSPF وDKIM دون تغيير، ورسالة اختبار وصلت إلى صندوق حقيقي.
- توجد نسخة احتياطية أخيرة — تصدير القاعدة ونسخة من ملفات الخادم القديم، محفوظان خارج ذلك الخادم، قبل أي إيقاف.
حدّد التراجع قبل التحويل
التراجع بسيط ما دام الخادم القديم سليمًا: تعيد العنوان القديم في سجلات A وAAAA، مستفيدًا من TTL المنخفض المضبوط سلفًا. ويتوقف عن كونه بسيطًا حين تتلقى القاعدة الجديدة طلبات، لأن العودة إلى الوراء تمحوها. فحدّد القاعدة قبل يوم التحويل: التراجع ممكن دون شرط حتى أول كتابة حقيقية على الموقع الجديد، وبعدها يكون التصحيح إلى الأمام. أبقِ الخادم القديم سليمًا ومدفوعًا أسبوعين على الأقل: فهذا ثمن إمكانية العودة.
في محفظة العملاء تصبح الطريقة روتينًا
اكتب هذا التسلسل مرة واحدة مع المدد المقيسة، وأعد استخدامه من عميل إلى آخر: ورقة الجرد، ونافذة التجميد، وقائمة التحقق. لا يحتاج العميل إلى فهم DNS؛ يحتاج أن يعرف متى ستكون الصيانة ومن يؤكد أن كل شيء يعمل. في ServOrbit تجمع استضافة الموزّعين حسابات عملائك، والنقل المساعَد خيار للمواقع التي تفضّل ألا تنقلها بنفسك. وتتابَع النطاقات والاستضافات وتواريخ التجديد من فضاء واحد، تحت علامتك.
