# رفع خطاهای رایج وردپرس: صفحه‌ی سفید، ۵۰۰ و خطای اتصال به دیتابیس

- منبع: https://di9.ir/blog/%d8%ae%d8%b7%d8%a7%d9%87%d8%a7%db%8c-%d8%b1%d8%a7%db%8c%d8%ac-%d9%88%d8%b1%d8%af%d9%be%d8%b1%d8%b3
- سایت: دیباگ
- نویسنده: danidiba
- تاریخ انتشار: 2026-08-19
- آخرین به‌روزرسانی: 2026-08-19

سایت تا دیروز کار می‌کرد و امروز فقط یک صفحه‌ی سفید یا پیام «There has been a critical error on this website» نشان می‌دهد. اولین واکنش معمولاً حدس‌زدن است: پاک‌کردن کش، نصب دوباره‌ی وردپرس، عوض‌کردن قالب.

حدس وقت را هدر می‌دهد. تقریباً هر خطای وردپرس یک پیام دقیق در یک فایل گزارش دارد که می‌گوید کدام فایل و کدام خط مشکل دارد. این راهنما نشان می‌دهد آن پیام را کجا پیدا کنید و با رایج‌ترین خطاها چه کنید.

## اولین کار هنگام خطای وردپرس چیست؟#

پیدا کردن متن دقیق خطا، پیش از هر تغییر. اگر خطا از نوع «خطای مهم» باشد، وردپرس معمولاً به ایمیل مدیر پیامی با نام افزونه یا قالب مقصر و لینک ورود در حالت بازیابی می‌فرستد. حالت بازیابی یعنی ورود به پیشخوان در حالی که افزونه یا قالب خراب موقتاً متوقف شده است. اول صندوق ایمیل مدیر را ببینید.

![چهار نشانه‌ی رایج خطای وردپرس، اولین جایی که باید دید و راه رفع رایج هر کدام](/blog/wp-content/uploads/2026/09/fig-w11-1.svg)

## گزارش خطای وردپرس را چطور امن روشن کنیم؟#

با سه ثابت در `wp-config.php` که خطا را در فایل می‌نویسند ولی به بازدیدکننده نشان نمی‌دهند. این خط‌ها را بالای خط پایان ویرایش بگذارید و اگر `WP_DEBUG` از قبل هست، فقط مقدارش را عوض کنید:

PHPکپی`define( &#039;WP_DEBUG&#039;, true );
define( &#039;WP_DEBUG_LOG&#039;, &#039;/home/USERNAME/wp-errors.log&#039; );
define( &#039;WP_DEBUG_DISPLAY&#039;, false );
@ini_set( &#039;display_errors&#039;, &#039;0&#039; );`

مقدار `WP_DEBUG_LOG` مسیر فایلی بیرون از `public_html` است، چون مسیر پیش‌فرض یعنی `wp-content/debug.log` از بیرون قابل دیدن است. `USERNAME` را با نام کاربری سی‌پنل عوض کنید.

جای دوم، گزارش خود هاست است. سی‌پنل معمولاً خطاهای PHP را در فایلی به نام `error_log` در همان پوشه‌ای می‌نویسد که خطا در آن رخ داده، و بخش Errors سی‌پنل هم آخرین خطاهای وب‌سرور را نشان می‌دهد. بعد از پیدا کردن علت، `WP_DEBUG` را دوباره `false` کنید.

## صفحه‌ی سفید یا «خطای مهم» را چطور رفع کنیم؟#

در بیشتر موارد با غیرفعال‌کردن افزونه یا قالبی که گزارش خطا نامش را آورده است. در متن خطا دنبال مسیری مثل `wp-content/plugins/نام-افزونه/` بگردید؛ همان افزونه مقصر است.

- در File Manager وارد `wp-content/plugins` شوید.

- نام پوشه‌ی افزونه‌ی مقصر را عوض کنید، مثلاً `-off` به آخرش اضافه کنید.

- سایت را بازخوانی کنید. اگر برگشت، علت همان افزونه بوده است.

- اگر مقصر معلوم نیست، نام کل پوشه‌ی `plugins` را موقتاً عوض کنید، وارد پیشخوان شوید، نام را برگردانید و افزونه‌ها را یکی‌یکی فعال کنید.

- اگر خطا از قالب است، نام پوشه‌ی قالب را در `wp-content/themes` عوض کنید؛ وردپرس به یکی از قالب‌های پیش‌فرض نصب‌شده برمی‌گردد.

دو علت رایج دیگر: **تغییر نسخه‌ی PHP** که افزونه‌ی قدیمی با آن سازگار نیست، و **تمام‌شدن حافظه** با پیام Allowed memory size exhausted. برای اولی نسخه‌ی PHP را موقتاً از Select PHP Version برگردانید و افزونه را به‌روز یا جایگزین کنید. برای دومی، پیش از افزایش حافظه ببینید کدام افزونه آن را مصرف می‌کند.

اگر خطا بعد از افزودن کدی پیش آمده که دستیار هوش مصنوعی نوشته، همان کد را اول بردارید؛ روش امن چنین کدی در [ساخت افزونه‌ی وردپرس با هوش مصنوعی](/blog/ساخت-افزونه-وردپرس-با-هوش-مصنوعی) آمده است.

## خطای ۵۰۰ وردپرس از کجا می‌آید؟#

از فایل `.htaccess` خراب، خطای مرگبار PHP یا دسترسی نادرست فایل‌ها. خطای ۵۰۰ یعنی سرور در اجرای درخواست به مشکل خورده ولی جزئیات را به مرورگر نمی‌گوید؛ جزئیات در `error_log` است.

- **`.htaccess`:** نام آن را به `.htaccess-old` تغییر دهید. اگر سایت برگشت، در **تنظیمات ← پیوندهای یکتا** بدون تغییر ذخیره را بزنید تا وردپرس فایل تازه بسازد، و قاعده‌های اضافه‌ی خودتان را یکی‌یکی برگردانید.

- **دسترسی فایل‌ها:** فایل‌ها `644` و پوشه‌ها `755`. دسترسی `777` روی بسیاری از هاست‌های اشتراکی خودش خطای ۵۰۰ می‌دهد.

- **تنظیم نامجاز:** خط‌هایی مثل `php_value` در `.htaccess` روی بعضی هاست‌ها مجاز نیستند؛ تنظیمات PHP را از بخش Select PHP Version انجام دهید.

## خطای اتصال به دیتابیس چه علتی دارد؟#

پیام Error establishing a database connection یعنی وردپرس نتوانسته با اطلاعات `wp-config.php` به دیتابیس وصل شود. علت‌ها به ترتیب احتمال:

علتچطور بررسی کنیدنام دیتابیس، کاربر یا رمز اشتباهمقدارها را با بخش MySQL Databases سی‌پنل مقایسه کنیدکاربر به دیتابیس وصل نیستدر همان بخش کاربر را با همه‌ی دسترسی‌ها اضافه کنیدسرور دیتابیس شلوغ یا در دسترس نیستاگر گاه‌به‌گاه است، از پشتیبانی هاست بپرسیدجدول‌های آسیب‌دیدهابزار تعمیر داخلی وردپرس

برای ابزار تعمیر، این خط را موقتاً به `wp-config.php` اضافه کنید، نشانی `/wp-admin/maint/repair.php` سایت را باز کنید و تعمیر را اجرا کنید:

PHPکپی`define( &#039;WP_ALLOW_REPAIR&#039;, true );`

> صفحه‌ی تعمیر بدون ورود در دسترس است. بلافاصله بعد از تعمیر این خط را پاک کنید.

اگر خطا درست بعد از انتقال سایت پیدا شده، مرحله‌های [انتقال وردپرس به هاست جدید](/blog/انتقال-وردپرس-به-هاست-جدید) را مرور کنید؛ پیشوند جدول ناهماهنگ هم علت رایجی است.

## خطاهای رایج دیگر وردپرس کدام‌اند؟#

شش خطای دیگر که هر کدام علت تقریباً ثابتی دارند و بدون گزارش خطا هم قابل تشخیص‌اند:

پیام یا نشانهعلتراه رفعBriefly unavailable for scheduled maintenanceبه‌روزرسانی نیمه‌کارهفایل `.maintenance` را از ریشه پاک کنیدتغییر مسیر بیش از حدناهماهنگی `http` و `https` در نشانی سایتنشانی‌ها را یکی کنیدخطای ۴۰۳ هنگام ذخیره‌ی نوشتهقاعده‌ی دیوار آتش هاستاز پشتیبانی هاست استثنا بخواهیدخطای ۵۰۸ یا کندی شدیدرسیدن به سقف منابعکش و حذف بار اضافهنداشتن اجازه‌ی دسترسی بعد از انتقالپیشوند جدول ناهماهنگپیشوند را در پیکربندی اصلاح کنیدشکست بارگذاری فایلسقف حجم بارگذاری PHPمقدار را در Select PHP Version بالا ببرید

برای تغییر مسیر بیش از حد، [HTTPS و محتوای ترکیبی روی سی‌پنل](/blog/mixed-content-و-https-روی-سی-پنل) و برای ۵۰۸، [خطای ۵۰۸ و سقف منابع هاست](/blog/خطای-508-resource-limit-reached) را ببینید.

## از هوش مصنوعی برای خطایابی چطور کمک بگیریم؟#

چند خط آخر گزارش خطا، نسخه‌ی PHP و وردپرس و آنچه تا حالا امتحان کرده‌اید را بدهید. پیش از فرستادن، رمز دیتابیس، کلیدها و نشانی ایمیل را از متن پاک کنید. روش کامل در [دیباگ با هوش مصنوعی](/blog/دیباگ-با-هوش-مصنوعی) آمده است.

## خطایابی وردپرس به کجا می‌رود#

جهت‌ها روشن‌اند: وردپرس در برابر خطا مقاوم‌تر شده است؛ حالت بازیابی، گزارش سلامت سایت و برگرداندن خودکار به‌روزرسانی افزونه‌ای که سایت را از کار بیندازد نمونه‌های آن‌اند. در مقابل، نسخه‌های تازه‌ی PHP سخت‌گیرترند و کدی که قبلاً فقط هشدار می‌داد، حالا خطای مرگبار می‌دهد. یعنی بیشتر خطاهای آینده هنگام ارتقای PHP یا افزونه‌های رهاشده پیش می‌آیند.

برای آماده‌بودن:

- مسیر گزارش خطا را از همین حالا بیرون از `public_html` تعریف کنید تا روز خطا آماده باشد.

- ارتقای PHP و به‌روزرسانی‌های بزرگ را اول روی محیط آزمایشی امتحان کنید.

- ایمیل مدیر را واقعی نگه دارید تا پیام حالت بازیابی به دستتان برسد.

- افزونه‌هایی را که مدت‌هاست به‌روز نشده‌اند با جایگزین فعال عوض کنید.

## خلاصه#

- حدس نزنید؛ اول متن دقیق خطا را در گزارش پیدا کنید.

- گزارش خطا را در فایلی بیرون از `public_html` بنویسید و روی صفحه نمایش ندهید.

- افزونه‌ی مقصر را با تغییر نام پوشه‌اش در File Manager غیرفعال کنید.

- خطای ۵۰۰: `.htaccess`، خطای PHP و دسترسی فایل‌ها را بررسی کنید.

- خطای دیتابیس: اطلاعات `wp-config.php` و وصل‌بودن کاربر به دیتابیس.