صور ووردبريس ظلت على الدومين القديم بعد النقل؟ تجربة استبدال آمن

نقلت موقع ووردبريس لدومين جديد، وعدلت عنوان الموقع، لكن بعض الصور لسه مكسورة او بتنسحب من الدومين القديم؟ تغيير home وsiteurl ما بيمر على كل مقال وكل إعداد داخل الإضافات. روابط كاملة ممكن تظل مخزنة في محتوى المقالات، بيانات الصور المتجاوبة، الودجات، خيارات القالب، او بيانات منشئ الصفحات.

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

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

اول تشخيص: الرابط غلط ولا الملف مفقود؟

قبل ما تشغل اي استبدال، افتح صفحة فيها صورة مكسورة واضغط على رابط الصورة او افحص عنصر img من ادوات المتصفح. قارن ثلاث شغلات:

1. هل اسم الدومين في src قديم؟
2. هل المسار بعد الدومين موجود فعليا داخل wp-content/uploads؟
3. شو رمز الاستجابة لما تفتح رابط الصورة مباشرة: 200، 403، 404، او فشل اتصال؟

اذا الرابط ما زال على الدومين القديم والملف موجود على الجديد، عندك مشكلة مراجع داخل قاعدة البيانات. اذا الرابط جديد لكنه يعيد 404، الاستبدال وحده مش الحل؛ ممكن الملفات ما انتقلت او اسم المجلد والتاريخ مختلف. واذا 403، افحص الصلاحيات، الحماية، او إعداد CDN.

كيف جهزنا تجربة قابلة للقياس؟

استخدمنا عنوانا قديما محليا هو http://old.localhost:8899. هذا العنوان يرجع لنفس الجهاز، لكن ما في خادم يعمل على المنفذ 8899. العنوان الجديد كان https://semsemm.com وعليه نسخة ووردبريس وملف الصورة.

صفحة الاختبار احتوت ثلاث مرات على العنوان القديم: رابط الصورة، النص الظاهر للرابط، ورابط داخلي. خيار ووردبريس المتسلسل احتوى ثلاث مرات ثانية: رابط الصورة ورابط دليل ورابط الرئيسية. صار المجموع 6 مراجع قديمة. فتح رابط الصورة القديم انتهى من غير استجابة HTTP، بينما الملف نفسه على العنوان الجديد رجع برمز 200 وحجم 49,728 بايت.

ليش الاستبدال النصي الاعمى ممكن يكسر الإعدادات؟

ووردبريس وإضافاته يخزنوا مصفوفات وكائنات بصيغة PHP serialized. هاي الصيغة تكتب طول كل نص داخل القيمة. مثال مبسط:

a:1:{s:3:"url";s:24:"http://old.example/image";}

طول الرابط في هذا المثال هو 24 بايت، لذلك نكتب s:24. العدد في الصيغة المتسلسلة يمثل البايتات، وليس عدد الحروف الظاهرة بالضرورة؛ النص العربي بترميز UTF-8 قد يستخدم عدة بايتات للحرف الواحد.

اذا استبدلت الدومين بنص اقصر او اطول داخل السطر الخام وتركت رقم الطول القديم، unserialize() ممكن يفشل. في تجربتنا كان طول الخيار المتسلسل 300 بايت. الاستبدال الاعمى على النص الخام انزله إلى 288 بايت، لكنه ترك ارقام الاطوال القديمة، وفشل فك القيمة فعليا. ما كتبنا الناتج الفاسد لقاعدة البيانات؛ استخدمناه فقط كاختبار في الذاكرة.

فيديو توثيق التجربة الفعلية

هذا تسجيل شاشة صامت ومتواصل للاختبار وهو يحدث داخل بيئة محلية معزولة. تظهر الخطوات والنتائج الفعلية لحظة التنفيذ، من غير تركيب صور ثابتة.

الطريقة الآمنة اللي نفذناها

حصرنا التغيير في صفحة المختبر وخيار المختبر فقط. محتوى الصفحة HTML عادي، فبدلنا العنوان القديم بالجديد داخله. اما الخيار المتسلسل، قرأناه عبر ووردبريس كمصفوفة، مررنا على القيم النصية داخلها، وبعد التبديل ارسلنا المصفوفة إلى update_option(). ووردبريس اعاد تسلسلها وحسب الاطوال الجديدة.

بعد التنفيذ، صارت المراجع القديمة صفرا والجديدة 6. رابط الصورة الجديد رجع 200، وظهرت الصورة في صفحة الاختبار. القيمة المتسلسلة صارت 288 بايت وفكها نجح، وهذا هو الفرق بين تغيير القيم داخل البنية وتغيير النص الخام من غير فهمه.

الطريقة العملية على موقع حقيقي باستخدام WP-CLI

في المختبر استخدمنا دالة PHP محصورة ببيانات التجربة، وما استخدمنا WP-CLI لان تنزيل الاداة تعطل محليا بسبب طبقة شهادات ويندوز. على استضافة توفر WP-CLI، الامر الرسمي افضل لاستبدال شامل لانه يتعامل بذكاء مع البيانات المتسلسلة. ابدأ دائما بتشغيل تجريبي:

wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --skip-columns=guid --dry-run

راجع عدد التغييرات والجداول. اذا الارقام منطقية وعندك نسخة احتياطية، شغل نفس الامر بعد حذف --dry-run:

wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --skip-columns=guid

توثيق أمر wp search-replace الرسمي يذكر انه يتعامل مع بيانات PHP المتسلسلة ولا يغير قيم المفاتيح الرئيسية. خيار --all-tables-with-prefix يشمل الجداول التي تبدأ ببادئة الموقع، حتى جداول الإضافات. لا تستخدمه بشكل اعمى على شبكة متعددة المواقع، ولا توسع النطاق لجداول ما بتعرفها.

ليش نتجاوز عمود guid؟

عمود guid معرف ثابت للعنصر، ومش هو الرابط اللي المفروض تبنيه لعرض المقال او الصورة. تغييره مع كل نقل ممكن يسبب تكرار عناصر داخل قارئات RSS او يغير هوية المحتوى. عشان هيك وضعنا --skip-columns=guid. دليل نقل ووردبريس الرسمي ينبه ايضا من الاستبدال الاعمى الذي يكسر البيانات المتسلسلة.

اذا ما عندك WP-CLI

تقدر تستخدم اداة موثوقة تفهم serialization من لوحة التحكم، لكن اعمل نسخة احتياطية وشغل المعاينة او dry run اولا. لا تنزل اول إضافة مجهولة باسم Search Replace وتمنحها صلاحية قاعدة البيانات. راجع عدد التنصيبات والتحديثات والدعم، احذفها بعد انتهاء النقل اذا ما عدت تحتاجها، ولا تترك سكربت استبدال عام متاحا من الويب.

اذا ما عندك وصول للوحة ولا WP-CLI، اطلب من الاستضافة تشغيل استبدال آمن او استخدم سكربتا موثوقا فقط خلال نافذة صيانة، مع حماية الوصول وحذفه مباشرة بعد الاستخدام. تنفيذ أوامر SQL من نوع REPLACE() على كل جدول ممكن ينجح مع HTML العادي لكنه يخاطر بالقيم المتسلسلة.

نطاق البحث اللي لازم تراجعه

الروابط القديمة مش محصورة في post_content. افحص:

• محتوى المقالات والصفحات والقوالب المحفوظة.
• postmeta لمنشئات الصفحات والحقول المخصصة.
• جدول الخيارات للودجات وإعدادات القالب والإضافات.
• روابط src وsrcset والصور الخلفية داخل CSS المحفوظ.
• دومين CDN قديم او روابط من خدمة تحسين صور سابقة.
• القوائم والازرار والنماذج وروابط التحميل الداخلية.

مش كل ظهور للدومين القديم خطأ. ممكن يكون رابط مصدر خارجي مقصود، بريد إلكتروني، نص داخل سجل، او بيانات ارشيفية ما لازم تتغير. عشان هيك العد والمعاينة قبل التنفيذ اهم من الضغط على استبدال الكل.

فحص ما بعد الاستبدال

1. اعد البحث عن الدومين القديم وتأكد من تفسير كل نتيجة باقية.
2. افتح عينة من مقالات قديمة وجديدة، مش الصفحة الرئيسية فقط.
3. افحص الصور البارزة وصور داخل المقال ونسخ srcset.
4. افتح رابط الصورة مباشرة وتأكد من 200 ونوع محتوى يبدأ بـ image/.
5. افحص Console وNetwork للطلبات الفاشلة والمحتوى المختلط.
6. امسح كاش ووردبريس والخادم وCDN بعد تثبيت صحة قاعدة البيانات.
7. احتفظ بتحويلات 301 من الدومين القديم للجديد اذا كان الدومين القديم تحت سيطرتك.

لو الصور الجديدة ترفع وتظهر، لكن صور السنوات القديمة لا تظهر حتى بعد تصحيح الدومين، قارن اسم الملف والمسار داخل uploads. احتمال تكون ملفات النقل ناقصة او الصورة المشار لها نسخة مصغرة قديمة ما عادت موجودة. وقتها استرجع الملفات او اعد توليد المقاسات بعد التأكد من وجود الاصل، بدل تكرار البحث والاستبدال.

تنظيف المختبر

بعد التقاط النتائج حذفنا صفحة الاختبار المنشورة، وخيار المختبر المتسلسل، وصفحة التقرير المؤقتة. ما ثبتنا إضافة استبدال، وما غيرنا اي مقال حقيقي من المقالات السابقة. بقيت إضافة سمسم لاب الاساسية وحدها فعالة، وعدد المقالات المنشورة قبل نشر هذا الدليل بقي 11.

الخلاصة

اذا بقيت صور ووردبريس على الدومين القديم بعد النقل، اثبت اولا ان الملف موجود على العنوان الجديد وان الرابط المخزن هو المشكلة. في تجربتنا كان عندنا 6 مراجع قديمة، والصورة ما ظهرت. الاستبدال النصي الاعمى كسر فك نسخة البيانات المتسلسلة، بينما تبديل القيم بعد فك البنية نقل المراجع إلى 6 جديدة وصفرا قديمة، ورجع ملف الصورة برمز 200 وظهر داخل الصفحة.

على الموقع الحقيقي خذ نسخة احتياطية، شغل wp search-replace مع --dry-run و--skip-columns=guid، راجع النطاق والعدد، ثم افحص الصور والروابط من المتصفح. الاستبدال الآمن جزء من النقل، لكنه ما يعوض الملفات الناقصة او صلاحيات خاطئة او CDN قديم.

تصحيح بتاريخ 6 سبتمبر 2026: صححنا طول الرابط في المثال المتسلسل من 26 إلى 24 بايت، وأضفنا توضيحا لفرق البايتات عن الحروف.