خطأ في الاتصال بقاعدة البيانات في WordPress: كيف تصلحه

تفتح موقعك فتجد كل صفحة — الواجهة الأمامية و wp-admin على حدٍّ سواء — قد استُبدلت بجملة رمادية واحدة: خطأ في الاتصال بقاعدة البيانات. لا شيء يظهر، لأن لا شيء يستطيع الظهور. لم يصل WordPress أصلاً إلى مرحلة بناء الصفحة.

إليك التصور الذهني الذي يجعل الإصلاح سريعاً. يحفظ WordPress كل محتواك — المقالات والصفحات والإعدادات والمستخدمين — في قاعدة بيانات MySQL، لا في ملفات. ومع كل طلب يقرأ أربعة تفاصيل دخول من wp-config.php، ويتصل بتلك القاعدة، ويسحب ما يحتاجه. هذا الخطأ يعني أن الاتصال جرت محاولته ورُفض. والحل هو معرفة لماذا رُفض، وليست هناك سوى ثلاثة احتمالات.

الأسباب الثلاثة، مرتبةً حسب الاحتمال

1. بيان اعتماد خاطئ في wp-config.php — النتيجة المعتادة لنقل الاستضافة.
2. خادم قاعدة البيانات متوقف أو مُحمَّل فوق طاقته — النتيجة المعتادة لعدم تغيير أي شيء من جهتك.
3. قاعدة البيانات تالفة — أقل شيوعاً، وتُعلن عن نفسها بشكل مختلف.

اعمل عليها بهذا الترتيب.

الخطوة الأولى: افحص بيانات الاعتماد الأربعة

افتح wp-config.php في جذر موقعك عبر SFTP أو مدير الملفات لدى مضيفك. أربعة أسطر تُعرِّف الاتصال:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

يجب أن يطابق كل واحد منها تماماً ما خصّصه لك مضيفك. افتح قسم قاعدة البيانات في لوحة تحكم استضافتك (في cPanel اسمه “MySQL Databases”) وقارن حرفاً بحرف:

• DB_NAME — كثيراً ما يسبق المضيفون الاسم باسم حسابك، مثل cpaneluser_wpdb. البادئة جزء من الاسم.
• DB_USER — تنطبق البادئة نفسها، ويجب أن يكون المستخدم مُسنداً إلى تلك القاعدة، لا أن يكون موجوداً فحسب.
• DB_PASSWORD — المتسبب الأكثر شيوعاً بلا منازع. إن لم تكن متأكداً، فأعد تعيينه في لوحة التحكم والصق القيمة الجديدة. وانتبه لمسافة زائدة في النهاية أو علامة اقتباس ذكية.
• DB_HOST — لا تفترض localhost. كثير من المضيفين يستخدمون خادم قاعدة بيانات مخصصاً بعنوان مثل mysql.yourhost.com، وأحياناً مع :port. لوحة التحكم تعرض القيمة الصحيحة.

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

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

الخطوة الثانية: تأكد أن خادم قاعدة البيانات يعمل فعلاً

إن كانت بيانات الاعتماد صحيحة واستمر الخطأ — خصوصاً إن ظهر من تلقاء نفسه دون أي تغيير منك — فخادم قاعدة البيانات نفسه هو المشتبه به.

على الاستضافة المشتركة هذا شائع ومؤقت في الغالب: تُغمَر خدمة MySQL أثناء ذروة الزيارات أو تبلغ حدّ الاتصالات المسموح لكل حساب فتبدأ برفض الاتصالات الجديدة. وعادةً ما تتعافى خلال دقائق قليلة. أعد التحميل بعد انتظار قصير قبل أن تفعل أي شيء جذري.

ولاختبار ما إذا كانت بيانات الاعتماد صالحة أصلاً بمعزل عن WordPress، ضع سكربتاً صغيراً بجوار wp-config.php:

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

استخدم قيم DB_HOST و DB_USER و DB_PASSWORD الحقيقية. فإن طبع Connected، فبيانات دخولك تعمل والمشكلة في مكان آخر (قاعدة بيانات تالفة، الخطوة الثالثة). وإن طبع خطأ اتصال، فالرسالة تخبرك بأيّها: “Access denied” يعني مستخدماً أو كلمة مرور خاطئة؛ و “Can’t connect to MySQL server” يعني مضيفاً خاطئاً أو خدمة متوقفة فعلاً — حان وقت التواصل مع مضيفك. احذف السكربت لحظة انتهائك.

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

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

يملك WordPress أداة إصلاح مدمجة. أضف سطراً واحداً إلى wp-config.php، فوق تعليق “stop editing”:

define( 'WP_ALLOW_REPAIR', true );

ثم افتح هذا الرابط مباشرةً في متصفحك:

https://yoursite.com/wp-admin/maint/repair.php

يُحمَّل دون تسجيل دخول — وهذا هو المقصود، إذ قد تكون محجوباً عن الدخول — ويعرض “Repair Database” و “Repair and Optimize Database”. شغّله.

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

الخطوة الرابعة: حين لا يتصل الإصلاح أصلاً

إن أظهرت صفحة الإصلاح نفسها خطأ الاتصال، فليس هناك ما يُصلَح — لا يمكن الوصول إلى قاعدة البيانات من الأساس، فتعود إلى الخطوة الأولى أو الثانية. عند تلك النقطة تكون الخطوة الموثوقة هي استعادة قاعدة البيانات من أحدث نسخة احتياطية لدى مضيفك. تحتفظ معظم لوحات التحكم بلقطات يومية تلقائية لقاعدة البيانات؛ والاستعادة من ليلة أمس أسرع وأأمن دائماً تقريباً من مطاردة تلف لا تستطيع الاتصال به.

نصائح يمكنك تجاهلها بأمان

“فقط أعد تثبيت WordPress.” هذا الخطأ يتعلق باتصال قاعدة البيانات، لا بملفات النواة. وإعادة التثبيت تستبدل الملفات نفسها التي تعمل بلا مشكلة ولا تمسّ شيئاً معطلاً.

“ارفع حدّ ذاكرة PHP.” نفاد الذاكرة خطأ مختلف برسالة مختلفة. ورفع الحدّ لا يفعل شيئاً لاتصال قاعدة بيانات مرفوض، ولا يخفي إلا أنك لم تفحص بيانات الاعتماد أصلاً.

“امسح ذاكرة التخزين المؤقت.” يقع الفشل في PHP قبل أن تتمكن أي ذاكرة تخزين مؤقت من تقديم صفحة. ومسح الكاش لا يغيّر شيئاً ما دام الاتصال مرفوضاً؛ ولا يستحق العناء إلا بعد عودة الموقع.

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

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

إن تحققت بيانات الاعتماد بسكربت الاختبار، وكان الخادم يعمل، واتصل الإصلاح دون أخطاء، لكن الموقع ما زال يعرض الرسالة، فالمشتبه المتبقي هو إضافة تتحدث إلى قاعدة البيانات عبر اتصالها الخاص — إضافة تخزين مؤقت أو إضافة قاعدة بيانات خزّنت مضيفاً قديماً. أعد تسمية wp-content/plugins إلى plugins-off عبر SFTP لاستبعادها. فإن زال الخطأ، فأعد إدخال الإضافات واحدة تلو الأخرى حتى يعود.