غيرت رابط ووردبريس وما عدت تدخل للوحة؟ تجربة استرجاع WP_HOME وWP_SITEURL

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

عملنا التجربة على نسخة سمسم لاب المحلية بشكل متعمد وقابل للرجوع. سجلنا القيم قبل التغيير، بدلنا home وsiteurl من المنفذ الصحيح 8802 إلى منفذ ما عليه خادم وهو 8899، وحاولنا فتح لوحة التحكم. بعد ما ظهر الفشل، استخدمنا WP_HOME وWP_SITEURL للاسترجاع المؤقت، ثم اصلحنا قاعدة البيانات واختبرنا الموقع مرة ثانية من دون الثابتين.

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

شو الفرق بين WordPress Address وSite Address؟

WordPress Address او siteurl هو العنوان اللي ووردبريس يعتبر ان ملفاته الاساسية موجودة تحته. اما Site Address او home فهو العنوان العام اللي المفروض الزائر يفتح منه الموقع. بالمواقع العادية القيمتان غالبا متطابقتان، لكن ممكن يختلفوا اذا ملفات ووردبريس داخل مجلد فرعي.

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

قبل التجربة: الموقع والدخول كانوا شغالين

قبل اي تغيير قرأنا القيم من جدول خيارات ووردبريس مباشرة. كانت home وsiteurl تساويان https://semsemm.com. فتحنا الصفحة الرئيسية وحصلنا على استجابة 200، وفتحنا صفحة الدخول والتقطنا الصورة التالية. كان عندنا 10 مقالات منشورة، والإضافة الفعالة الوحيدة هي إضافة سمسم لاب الاساسية.

مرحلة العطل: تغيير القيم إلى 8899

اخترنا المنفذ 8899 لانه عنوان محلي وما عليه خدمة، يعني ما في خطر ارسال زائر او بيانات إلى موقع خارجي. غيرنا القيمتين في قاعدة البيانات، وبعدها طلبنا /wp-admin/ من العنوان الاصلي على 8802.

ووردبريس رد برمز 302، ووضع ترويسة تحويل إلى:

http://127.0.0.1:8899/wp-login.php?redirect_to=...

المتصفح اتبع التحويل، ولانه ما في خادم على 8899 ظهر ERR_CONNECTION_REFUSED. هذه نقطة مهمة: عنوان الصفحة اللي كتبناه بالبداية كان 8802، لكن ووردبريس نفسه ارسل المتصفح إلى 8899 بسبب القيم المخزنة.

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

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

الاسترجاع المؤقت من wp-config.php

اذا ما بتقدر تدخل لوحة التحكم، افتح ملف wp-config.php من مدير ملفات الاستضافة او SFTP. قبل سطر تحميل اعدادات ووردبريس، اضف العنوان الصحيح لموقعك:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

بدل example.com بدومينك الحقيقي، وانتبه لـ https وwww والمجلد الفرعي. في تجربتنا وضعنا https://semsemm.com. بعد الاضافة، طلب لوحة التحكم صار يحول إلى صفحة الدخول على 8802 بدل 8899، وصفحة الدخول فتحت من جديد.

وثائق ووردبريس عن wp-config.php توضح ان WP_HOME يتجاوز قيمة home وان WP_SITEURL يتجاوز siteurl. كلمة يتجاوز مهمة: الثابتان لا يصلحان السجل المخزن داخل قاعدة البيانات.

كيف تأكدنا ان التجاوز مش اصلاح دائم؟

بعد عودة صفحة الدخول، قرأنا القيم بطريقتين في اللحظة نفسها. القراءة المباشرة من قاعدة البيانات اعطت 8899 للقيمتين. لكن home_url() وsite_url() داخل ووردبريس اعطتا 8802، لان الثابتين صارا المرجع الفعال. الصورة التالية تعرض النتيجة الحقيقية، مش رسما تقديريا.

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

الاصلاح الدائم من قاعدة البيانات

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

1. من phpMyAdmin افتح جدول الخيارات. اسمه غالبا wp_options، لكن البداية ممكن تكون مختلفة. ابحث عن السطرين home وsiteurl وعدل القيمة بدقة.
2. اذا عندك WP-CLI، استخدم wp option update home 'https://example.com' ثم wp option update siteurl 'https://example.com'.
3. اذا عندك وصول موثوق لقاعدة البيانات، تقدر تحدث السطرين مباشرة بعد اخذ نسخة احتياطية والتأكد من اسم الجدول.

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

الفحص النهائي بعد الاصلاح

بعد تعديل قاعدة البيانات، ازلنا الثابتين مؤقتا من ملف الاعدادات حتى نتأكد ان النجاح مش ناتج عن التجاوز. النتيجة كانت:

• home المخزنة: 8802.
• siteurl المخزنة: 8802.
• home_url() الفعالة: 8802.
• site_url() الفعالة: 8802.
• الصفحة الرئيسية رجعت برمز 200.
• لوحة التحكم حولت إلى صفحة الدخول على 8802، مش 8899.
• عدد المقالات بقي 10، وما اضفنا اي إضافة مؤقتة.

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

اذا رجع الدخول لكن الصور او الروابط ظلت قديمة

تعديل home وsiteurl يرجع العنوان الاساسي، لكنه مش بالضرورة يبدل كل رابط قديم محفوظ داخل محتوى المقالات، الودجات، او اعدادات الإضافات. عند نقل دومين كامل، خذ نسخة احتياطية واستخدم اداة تفهم البيانات المتسلسلة مثل أمر WP-CLI التالي:

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

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

ليش تغيير HTTP إلى HTTPS ممكن يعمل حلقة تحويل؟

اذا الدومين خلف Cloudflare او وكيل عكسي، ممكن الزائر يوصل عبر HTTPS بينما الخادم الداخلي يشوف الطلب HTTP. وقتها ووردبريس او إضافة الحماية قد يعيد التحويل كل مرة. راجع وضع SSL في الوسيط، شهادة الخادم، وترويسات البروكسي. لا تحل المشكلة بتعطيل HTTPS بشكل دائم، ولا تضيف قواعد تحويل متعددة في ووردبريس والخادم وCloudflare بنفس الوقت.

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

قائمة سريعة قبل تغيير دومين ووردبريس

1. اكتب القيم الحالية لـ home وsiteurl وخذ لقطة او نسخة منها.
2. خذ نسخة احتياطية من قاعدة البيانات قبل التغيير.
3. تأكد ان الدومين الجديد يشير للاستضافة وان شهادة HTTPS جاهزة.
4. انتبه لفرق www ومن دون www، ولأي مجلد فرعي.
5. جهز وصولا إلى مدير الملفات او SFTP وقاعدة البيانات قبل الضغط على حفظ.
6. بعد التغيير افحص الصفحة الرئيسية، الدخول، لوحة التحكم، الصور، الروابط، والنماذج.
7. امسح كاش ووردبريس والخادم وCDN بعد نجاح الفحص، مش قبل ما تعرف سبب المشكلة.

الخلاصة

لما تغير رابط ووردبريس وتفقد الدخول، افحص home وsiteurl قبل ما تعيد تثبيت الموقع او تحذف إضافات. تجربتنا اثبتت ان قيمة خاطئة حولت لوحة التحكم فعليا من 8802 إلى 8899 وانتهت برفض اتصال. ثابتا WP_HOME وWP_SITEURL رجعا الوصول مؤقتا، لكن القياس بين ان قاعدة البيانات بقيت خاطئة. الاصلاح اكتمل فقط بعد تعديل القيم المخزنة، ازالة التجاوز للاختبار، والتأكد من استجابة الموقع والتحويل الصحيح.