خطای اتصال به پایگاه داده در 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 را با SFTP به plugins-off تغییر نام دهید. اگر خطا برطرف شد، افزونه‌ها را یکی‌یکی برگردانید تا دوباره برگردد.