الخبر الجيد أولًا

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

ابدأ بسؤالين

قبل أي تعديل، افتح yoursite.com/wp-admin وقارنه بالصفحة الرئيسية. الفارق يحدّد مسار التشخيص:

ما تعرضه لوحة التحكمالمعنىانتقل إلى
نفس خطأ الاتصالووردبريس لا يصل إلى الخادم إطلاقًابيانات الاعتماد والخادم
«جدول أو أكثر غير متاح… قد تحتاج قاعدة البيانات إلى إصلاح»الاتصال يعمل؛ الجداول تالفةإصلاح الجداول

١. تحقّق من بيانات الاعتماد

افتح wp-config.php. يجب أن تطابق هذه القيم الأربع ما تعرضه استضافتك بالضبط:

define( 'DB_NAME', 'your_database' );
define( 'DB_USER', 'your_db_user' );
define( 'DB_PASSWORD', 'your_password' );
define( 'DB_HOST', 'localhost' );

القيمة التي توقع الجميع هي DB_HOST. فـ localhost صحيحة في معظم الاستضافات المشتركة، لكن بعض المستضيفين يطلبون 127.0.0.1 أو منفذًا (127.0.0.1:3306) أو اسم مضيف مخصصًا. وإذا نقلك المستضيف مؤخرًا إلى خادم جديد، فغالبًا هذه هي القيمة الوحيدة التي تغيّرت.

٢. اختبر الاتصال خارج ووردبريس

لا تخمّن — أثبت. ضع هذا الملف في جذر الموقع باسم dbtest.php، افتحه في المتصفح، ثم احذفه فورًا:

<?php
$c = @new mysqli('localhost', 'your_db_user', 'your_password', 'your_database');
echo $c->connect_error ? 'فشل: ' . $c->connect_error : 'الاتصال ناجح.';

«الاتصال ناجح» يعني أن بياناتك صحيحة والمشكلة في مكان آخر: جداول تالفة، أو إضافة تحتكر الاتصالات، أو wp-config.php مُعدَّل. أما Access denied فيعني اسم مستخدم أو كلمة مرور خاطئة، وCan't connect to MySQL server يعني أن الخدمة نفسها غير متاحة.

٣. هل خادم قاعدة البيانات يعمل أصلًا؟

  • مواقعك الأخرى على نفس الحساب متوقفة أيضًا؟ مشكلة على مستوى الخادم. تواصل مع المستضيف؛ لا شيء تصلحه في ملفاتك.
  • الموقع يعمل متقطعًا ويسقط تحت الضغط؟ أنت تبلغ حد max_connections. شائع في الاستضافة المشتركة خلال الذروة، وسببه غالبًا استعلام بطيء يحتجز الاتصالات.
  • تجاوزت حدود باقتك مؤخرًا؟ بعض المستضيفين يعلّقون قاعدة البيانات قبل الحساب. راجع لوحة الفوترة وبريدك.

٤. إصلاح الجداول التالفة

إذا أخبرتك لوحة التحكم أن القاعدة تحتاج إصلاحًا، أضف إلى wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

ثم افتح yoursite.com/wp-admin/maint/repair.php وشغّل الإصلاح. وعند الانتهاء احذف هذا السطر فورًا — فما دام موجودًا تكون صفحة الإصلاح متاحة لأي شخص على الإنترنت دون تسجيل دخول.

التلف عَرَض لا سبب

الجداول لا تتلف من تلقاء نفسها. إعادة تشغيل مفاجئة للخادم، أو قرص ممتلئ، أو عملية MySQL تنهار — أحدها هو الفاعل. وإن تكرر الأمر مرتين، توقّف عن الإصلاح واسأل مستضيفك لماذا تموت الخدمة.

٥. حين يكون السبب اختراقًا

سبب أقل وضوحًا: برمجية خبيثة أعادت كتابة wp-config.php. بعض الإصابات تُفسد الملف أثناء ذلك، وأخرى تحقن شيفرة قبل وسم <?php فتكسر التحليل. افتح الملف وتأكد أنه يبدأ نظيفًا، وأنه خالٍ من eval() أو كتل base64 غير متوقعة، وأن البيانات هي التي تعرفها.

وإذا تغيّرت كلمة مرور قاعدة البيانات دون أن تغيّرها أنت، فتعامل مع الأمر بوصفه حادثة أمنية لا مشكلة إعدادات.

الموقع ما زال متوقفًا؟

أعطال قاعدة البيانات من أسرع ما يُحل — غالبًا في أقل من ٣٠ دقيقة. أرسل لي رابط الموقع واسم شركة الاستضافة.

أسئلة شائعة

ما أسباب هذا الخطأ؟

لم يتمكن ووردبريس من الوصول إلى MySQL. أربعة أسباب شائعة: بيانات اعتماد خاطئة، خادم متوقف أو مُحمَّل، جداول تالفة، وبلوغ حد الاتصالات في الاستضافة المشتركة.

لماذا الآن، ولم أغيّر شيئًا؟

غالبًا أعاد المستضيف تشغيل الخادم أو حمّله فوق طاقته، أو بلغت حد الاتصالات في ذروة الزيارات، أو عُلّق الحساب.

هل سأفقد محتواي؟

نادرًا جدًا. البيانات على القرص وووردبريس لا يصل إليها فحسب. وحتى التلف الحقيقي يُصلَح عادةً.

يعمل أحيانًا ويتوقف أحيانًا.

استنفاد كلاسيكي للاتصالات. قاعدتك تسمح بعدد ثابت من الاتصالات المتزامنة وتبلغ السقف تحت الضغط. الحل الحقيقي هو العثور على الاستعلام البطيء المسؤول.