حل خطأ الاتصال بقاعدة البيانات في ووردبريس

قد تظهر شاشة مكتوب فيها خطأ الاتصال بقاعدة البيانات، او العبارة الانجليزية التالية:

Error establishing a database connection

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

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

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

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

ماذا حدث في المختبر؟

استخدمنا ووردبريس 7.1 مع PHP 8.3.30 وMySQL 8.4.3. سجلنا ان الصفحة الرئيسية تعمل، ثم أوقفنا خدمة MySQL الخاصة بنسخة الاختبار فقط. ما غيرنا اسم القاعدة او المستخدم او كلمة المرور.

اول طلب بعد التوقف أعاد 500 Internal Server Error، وظهرت شاشة الاتصال بقاعدة البيانات. هذا يثبت ان الرسالة ممكن تظهر مع بيانات صحيحة تماما اذا كانت الخدمة نفسها غير متاحة.

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

حدد هل الخطأ دائم او متقطع

اذا ظهر الخطأ بعد نقل الموقع او تغيير كلمة مرور قاعدة البيانات وظل ثابتا، ابدأ من ملف wp-config.php. اما اذا الموقع يفتح احيانا ويفشل احيانا بدون تعديل منك، فبيانات الدخول غالبا ليست المشكلة؛ افحص توقف الخدمة، ضغط الاتصالات، الذاكرة، مساحة القرص، او انقطاع الاتصال بقاعدة بعيدة.

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

افحص خدمة قاعدة البيانات اولا

1. افتح صفحة حالة الاستضافة او لوحة ادارة الخادم، وشوف هل MySQL او MariaDB تعمل.
2. اذا كانت الاستضافة مشتركة، تواصل مع الدعم واسأل عن توقف قاعدة البيانات او بلوغ حد الاتصالات وقت الخطأ.
3. اذا عندك خادم تديره بنفسك، افحص سجل قاعدة البيانات والذاكرة ومساحة القرص قبل اعادة التشغيل المتكرر.
4. لا تحذف ملفات او قواعد لتوفير مساحة قبل وجود نسخة احتياطية ومعرفة ما الذي تحذفه.

دليل اخطاء ووردبريس الشائعة يضع مشاكل بيانات wp-config.php ومشاكل شركة الاستضافة ضمن الاسباب الرئيسية لهذا الخطأ.

راجع بيانات wp-config.php بدون كشفها

ملف wp-config.php موجود في جذر تثبيت ووردبريس او مجلد اعلى منه في بعض الاعدادات. خذ نسخة منه قبل التعديل، وقارن القيم مع البيانات التي تعرضها لوحة الاستضافة:

• DB_NAME: اسم قاعدة ووردبريس.
• DB_USER: مستخدم قاعدة البيانات، وليس اسم دخول مدير ووردبريس.
• DB_PASSWORD: كلمة مرور مستخدم القاعدة.
• DB_HOST: عنوان خادم القاعدة، وقد يحتوي منفذا غير افتراضي.

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

يوضح دليل wp-config.php الرسمي ان المنفذ البديل يكتب ضمن DB_HOST، مثل عنوان الخادم متبوعا برقم المنفذ. لا تجرب localhost و127.0.0.1 عشوائيا على موقع مباشر؛ استخدم القيمة التي تعطيك اياها الاستضافة.

تغيير كلمة مرور القاعدة ليس تغيير كلمة مرور المدير

هذه غلطة سهلة: كلمة مرور مستخدم MySQL مختلفة عن كلمة مرور حسابك في لوحة ووردبريس. اذا غيرت كلمة مرور القاعدة من cPanel، لازم تحدث قيمة DB_PASSWORD في wp-config.php بنفس اللحظة. تغييرها لا يساعدك تستعيد دخول المدير، وترك القيمتين مختلفتين يوقف الموقع كله.

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

كيف تختبر بيانات الاتصال؟

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

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

لا تبدأ باصلاح الجداول قبل اثبات وجود تلف

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

اذا قررت استخدام وضع اصلاح ووردبريس، اقرأ التوثيق وخذ نسخة احتياطية، وازل خيار الاصلاح من wp-config.php فور الانتهاء. صفحة الاصلاح صممت لتعمل بدون تسجيل دخول، لذلك تركها مفعلة مخاطرة غير ضرورية.

ماذا نفحص بعد عودة الاتصال؟

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

اذا كان الخطأ متقطعا، اطلب من الاستضافة فحص السجل في الوقت الذي سجلته. عبارة “الموقع بطيء” اقل فائدة من اعطائهم الرابط، وقت الفشل، كود 500، وهل فشل wp-admin ايضا.

الخلاصة من التجربة

ايقاف MySQL وحده جعل ووردبريس يعرض خطأ الاتصال بحالة 500، واعادة تشغيلها أعادت الموقع والمقالات الى 200. لذلك لا نفترض ان المحتوى ضاع، ولا نعدل كلمات المرور قبل التحقق من الخدمة. نحدد هل الخطأ دائم او متقطع، نفحص حالة الخادم، ثم نقارن بيانات wp-config.php مع لوحة الاستضافة بدون كشفها.

من الحالات التي تتكرر في المجتمع مستخدم غير كلمة مرور MySQL وهو يحاول تغيير كلمة مرور دخول ووردبريس، فتوقفت قاعدة البيانات عن الاتصال. استخدمنا الحالة لتوضيح الفرق بين الحسابين، بينما اختبرنا في المختبر السبب الآخر: توقف الخدمة مع بقاء بيانات الاتصال صحيحة.