خطاهای رایج وردپرس و روش رفع آن‌ها

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

قبل از هر تغییر: سه کاری که جلوی خراب‌تر شدن را می‌گیرد

• بکاپ کامل بگیرید. هم از فایل‌ها و هم از دیتابیس. بسیاری از راه‌حل‌های زیر شامل ویرایش wp-config.php یا .htaccess است و یک اشتباه تایپی می‌تواند سایت را کاملاً از دسترس خارج کند.
• یک راه دسترسی جایگزین داشته باشید. در بیشتر این خطاها اصلاً به پیشخوان وردپرس دسترسی ندارید و باید از File Manager کنترل‌پنل هاست، FTP یا SSH کار کنید.
• ارور لاگ سرور را ببینید. در سی‌پنل از بخش Errors، و معمولاً هم فایلی به نام error_log کنار index.php سایت ساخته می‌شود. متن دقیق خطا در همین فایل است و شما را مستقیم به فایل و افزونه‌ی مقصر می‌رساند.

قدم اول در هر خطا: روشن کردن نمایش خطا در وردپرس

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

فایل wp-config.php را در مسیر اصلی نصب وردپرس باز کنید — همان فایلی که هنگام نصب وردپرس روی سی پنل ساخته می‌شود — و دنبال این خط بگردید:

define('WP_DEBUG', false);

عبارت false را به true تغییر دهید و فایل را ذخیره کنید:

define('WP_DEBUG', true);

اگر این خط اصلاً در فایل نبود، خودتان اضافه‌اش کنید؛ اما حتماً بالای خط /* That's all, stop editing! */، وگرنه وردپرس آن را نمی‌خواند.

روی سایت آنلاین، خطا را در فایل لاگ بنویسید نه روی صفحه

نمایش مستقیم خطا روی صفحه، مسیر فایل‌های سرور و گاهی اطلاعات دیتابیس را به هر بازدیدکننده‌ای نشان می‌دهد. روی سایتی که در حال سرویس‌دهی است، به‌جای فقط WP_DEBUG این چهار خط را بگذارید تا خطاها بی‌سروصدا در فایل ذخیره شوند:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

خطاها در فایل wp-content/debug.log نوشته می‌شوند. بعد از پیدا کردن مشکل، حتماً WP_DEBUG را دوباره false کنید و فایل debug.log را پاک کنید، چون این فایل با مرورگر هم قابل باز کردن است.

پیام خطا را چطور بخوانیم

با این تغییر، خطاها هم در بخش قالب و صفحات جلوی سایت و هم در پیشخوان مدیریت نمایش داده می‌شوند. متن خطایی که ظاهر می‌شود معمولاً نام فایل و شماره خط را نشان می‌دهد؛ همین دو تکه اطلاعات مشخص می‌کند مقصر کدام افزونه یا قالب است. نمونه‌ای از تحلیل چنین پیامی را در رفع خطای Parse error آورده‌ایم. توجه داشته باشید که روشن کردن نمایش خطا همیشه مشکل را کامل حل نمی‌کند و همه خطاها هم مستقیماً به قالب یا افزونه مربوط نیستند؛ در این موارد یافتن ریشه مشکل دشوارتر است و باید سراغ ارور لاگ سرور بروید.

خطاهای سطح سرور و دسترسی

خطای ۵۰۰ یا ۵۰۳ Internal Server Error

اول یک نکته که خیلی‌ها قاطی می‌کنند: این دو خطا یکی نیستند. ۵۰۰ یعنی Internal Server Error (خطای داخلی سرور) و معمولاً ریشه‌اش در خود سایت است؛ ۵۰۳ یعنی Service Unavailable (سرویس در دسترس نیست) و بیشتر وقت‌ها یعنی ظرفیت پردازش سرور پر شده — مثلاً پروسه‌های PHP-FPM یا سقف منابع اکانت در هاست اشتراکی.

علت: خرابی یا دستور نامعتبر در فایل .htaccess، خطای مرگبار (fatal error) در یک افزونه یا قالب، یا کمبود منابع مثل حافظه PHP و پر شدن سقف پروسه‌ها.

راه‌حل ۱ — فایل htaccess را کنار بگذارید: فایل .htaccess را در مسیر اصلی سایت به نام دیگری تغییر دهید (مثلاً htaccess-old). اگر سایت بالا آمد، مقصر همین فایل بوده است. توجه کنید که این کار ریدایرکت‌ها و قواعد امنیتی داخل همان فایل را هم موقتاً از کار می‌اندازد، پس این حالت را طولانی نگه ندارید. برای بازسازی نسخه سالم، وارد پیشخوان شوید و در بخش «پیوندهای یکتا» از منوی تنظیمات فقط دکمه ذخیره را بزنید تا وردپرس فایل استاندارد را دوباره بسازد. جزئیات بیشتر در رفع مشکل فایل htaccess آمده است. محتوای پیش‌فرض این فایل چنین است:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

راه‌حل ۲ — افزونه‌ها و قالب: همه افزونه‌ها را غیرفعال کنید و قالب را موقتاً به یکی از قالب‌های پیش‌فرض وردپرس تغییر دهید. اگر به پیشخوان دسترسی ندارید، از File Manager نام پوشه wp-content/plugins را به plugins-off تغییر دهید؛ وردپرس همه افزونه‌ها را غیرفعال می‌کند. بعد نام را برگردانید و افزونه‌ها را یکی‌یکی فعال کنید تا مقصر پیدا شود. بدانید که با این روش افزونه‌ها بعد از برگرداندن نام پوشه همچنان غیرفعال می‌مانند و باید دستی فعالشان کنید؛ تنظیمات و داده‌هایشان اما پاک نمی‌شود.

راه‌حل ۳ — حافظه PHP: این خط را در wp-config.php و بالای خط /* That's all, stop editing! */ اضافه کنید:

define( 'WP_MEMORY_LIMIT', '256M' );

دقت کنید این تنظیم فقط تا سقفی کار می‌کند که memory_limit خود PHP روی سرور اجازه می‌دهد؛ اگر مقدار سرور کمتر باشد، باید از MultiPHP INI Editor در سی‌پنل یا از php.ini آن را افزایش دهید یا از پشتیبانی بخواهید.

خطای ۴۰۳ Forbidden

علت: سطح دسترسی نادرست فایل‌ها و پوشه‌ها، قواعد امنیتی در .htaccess، افزونه امنیتی، یا فایروال و ModSecurity سرور.

راه‌حل ۱ — سطح دسترسی‌ها: استاندارد درست ۷۵۵ برای پوشه‌ها و ۶۴۴ برای فایل‌ها است. برای wp-config.php مقدار ۶۴۰ یا ۶۰۰ امن‌تر است. هیچ‌وقت برای رفع خطا دسترسی ۷۷۷ ندهید؛ این کار سایت را در معرض خطر می‌گذارد و روی بسیاری از سرورها خودش باعث ۴۰۳ می‌شود.

اگر SSH دارید، این دو دستور همه چیز را یک‌جا استاندارد می‌کنند — اما قبل از اجرا حتماً دو نکته زیر را بخوانید:

cd /home/USERNAME/public_html
pwd
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chmod 640 wp-config.php

هشدار اول — حتماً اول با pwd مطمئن شوید داخل پوشه سایت هستید. این دستورها بازگشتی‌اند و هرچه زیر مسیر فعلی باشد را تغییر می‌دهند. اگر اشتباهی در پوشه خانگی اکانت (/home/USERNAME) اجرایشان کنید، دسترسی .ssh و authorized_keys هم عوض می‌شود و ورود SSH با کلید از کار می‌افتد — یعنی ممکن است خودتان را از سرور بیرون بیندازید؛ پوشه ایمیل و تنظیمات کنترل‌پنل هم آسیب می‌بیند.

هشدار دوم: خط دوم wp-config.php را هم روی ۶۴۴ می‌برد، برای همین خط آخر آن را دوباره به ۶۴۰ برمی‌گرداند. اگر روی سرورتان ۶۴۰ باعث خطا شد، ۶۴۴ را نگه دارید.

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

راه‌حل ۳ — قواعد دستی htaccess: آموزش‌های قدیمی برای محافظت از فایل‌ها از دستورهای Apache 2.2 استفاده می‌کنند که منسوخ است و روی Apache 2.4 بدون ماژول mod_access_compat یا کار نمی‌کند یا خطای ۵۰۰ می‌دهد. شکل قدیمی:

<Files wp-config.php>
Order allow,deny
Deny from all
</Files>

معادل امروزی همان قاعده در Apache 2.4 این است:

<Files wp-config.php>
Require all denied
</Files>

نمونه‌های بیشتر محدودسازی دسترسی را در ایمن‌سازی سایت با htaccess در کلودفلر و CDN ببینید.

خطای ۴۲۹ Too Many Requests

علت: ارسال بیش از حد درخواست از یک آی‌پی؛ معمولاً ربات‌های خزنده، حمله brute force روی صفحه ورود، یا محدودیت نرخ درخواست خود هاست.

راه‌حل: منبع درخواست‌ها را از ارور لاگ یا آمار بازدید پیدا کنید. اگر ربات‌های خزنده‌اند، محدودسازی واقعی باید در سطح سرور، فایروال یا کلودفلر (Rate Limiting) انجام شود. توجه کنید که robots.txt فقط یک درخواست مؤدبانه است و ربات‌های مخرب آن را نادیده می‌گیرند؛ دستور Crawl-delay را هم گوگل اصلاً اعمال نمی‌کند. اگر منبع، تلاش برای ورود است، افزونه محدودکننده تلاش‌های ناموفق ورود کارساز است.

خطاهای پایگاه داده

Error establishing a database connection

علت: اشتباه بودن اطلاعات اتصال در wp-config.php، از کار افتادن سرویس دیتابیس، پر شدن سقف اتصال‌های همزمان، یا آسیب دیدن جدول‌ها.

راه‌حل:

• در wp-config.php چهار مقدار DB_NAME، DB_USER، DB_PASSWORD و DB_HOST را با اطلاعات واقعی در بخش MySQL Databases هاست مقایسه کنید. در سی‌پنل به‌طور پیش‌فرض نام دیتابیس و نام کاربری با پیشوند نام کاربری اکانت ساخته می‌شوند (مدیر سرور می‌تواند این پیش‌فرض را در WHM خاموش کند، پس نام واقعی را از خود کنترل‌پنل بخوانید) و DB_HOST معمولاً localhost است.
• مطمئن شوید کاربر دیتابیس واقعاً به آن دیتابیس اختصاص داده شده و دسترسی ALL PRIVILEGES دارد.
• اگر اطلاعات درست است و باز خطا می‌گیرید، احتمالاً سرویس MySQL/MariaDB مشکل دارد یا سقف اتصال‌های همزمان پر شده؛ این مورد را باید پشتیبانی هاست بررسی کند.

اگر پیام خطا از خراب بودن جدول‌ها خبر می‌دهد، به‌طور موقت این خط را به wp-config.php اضافه کنید و به آدرس /wp-admin/maint/repair.php بروید:

define( 'WP_ALLOW_REPAIR', true );

بعد از پایان تعمیر، این خط را حتماً حذف کنید؛ تا وقتی این تنظیم فعال باشد، صفحه تعمیر بدون نیاز به ورود برای همه قابل دسترسی است.

صفحه سفید و خطاهای PHP

صفحه سفید وردپرس (White Screen of Death)

علت: خطای مرگبار در کد PHP یک افزونه یا قالب، یا تمام شدن حافظه PHP.

راه‌حل:

• نمایش خطا را طبق بخش ابتدای همین مقاله روشن کنید تا صفحه سفید تبدیل به یک پیام مشخص با نام فایل و شماره خط شود.
• همه افزونه‌ها را غیرفعال کنید و قالب پیش‌فرض را فعال کنید.
• حافظه PHP را با WP_MEMORY_LIMIT افزایش دهید.

نکته‌ای که مقاله‌های قدیمی ندارند: در نسخه‌های امروزی وردپرس معمولاً به‌جای صفحه کاملاً سفید، پیام «سایت با یک مشکل فنی روبه‌رو است» را می‌بینید و وردپرس به ایمیل مدیر سایت یک لینک ورود به حالت بازیابی (Recovery Mode) می‌فرستد. با آن لینک می‌توانید وارد پیشخوان شوید در حالی که افزونه یا قالب مقصر موقتاً غیرفعال شده است. پس قبل از هر کاری، ایمیل مدیر سایت (و پوشه اسپم آن) را چک کنید.

خطای Syntax error یا Parse error

علت: ویرایش اشتباه در کدهای قالب یا افزونه؛ معمولاً یک پرانتز، سمی‌کالن یا آکولاد جا افتاده — اغلب بعد از کپی کردن یک قطعه کد در functions.php.

راه‌حل: خود پیام خطا نام فایل و شماره خط را می‌گوید. آن فایل را با File Manager یا FTP باز کنید و کد اضافه‌شده را حذف یا اصلاح کنید، یا فایل را با نسخه سالم قالب/افزونه جایگزین کنید. راهنمای گام‌به‌گام در رفع خطای Parse error آمده است. برای جلوگیری از تکرار، کدهای دلخواه را به‌جای functions.php قالب، در یک افزونه کوچک اختصاصی یا قالب فرزند بگذارید.

خطاهایی که بعد از تغییر نسخه PHP ظاهر می‌شوند

اگر سایت دقیقاً بعد از ارتقای نسخه PHP سفید شد یا خطای Uncaught Error: Call to undefined function داد، مشکل از کد قدیمی قالب یا افزونه است، نه از سرور. مواردی که بیشترین دردسر را می‌سازند:

• توابع خانواده mysql_* (مثل mysql_connect()) در PHP 7 حذف شده‌اند؛ جایگزین آن‌ها mysqli یا PDO است.
• توابع create_function() و each() در PHP 8 حذف شده‌اند و قالب‌های قدیمی به همین دلیل کاملاً از کار می‌افتند.
• در PHP 8 بسیاری از چیزهایی که قبلاً فقط Warning بودند به خطای مرگبار تبدیل شده‌اند؛ یعنی کدی که در PHP 7 «کار می‌کرد» حالا سایت را می‌خواباند.

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

خطاهای نصب و به‌روزرسانی افزونه و قالب

وردپرس هنگام نصب افزونه یا قالب اطلاعات FTP می‌خواهد

هنگام نصب افزونه، نصب قالب یا به‌روزرسانی وردپرس، به‌جای انجام کار، فرم درخواست اطلاعات FTP ظاهر می‌شود و حتی با وارد کردن اطلاعات درست هم قبول نمی‌کند.

علت: وردپرس نتوانسته تشخیص دهد که خودش اجازه نوشتن مستقیم روی فایل‌ها را دارد، بنابراین سراغ روش FTP رفته است.

راه‌حل: وارد File Manager هاست شوید، فایل wp-config.php را پیدا کنید، روی آن کلیک و از بالای صفحه گزینه Edit را بزنید. خط زیر را اضافه کنید — حتماً بالای خط /* That's all, stop editing! */، وگرنه وردپرس آن را نمی‌خواند — و فایل را Save کنید:

define( 'FS_METHOD', 'direct' );

این خط به وردپرس می‌گوید فایل‌ها را مستقیم بنویسد و سراغ FTP نرود.

اگر باز هم کار نکرد، مشکل از مالکیت فایل‌هاست نه از این تنظیم. وردپرس فقط وقتی می‌تواند مستقیم بنویسد که فایل‌های سایت متعلق به همان کاربری باشند که PHP با آن اجرا می‌شود. در سی‌پنل این حالت پیش‌فرض است؛ اگر فایل‌ها را با کاربر دیگری (مثلاً root) کپی کرده باشید، از پشتیبانی بخواهید مالکیت پوشه سایت را اصلاح کند. دو مورد دیگر را هم چک کنید: دسترسی نوشتن روی پوشه wp-content و پر نبودن فضای اکانت هاست.

Could not create directory و Installation failed

علت: مجوز ناکافی برای ساخت پوشه، یا پر بودن فضای دیسک.

راه‌حل: سطح دسترسی wp-content و زیرپوشه‌های themes، plugins و uploads را روی ۷۵۵ و مالکیت آن‌ها را روی کاربر اکانت تنظیم کنید، و میزان فضای باقی‌مانده اکانت را ببینید. اگر خود فایل .htaccess خراب شده باشد، رفع مشکل فایل htaccess نشانه‌ها و راه‌حل آن را دارد.

Destination folder already exists

علت: نصب قبلی همان افزونه یا قالب که ناقص مانده و پوشه‌اش باقی است.

راه‌حل: اگر همان افزونه از قبل نصب است، به‌جای نصب دوباره از گزینه به‌روزرسانی استفاده کنید. در غیر این صورت پوشه مربوطه را از wp-content/plugins یا wp-content/themes حذف کنید و دوباره نصب کنید.

Briefly unavailable for scheduled maintenance

علت: وردپرس هنگام به‌روزرسانی فایلی به نام .maintenance در مسیر اصلی می‌سازد و در پایان حذف می‌کند؛ اگر به‌روزرسانی نیمه‌کاره بماند، این فایل باقی می‌ماند و سایت در حالت تعمیر گیر می‌کند.

راه‌حل: فایل .maintenance را از مسیر اصلی وردپرس حذف کنید. توجه کنید که این فایل مخفی است؛ در File Manager باید نمایش فایل‌های مخفی (Show Hidden Files) را فعال کنید. بعد از حذف، به‌روزرسانی را دوباره و این بار کامل انجام دهید.

خطاهای آپلود و رسانه

Missing a temporary folder

علت: نبود یا نامعتبر بودن مسیر پوشه موقت برای آپلود فایل.

راه‌حل: اول پوشه‌ای به نام temp داخل wp-content بسازید (این مرحله را جا نیندازید؛ تعریف کردن مسیری که وجود ندارد مشکل را حل نمی‌کند) و سپس این خط را به wp-config.php اضافه کنید:

define( 'WP_TEMP_DIR', dirname(__FILE__) . '/wp-content/temp/' );

دسترسی این پوشه را روی ۷۵۵ و مالکیتش را روی کاربر اکانت بگذارید، وگرنه وردپرس باز هم نمی‌تواند در آن بنویسد. این خط فرض می‌کند wp-config.php در همان مسیر اصلی وردپرس است؛ اگر آن را یک پوشه بالاتر برده‌اید، مسیر را متناسب اصلاح کنید.

تصویر در کتابخانه رسانه آپلود نمی‌شود

علت: مجوز نادرست پوشه uploads، کمبود حافظه PHP هنگام پردازش تصویر، یا حجم بیش از حد فایل.

راه‌حل: دسترسی wp-content/uploads و زیرپوشه‌های سال و ماه آن را روی ۷۵۵ بگذارید و مالکیتشان را چک کنید. اگر پیام «HTTP error» می‌گیرید، معمولاً پردازش تصویر به حافظه بیشتری نیاز دارد؛ WP_MEMORY_LIMIT را بالا ببرید و تصویر بسیار بزرگ را قبل از آپلود کوچک‌تر کنید.

Maximum execution time exceeded

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

راه‌حل: مقدار max_execution_time را افزایش دهید. مطمئن‌ترین جا در هاست اشتراکی، ابزار MultiPHP INI Editor سی‌پنل است. روی سرور اختصاصی یا VPS، مقدار را در php.ini تغییر دهید و بعد سرویس PHP را ری‌استارت کنید. چون نام سرویس روی هر سرور فرق می‌کند، اول آن را پیدا کنید و بعد همان نام را ری‌استارت کنید:

systemctl list-units --type=service | grep -i php
systemctl restart php-fpm

در AlmaLinux و Rocky Linux فایل تنظیمات معمولاً /etc/php.ini و نام سرویس php-fpm است؛ در اوبونتو فایل /etc/php/8.x/fpm/php.ini است و نام سرویس شامل نسخه می‌شود (مثلاً php8.2-fpm). روی سرورهای سی‌پنل با EasyApache 4 اصلاً سرویسی به نام php-fpm وجود ندارد؛ آنجا هر نسخه سرویس جدا دارد (مثلاً ea-php82-php-fpm) و بهتر است تنظیمات را از همان MultiPHP INI Editor عوض کنید تا با به‌روزرسانی‌های بعدی کنترل‌پنل بازنویسی نشود. دستورهای قدیمی مثل service php-fpm restart یا /etc/init.d/php-fpm restart منسوخ‌اند؛ روی توزیع‌های امروزی یا کار نمی‌کنند یا در نهایت به همان systemctl هدایت می‌شوند.

یک هشدار مهم: در آموزش‌های قدیمی گفته می‌شود همین مقدار را با php_value max_execution_time 300 در .htaccess بگذارید. این دستور را فقط دو حالت می‌فهمند: PHP به‌صورت ماژول Apache (mod_php)، و وب‌سرور LiteSpeed/OpenLiteSpeed که عمداً همین دستورهای Apache را پشتیبانی می‌کند. اما روی سرورهایی که PHP را با PHP-FPM یا CGI/FastCGI اجرا می‌کنند — یعنی حالت رایج امروز — این خط ناشناخته است و خودش باعث خطای ۵۰۰ می‌شود. برای محدودیت حجم آپلود هم رفع خطای upload_max_filesize را ببینید.

خطاهای آدرس، SSL و ورود

Too many redirects

علت: ناهماهنگی بین آدرس سایت در تنظیمات وردپرس و آنچه سرور یا CDN تحویل می‌دهد؛ مثلاً یکی www دارد و دیگری ندارد، یا یکی http است و دیگری https.

راه‌حل: در بخش «همگانی» از منوی تنظیمات، مقدار «نشانی وردپرس» و «نشانی سایت» را یکسان و با پروتکل درست وارد کنید. اگر به پیشخوان دسترسی ندارید، این دو خط را موقتاً در wp-config.php بگذارید (به‌جای example.com دامنه خودتان را بنویسید):

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

بعد این موارد را هم بررسی کنید:

• اگر از کلودفلر استفاده می‌کنید، حالت SSL را از Flexible به Full یا Full (strict) تغییر دهید. حالت Flexible در کنار ریدایرکت https سایت، کلاسیک‌ترین علت حلقه بی‌نهایت ریدایرکت است.
• قواعد ریدایرکت تکراری در .htaccess و افزونه‌های ریدایرکت/سئو را بررسی کنید؛ اغلب دو قاعده هم‌زمان یک کار را انجام می‌دهند.
• در پایان، کش مرورگر، کش افزونه و کش CDN را پاک کنید.

Mixed Content (قفل سبز نمایش داده نمی‌شود)

علت: صفحه با https باز می‌شود اما بعضی تصویرها، فایل‌های CSS یا جاوااسکریپت هنوز آدرس http دارند. مرورگرها این فایل‌ها را یا بلاک می‌کنند یا هشدار می‌دهند و قفل امنیتی را نشان نمی‌دهند.

راه‌حل: ریشه‌ای‌ترین راه، اصلاح آدرس‌ها در خود دیتابیس است. اگر به SSH و WP-CLI دسترسی دارید و حتماً از قبل بکاپ دیتابیس گرفته‌اید، اول با --dry-run ببینید قرار است چند مورد عوض شود و بعد بدون آن اجرا کنید. هر دو دستور را از مسیر اصلی وردپرس اجرا کنید:

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

--skip-columns=guid را حذف نکنید؛ ستون guid شناسه ثابت مطالب در فیدهاست و دست زدن به آن می‌تواند باعث شود خوانندگان فید همه مطالب را دوباره «جدید» ببینند.

اگر دسترسی SSH ندارید، افزونه‌هایی مثل Really Simple SSL همین کار را در لحظه انجام می‌دهند و برای رفع سریع مشکل خوب‌اند؛ اما توجه داشته باشید که این افزونه‌ها آدرس‌های داخل دیتابیس را اصلاح نمی‌کنند بلکه خروجی را هنگام نمایش بازنویسی می‌کنند، پس هم کمی بار اضافه دارند و هم اگر روزی غیرفعالشان کنید مشکل برمی‌گردد. برای پیدا کردن منبع دقیق فایل http، در مرورگر با کلید F12 به کنسول بروید؛ آدرس فایل مشکل‌دار همان‌جا نوشته شده است.

Secure connection failed

علت: گواهی SSL نصب نشده، منقضی شده، برای دامنه دیگری صادر شده، یا نسخه www دامنه را پوشش نمی‌دهد.

راه‌حل: در بخش SSL/TLS هاست وضعیت و تاریخ انقضای گواهی را ببینید و در صورت نیاز آن را تمدید یا از طریق AutoSSL دوباره صادر کنید. مطمئن شوید گواهی هم example.com و هم www.example.com را پوشش می‌دهد و رکورد DNS دامنه واقعاً به همین سرور اشاره می‌کند.

صفحه ورود مدام رفرش می‌شود

علت: نام کاربری و رمز درست است اما وردپرس دوباره صفحه ورود را نشان می‌دهد؛ معمولاً کوکی درست ست نمی‌شود، آدرس سایت با آدرسی که در مرورگر باز کرده‌اید یکی نیست (www در برابر بدون www)، یا افزونه‌ی کش/امنیتی مسیر ورود را دستکاری کرده است.

راه‌حل: کوکی‌ها و کش مرورگر را پاک کنید، دقیقاً همان آدرسی را باز کنید که در تنظیمات وردپرس ثبت شده، افزونه‌های کش و امنیتی را موقتاً غیرفعال کنید و کش افزونه را خالی کنید. اگر افزونه‌ای یا تنظیمات چنددامنه‌ای مقدار COOKIE_DOMAIN را اشتباه ست کرده باشد، بازگرداندن آن به مقدار پیش‌فرض مشکل را حل می‌کند:

define( 'COOKIE_DOMAIN', false );

The response is not a valid JSON response

علت: ویرایشگر نمی‌تواند پاسخ درستی از REST API بگیرد؛ معمولاً به دلیل ناهماهنگی آدرس سایت (http/https یا www)، خراب بودن قواعد بازنویسی در .htaccess، یا بلاک شدن مسیر /wp-json/ توسط افزونه امنیتی یا ModSecurity.

راه‌حل: اول در بخش «پیوندهای یکتا» از منوی تنظیمات فقط دکمه ذخیره را بزنید تا قواعد بازنویسی از نو ساخته شوند. بعد آدرس سایت را در تنظیمات همگانی چک کنید. سپس در ابزارها و بخش «سلامت سایت»، وضعیت REST API را ببینید؛ اگر آنجا خطا گزارش شده بود، افزونه‌های امنیتی و فایروال را یکی‌یکی غیرفعال کنید تا مقصر پیدا شود.

چک‌لیست عیب‌یابی که در بیشتر موارد جواب می‌دهد

• قبل از هر تغییر بکاپ بگیرید.
• نمایش خطا را روشن کنید و ارور لاگ سرور را بخوانید؛ حدس زدن وقت تلف کردن است.
• افزونه‌ها را غیرفعال و قالب پیش‌فرض را فعال کنید، بعد یکی‌یکی برگردانید تا مقصر مشخص شود. ابزار «سلامت سایت» وردپرس (منوی ابزارها) و افزونه Health Check & Troubleshooting همین کار را بدون تأثیر روی بازدیدکنندگان انجام می‌دهند.
• سطح دسترسی‌ها را استاندارد نگه دارید: ۷۵۵ برای پوشه‌ها، ۶۴۴ برای فایل‌ها، و هرگز ۷۷۷٫
• نسخه PHP را روی یک نسخه پشتیبانی‌شده و سازگار با قالب و افزونه‌هایتان نگه دارید و قبل از تغییر نسخه روی سایت اصلی، آن را روی یک نسخه آزمایشی امتحان کنید.
• بعد از هر تغییر، کش افزونه، کش سرور و کش CDN را پاک کنید؛ در غیر این صورت ممکن است فکر کنید راه‌حل جواب نداده.

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