نقل موقع WordPress إلى خادم أو نطاق جديد باستخدام WP-CLI وrsync وsearch-replace

نقل موقع WordPress يتلخص في ثلاثة أمور: الملفات (وأهمها wp-content)، وقاعدة البيانات، وكل مكان خُزّن فيه العنوان القديم. وأداة WP-CLI، وهي أداة سطر الأوامر الرسمية لـ WordPress، تتعامل مع أجزاء قاعدة البيانات بموثوقية، بما في ذلك البيانات المسلسلة (serialized) التي يفسدها البحث والاستبدال الساذج. يشرح هذا الدليل نقل موقع بين خادمي لينكس، مع تغيير النطاق اختيارياً، واختبار قبل تبديل DNS، ومزامنة نهائية قصيرة.

قبل البدء

• WP-CLI على الخادمين: يثبّته دليل WP-CLI كملف PHAR واحد، ويشرح أيضاً كيفية التحقق منه مقابل توقيع GPG المنشور:

  curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
  php wp-cli.phar --info
  chmod +x wp-cli.phar
  sudo mv wp-cli.phar /usr/local/bin/wp

• برمجيات متوافقة: شغّل wp core version وphp -v على الخادم القديم، وتأكد من أن الجديد يعمل بإصدار PHP مماثل أو أحدث ومدعوم، وبقاعدة بيانات يدعمها WordPress (يوصي WordPress بـ MariaDB 10.11 أو أحدث، أو MySQL 8.0 أو أحدث).
• تقليل مدة TTL في DNS: قد تحتفظ خوادم الحل بسجل DNS طوال مدة TTL الخاصة به. لذا خفّض TTL لسجلات A وAAAA الخاصة بالموقع قبل النقل بيوم أو أكثر (إلى 300 ثانية مثلاً)، وانتظر مدة لا تقل عن قيمة TTL القديمة قبل التبديل.
• نسخة احتياطية كاملة للموقع القديم يمكنك استعادتها دون الحاجة إلى الخادم الجديد.

شغّل أوامر WP-CLI بالمستخدم المالك لملفات الموقع، ومن داخل مجلد WordPress.

1. انسخ الملفات

على الخادم الجديد اسحب الموقع عبر rsync فوق SSH، وابدأ بتشغيل تجريبي. والشرطة المائلة في نهاية مسار المصدر تنسخ محتويات المجلد لا المجلد نفسه:

rsync -az --dry-run --exclude=.maintenance \
  deploy@old-server:/var/www/example/ /var/www/example/
rsync -az --exclude=.maintenance \
  deploy@old-server:/var/www/example/ /var/www/example/

الخيار -a (وضع الأرشفة) يحافظ على الصلاحيات والطوابع الزمنية. وتجنّب --delete في النسخة الأولى كي لا يحذف مسار خاطئ أي شيء في الوجهة.

2. وجّه wp-config.php إلى قاعدة البيانات الجديدة

أنشئ قاعدة بيانات فارغة ومستخدماً على الخادم الجديد، ثم حدّث ملف wp-config.php المنسوخ عبر WP-CLI بدلاً من التحرير اليدوي:

wp config set DB_NAME example_db
wp config set DB_USER example_user
wp config set DB_PASSWORD 'a-long-random-password'
wp config set DB_HOST localhost

3. انقل قاعدة البيانات

صدّر على الخادم القديم، واستورد على الجديد:

# old server
wp db export /tmp/example.sql --add-drop-table

# new server, after copying the file across
wp db import /tmp/example.sql
wp option get home
wp option get siteurl

احذف ملفات SQL حين تنتهي، فهي تحتوي بصمات كلمات مرور كل المستخدمين وكل محتوى الموقع.

4. غيّر العنوان، فقط إن تغيّر النطاق

إن بقي الموقع على النطاق نفسه فتجاوز هذه الخطوة. أما إن انتقل إلى نطاق جديد أو من HTTP إلى HTTPS، فاستبدل العنوان القديم في كل قاعدة البيانات. ويحذّر دليل نقل WordPress من أن البحث والاستبدال العادي قد يفسد البيانات المسلسلة، لأن بعض القوالب والودجات تخزّن القيم مع أطوالها، والأمر search-replace في WP-CLI يتعامل مع البيانات المسلسلة، وهو من الأدوات التي يوصي بها الدليل:

wp search-replace 'https://old.example.com' 'https://example.com' --skip-columns=guid --dry-run
wp search-replace 'https://old.example.com' 'https://example.com' --skip-columns=guid

• --dry-run يعرض عدد الاستبدالات المتوقعة في كل جدول دون تغيير شيء، فاقرأ نتيجته قبل تشغيل الأمر الفعلي.
• --skip-columns=guid يترك عمود guid في المقالات دون مساس، وتوثيق WordPress حازم في أن هذه المعرّفات يجب ألا تتغير أبداً، لأن قارئات الخلاصات تستخدمها لتمييز العناصر التي عرضتها سابقاً.
• افتراضياً لا يلمس الأمر إلا الجداول المسجلة في WordPress، والإضافات التي تحتفظ بجداول خاصة بالبادئة نفسها قد تحتاج إلى --all-tables-with-prefix.
• --precise يفرض المعالجة عبر PHP لكل عمود، فاستخدمه إن شككت في بيانات مسلسلة معقدة قد يفوتها الوضع الافتراضي، مع أنه أبطأ.

ثم امسح المخازن المؤقتة وأعد توليد قواعد إعادة الكتابة:

wp cache flush
wp rewrite flush

5. اختبر قبل أن يراه أحد

وجّه جهازك أنت إلى الخادم الجديد بإضافة سطر إلى ملف hosts فيه (/etc/hosts في لينكس وmacOS، وC:\Windows\System32\drivers\etc\hosts في ويندوز):

203.0.113.10  example.com www.example.com

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

6. المزامنة النهائية والتبديل

كل ما أُنشئ على الموقع القديم منذ النسخة الأولى، كالطلبات والتعليقات والملفات المرفوعة، يجب أن يُنقل في النهاية، فاجعل هذه النافذة قصيرة:

# old server: stop changes
wp maintenance-mode activate
wp db export /tmp/example-final.sql --add-drop-table

# new server: fetch the final copy
rsync -az --exclude=.maintenance deploy@old-server:/var/www/example/wp-content/uploads/ /var/www/example/wp-content/uploads/
wp db import /tmp/example-final.sql
# repeat the search-replace from step 4 if the domain changed
wp cache flush

الآن غيّر سجلات DNS لتشير إلى الخادم الجديد، ومع مدة TTL القصيرة يصل أغلب الزوار خلال دقائق. وأصدر شهادة TLS على الخادم الجديد فور توجيه DNS إليه؛ فتحدي HTTP-01 لدى Let's Encrypt يجلب ملفاً من http://<your domain>/.well-known/acme-challenge/، فلا ينجح إلا حين يشير النطاق إلى الخادم الجديد (أما تحدي DNS-01 فيعمل قبل ذلك إن كان مزوّد DNS لديك يدعمه). وإن كانت الوجهة خطة استضافة مُدارة فتحقق مما تقدمه لك؛ ففي خطط الاستضافة لدى Skyline مثلاً تُصدر شهادات SSL المجانية وتُجدَّد تلقائياً، وتُنسخ المواقع وقواعد البيانات احتياطياً كل ليلة.

بعد النقل

• اترك الخادم القديم في وضع الصيانة دون تغيير لمدة أسبوع، وراقب سجل الوصول فيه لرصد الزوار المتأخرين بسبب DNS المخزّن.
• تحقق من المهام المجدولة: إن كان WP-Cron قد استُبدل بمهمة cron على الخادم القديم، فأعد إنشاءها على الجديد.
• أعد مدة TTL في DNS إلى قيمتها المعتادة.
• خذ نسخة احتياطية جديدة على الخادم الجديد وتأكد من أن استعادتها تعمل.

ما الذي ينبغي فعله

1. خفّض مدة TTL مسبقاً، وخذ نسخة احتياطية كاملة من الموقع القديم.
2. انسخ الملفات عبر rsync (بتشغيل تجريبي أولاً)، وقاعدة البيانات عبر wp db export وwp db import.
3. لا تغيّر العناوين إلا عبر wp search-replace، ودائماً بعد --dry-run، ودائماً مع --skip-columns=guid.
4. اختبر عبر ملف hosts قبل تبديل DNS.
5. جمّد الموقع القديم بوضع الصيانة لمزامنة نهائية قصيرة، ثم بدّل DNS وأصدر الشهادة.
6. احتفظ بالخادم القديم أسبوعاً قبل حذفه.

المصادر

• make.wordpress.org/cli/handbook/guides/installing
• developer.wordpress.org/cli/commands/db/export
• developer.wordpress.org/cli/commands/db/import
• developer.wordpress.org/cli/commands/search-replace
• developer.wordpress.org/cli/commands/config/set
• developer.wordpress.org/cli/commands/maintenance-mode/activate
• developer.wordpress.org/cli/commands/cache/flush
• developer.wordpress.org/cli/commands/rewrite/flush
• developer.wordpress.org/advanced-administration/upgrade/migrating
• wordpress.org/about/requirements
• manpages.debian.org/trixie/rsync/rsync.1.en.html
• datatracker.ietf.org/doc/html/rfc1035
• letsencrypt.org/docs/challenge-types
• cloud.alskyline.com/hosting