راهنمای جامع خطاهای وردپرس

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

در این راهنما، بیش از ۴۰ مورد از خطاهای وردپرس بر اساس نوع مشکل بررسی می‌شوند؛ از خطاهای HTTP و اتصال پایگاه داده گرفته تا مشکلات PHP، ویرایشگر گوتنبرگ، REST API، بارگذاری تصاویر و به‌روزرسانی‌ها. برای هر خطا، نشانه‌ها، علت‌های احتمالی و روش‌های عملی رفع مشکل نیز توضیح داده می‌شوند. این راهنما هم برای مدیران سایت‌های وردپرسی و هم برای توسعه‌دهندگانی نوشته شده است که می‌خواهند به‌جای آزمون‌وخطای بی‌هدف، از روش اصولی عیب‌یابی استفاده کنند.

پیش از رفع خطاهای وردپرس

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

۱) از فایل‌ها و پایگاه داده نسخه پشتیبان بگیرید

بکاپ باید شامل فایل‌های وردپرس، پوشه wp-content، پایگاه داده و تنظیمات مهم سرور باشد. قبل از تغییرات پرخطر، مطمئن شوید که امکان بازیابی نسخه پشتیبان وجود دارد. برای سایت‌های فروشگاهی، صرفاً داشتن بکاپ کافی نیست. بازیابی پایگاه داده ممکن است سفارش‌ها، پرداخت‌ها یا اطلاعات مشتریانی را که پس از زمان تهیه بکاپ ثبت شده‌اند، از بین ببرد.

۲) آخرین تغییرات سایت را بررسی کنید

• آیا هسته وردپرس، افزونه یا پوسته‌ای به‌روزرسانی شده است؟
• آیا نسخه PHP یا تنظیمات هاست تغییر کرده است؟
• آیا کد جدیدی به پوسته یا افزونه اختصاصی اضافه شده است؟
• آیا سایت به دامنه یا سرور دیگری منتقل شده است؟
• آیا تنظیمات CDN، فایروال یا SSL تغییر کرده‌اند؟

این اطلاعات معمولاً محدوده جستجو را بسیار کوچک‌تر می‌کنند.

۳) ابزار سلامت سایت را بررسی کنید

در پیشخوان وردپرس، به مسیر ابزارها ← سلامت سایت مراجعه کنید. این بخش می‌تواند مشکلاتی مانند قدیمی‌بودن PHP، خطاهای REST API، درخواست‌های Loopback، ماژول‌های ضروری PHP و برخی مشکلات زمان‌بندی را شناسایی کند.

۴) لاگ خطا را فعال کنید

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

/* That's all, stop editing! Happy publishing. */

خطوط زیر را قبل از عبارت بالا قرار دهید:

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

اگر این ثابت‌ها از قبل تعریف شده‌اند، مقادیر همان‌ها را اصلاح کنید؛ آن‌ها را دوباره تعریف نکنید. با این تنظیمات، پیام‌های قابل ثبت در فایل wp-content/debug.log ذخیره می‌شوند. این فایل می‌تواند اطلاعات مهمی مانند مسیر فایل خطادار، شماره خط، خطاهای PHP و Stack Trace را در اختیار شما قرار دهد.

جدول عیب‌یابی سریع خطاهای وردپرس

جدول زیر برای زمانی مناسب است که می‌خواهید بر اساس پیام خطا، اولین محل بررسی را پیدا کنید.

این موارد تنها علت‌های احتمالی هستند؛ تشخیص قطعی باید بر اساس لاگ‌ها و شرایط همان سایت انجام شود!

گروه ۱: خطاهای HTTP و ارتباط با سرور

۱) خطای ۵۰۰ وردپرس

خطای ۵۰۰ یا Internal Server Error نشان می‌دهد که سرور هنگام پردازش درخواست با مشکلی غیرمنتظره مواجه شده است. این کد به‌تنهایی مشخص نمی‌کند که مشکل از وردپرس، PHP، وب‌سرور یا افزونه‌هاست.

دلایل احتمالی: خطای Fatal در افزونه یا قالب، دستور نامعتبر در فایل .htaccess، محدودیت حافظه یا منابع PHP، خطاهای پیکربندی آپاچی یا nginx یا مشکلات دسترسی به فایل‌ها می‌توانند از دلایل احتمالی بروز خطای 500 باشند.

روش رفع خطا: ابتدا لاگ PHP و وب‌سرور را بررسی کنید. اگر هاست شما از وب‌سرور آپاچی استفاده می‌کند، نام فایل .htaccess را موقتاً به .htaccess-backup تغییر دهید. اگر مشکل برطرف شد، تنظیمات Rewrite را بررسی کرده و از مسیر تنظیمات ← پیوندهای یکتا، قوانین را دوباره ذخیره کنید.

در مرحله بعد، افزونه‌ها را به‌صورت کنترل‌شده غیرفعال کنید و پوسته پیش‌فرضی را که با نسخه فعلی وردپرس سازگار است، آزمایش کنید. اگر مشکل همچنان باقی بود، لاگ سرور را برای خطاهای PHP-FPM، محدودیت منابع یا مشکلات پیکربندی بررسی کنید.

توجه داشته باشید که فایل .htaccess در پیکربندی معمول nginx برای قوانین Rewrite استفاده نمی‌شود.

۲) خطای ۴۰۳ وردپرس

کد ۴۰۳ یا Forbidden به این معناست که سرور درخواست را دریافت و پردازش کرده، اما دسترسی به منبع را مجاز نمی‌داند. این مشکل ممکن است هنگام ورود به پیشخوان، مشاهده پوشه‌ها، استفاده از REST API یا حتی بازکردن صفحه اصلی دیده شود.

دلایل احتمالی: تنظیمات اشتباه مجوز فایل‌ها، قوانین امنیتی وب‌سرور، مسدودشدن IP توسط فایروال سرور، محدودیت افزونه امنیتی یا قوانین اشتباه .htaccess می‌توانند از دلایل احتمالی بروز این خطا باشند.

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

• دسترسی پوشه‌ها: 755
• دسترسی فایل‌ها: 644

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

۳) خطای ۴۰۴ وردپرس

یکی از رایج‌ترین سناریوها این است که صفحه اصلی سایت باز می‌شود، اما نوشته‌ها، برگه‌ها یا آدرس‌های سفارشی با خطای ۴۰۴ یا Not Found مواجه می‌شوند. این وضعیت اغلب به تنظیمات پیوندهای یکتا و قوانین Rewrite مربوط است.

روش رفع خطا:

1. وارد تنظیمات ← پیوندهای یکتا شوید.
2. بدون تغییر ساختار پیوندها، روی «ذخیره تغییرات» کلیک کنید.
3. اگر مشکل ادامه داشت، قوانین Rewrite سرور را بررسی کنید.
4. اگر مشکل فقط برای یک نوع نوشته سفارشی رخ می‌دهد، تداخل نامک و ثبت درست Rewrite در کد را بررسی کنید.

در توسعه افزونه‌ها نیز باید پس از ثبت یا تغییر قوانین مربوط به نوع نوشته سفارشی (Custom Post Type)، عملیات Flush Rewrite Rules به‌شکل مناسب انجام شود؛ نه در هر درخواست سایت.

۴) خطاهای ۵۰۲ و ۵۰۴ وردپرس

این دو خطا معمولاً در معماری‌هایی دیده می‌شوند که یک وب‌سرور یا پروکسی، درخواست‌ها را به سرویس دیگری مانند PHP-FPM ارسال می‌کند. خطای 502 Bad Gateway معمولاً نشان‌دهنده دریافت پاسخ نامعتبر از سرویس بالادستی است؛ درحالی‌که خطای 504 Gateway Timeout یعنی Gateway نتوانسته در زمان مقرر پاسخ بگیرد.

دلایل احتمالی شامل از کار افتادن PHP-FPM، اشباع ورکرها، اجرای کوئری‌های طولانی، مشکلات شبکه داخلی و محدودیت تایم‌اوت درخواست‌ها است.

روش رفع خطا: برای عیب‌یابی، وضعیت PHP-FPM، لاگ وب‌سرور، مدت اجرای درخواست‌ها و مصرف CPU و رم را بررسی کنید. اگر خطا پس از اجرای فرایند سنگین یک افزونه اتفاق می‌افتد، ابتدا همان فرایند را بررسی کنید. افزایش بی‌هدف تایم‌اوت ممکن است فقط مشکل اصلی را پنهان کند.

۵) خطای ۵۰۳ وردپرس

خطای ۵۰۳ یا Service Unavailable یعنی سرویس در حال حاضر توانایی پاسخ‌گویی به درخواست را ندارد. این پیام می‌تواند در زمان نگهداری سایت، افزایش ناگهانی ترافیک، محدودیت منابع، اختلال در سرویس بک‌اند یا تنظیمات زیرساخت نمایش داده شود.

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

۶) خطای ۴۲۹ وردپرس

خطای ۴۲۹ یا Too Many Requests نشان می‌دهد که در بازه زمانی مشخص، تعداد درخواست‌ها از محدودیت اعمال‌شده عبور کرده است. در وردپرس ممکن است هنگام ورودهای مکرر، استفاده از API، اجرای خزنده‌ها یا ارسال درخواست‌های پرتعداد توسط افزونه‌ها رخ دهد.

روش رفع خطا: راهکار مناسب، شناسایی منبع محدودکننده نرخ است؛ مثلاً CDN، وب‌سرور، افزونه امنیتی یا سرویس API. اگر پاسخ دارای هدر Retry-After است، کلاینت باید مطابق آن رفتار کند. غیرفعال‌کردن کامل محدودیت امنیتی معمولاً راهکار مناسبی نیست. بهتر است قوانین برای درخواست‌های معتبر اصلاح شوند.

۷) خطای ERR_TOO_MANY_REDIRECTS

این خطا زمانی ظاهر می‌شود که مرورگر وارد حلقه تغییر مسیر (redirect loop) شود. برای مثال، یک لایه درخواست را از HTTP به HTTPS هدایت می‌کند و لایه دیگری آن را دوباره به HTTP برمی‌گرداند.

دلایل احتمالی: ناهماهنگی بین home و siteurl در تنظیمات سایت، تنظیم اشتباه SSL در CDN، افزونه‌های ریدایرکت و قوانین متناقض وب‌سرور.

روش رفع خطا: مسیر ریدایرکت را در تب Network مرورگر یا با ابزار curl بررسی کنید، سپس تنظیمات URL وردپرس و قوانین HTTP/HTTPS را هماهنگ کنید.

curl -IL https://example.com

این دستور پاسخ‌ها و هدرهای HTTP را در طول ریدایرکت‌ها نمایش می‌دهد. در صورت مشاهده حلقه یا محدودیت تعداد ریدایرکت‌ها، هدرهای Location را بررسی کنید.

گروه ۲: خطاهای پایگاه داده وردپرس

۸) خطای اتصال به پایگاه داده

خطای «خطا در برقراری ارتباط با پایگاه‌داده» زمانی نمایش داده می‌شود که وردپرس نتواند اتصال موردنیاز به پایگاه داده MySQL یا MariaDB را برقرار کند. از آنجا که نوشته‌ها، تنظیمات و بسیاری از داده‌های سایت در پایگاه داده قرار دارند، اختلال در اتصال می‌تواند کل سایت را از دسترس خارج کند.

دلایل احتمالی: اشتباه بودن نام پایگاه داده یا اطلاعات کاربری آن، عوض شدن رمز عبور دیتابیس، متوقف‌شدن سرویس MySQL/MariaDB، اشتباه بودن آدرس یا پورت سرور دیتابیس، محدودیت تعداد اتصال‌ها یا منابع سرور و یا مشکلات شبکه میان وب‌سرور و دیتابیس از مهم‌ترین دلایل نمایش این خطا هستند.

مراحل رفع خطا: فایل wp-config.php را بررسی کنید:

define('DB_NAME', 'database_name');
define('DB_USER', 'database_user');
define('DB_PASSWORD', 'database_password');
define('DB_HOST', 'localhost');

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

۹) خطای خرابی جدول‌های دیتابیس

گاهی اتصال برقرار می‌شود، اما یک یا چند جدول قابل خواندن نیستند یا هنگام اجرای کوئری خطایی مانند زیر مشاهده می‌شود:

Table is marked as crashed، Table doesn't exist یا Unknown column

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

مراحل رفع خطا: ابتدا از پایگاه داده بکاپ بگیرید. سپس با ابزارهایی مانند phpMyAdmin ساختار و وضعیت جدول را بررسی کنید. در صورت وجود خرابی قابل تعمیر و پشتیبانی موتور ذخیره‌سازی از عملیات تعمیر، می‌توان از ابزار مناسب آن موتور استفاده کرد. برای مثال، REPAIR TABLE راهکار عمومی تعمیر جدول‌های InnoDB نیست.

اگر جدول یا ستون واقعاً وجود ندارد، باید فرایند ایجاد یا مهاجرت Schema بررسی شود؛ نه اینکه صرفاً عملیات تعمیر اجرا شود.

گروه ۳: خطاهای بحرانی PHP

۱۰) خطای «یک خطای مهم در این وبسایت رخ داده است»

این پیام معمولاً زمانی ظاهر می‌شود که وردپرس با خطای بحرانی PHP مواجه شده و نمی‌تواند درخواست را به شکل عادی ادامه دهد. وردپرس دارای سازوکار Recovery Mode است که در برخی شرایط به مدیر سایت امکان می‌دهد مشکل ایجادشده توسط افزونه یا پوسته را شناسایی و کنترل کند.

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

روش رفع خطا:

1. ایمیل مدیر سایت را برای پیام Recovery Mode بررسی کنید.
2. اگر لینک بازیابی دریافت کرده‌اید، از آن برای ورود و غیرفعال‌کردن افزونه یا پوسته مشکل‌ساز استفاده کنید.
3. در غیر این صورت، فایل debug.log و لاگ PHP سرور را بررسی کنید.
4. نام فایل، شماره خط و Stack Trace را پیدا کنید.
5. مشکل را با اصلاح کد، نصب نسخه سازگار یا بازگرداندن آخرین تغییرات حل کنید.

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

۱۱) صفحه سفید مرگ وردپرس

در این حالت، سایت یا پیشخوان تنها یک صفحه سفید نمایش می‌دهد و ظاهراً هیچ پیغام خطایی وجود ندارد. به همین علت، آن را صفحه سفید مرگ یا White Screen of Death می‌نامند. ممکن است یک خطای PHP، قطع فرایند اجرا، تداخل افزونه یا مشکل پوسته باعث WSOD شود.

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

۱۲) خطای Allowed Memory Size Exhausted

این خطا نشان می‌دهد که فرایند PHP تلاش کرده بیشتر از سقف حافظه مجاز استفاده کند. برای نمونه ممکن است پیغام زیر نمایش داده شود:

Fatal error: Allowed memory size of 134217728 bytes exhausted

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

در صورت مناسب‌بودن منابع هاست، می‌توان تنظیم زیر را در wp-config.php آزمایش کرد:

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

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

۱۳) خطای Maximum Execution Time Exceeded

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

اگر علت، پردازش سنگین و معتبر است، ممکن است افزایش محدودیت max_execution_time از طریق تنظیمات PHP مفید باشد؛ البته این مقدار می‌تواند توسط هاست کنترل شود.

برای کارهای واقعاً سنگین، روش مناسب‌تر معمولاً تقسیم پردازش به گروه‌های کوچک یا استفاده از صف وظایف است.

۱۴) خطای PHP Parse Error یا Syntax Error

خطای سینتکسی وقتی ایجاد می‌شود که مفسر PHP نتواند کد را تجزیه کند. برای مثال:

<?php
$message = 'Hello'
echo $message;

در این کد، بعد از انتساب مقدار به متغیر، علامت ; فراموش شده است. نمونه درست:

<?php
$message = 'Hello';
echo $message;

اگر این خطا پس از ویرایش فایل functions.php یا کد افزونه ظاهر شد، شماره خط اعلام‌شده را همراه با خطوط قبل از آن بررسی کنید. برای بررسی سینتکس یک فایل می‌توانید از دستور زیر استفاده کنید:

php -l path/to/file.php

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

۱۵. خطای Call to Undefined Function

خطای Call to Undefined Function یا Undefined Method معمولاً به این معناست که کد می‌خواهد تابع یا متدی را اجرا کند که در آن شرایط در دسترس نیست. دلایل احتمالی عبارتند از بارگذاری‌نشدن فایل وابسته، اشتباه تایپی در نام تابع، ناسازگاری نسخه‌ها یا اجرای کد پیش از آماده‌شدن وابستگی‌ها.

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

۱۶) خطای Headers Already Sent

معمولاً هنگامی که قبل از اجرای دستورهایی مانند header()، setcookie() یا wp_redirect() خروجی به مرورگر ارسال شده باشد با پیغام زیر مواجه می‌شوید:

Cannot modify header information - headers already sent

وجود فاصله یا BOM در ابتدای فایل PHP، استفاده زودهنگام از echo یا خروجی ناخواسته یک افزونه از علت‌های احتمالی هستند.

در فایل‌های PHP که فقط کد PHP دارند، بهتر است تگ پایانی ?> حذف شود تا از ایجاد خروجی تصادفی جلوگیری شود. همچنین مسیر و شماره خطی را که در پیغام «output started at» آمده است بررسی کنید؛ چون محل مشاهده اخطار الزاماً محل ایجاد خروجی اولیه نیست.

گروه ۴: خطاهای ورود و مدیریت وردپرس

۱۷) مشکل ورود به پیشخوان وردپرس

گاهی صفحه ورود باز می‌شود، اما پس از وارد کردن اطلاعات صحیح دوباره به همان صفحه برمی‌گردد. در بعضی موارد نیز کاربر با خطای ۴۰۳ یا پیغام نامعتبر بودن نشست مواجه می‌شود. علت‌های احتمالی شامل مشکلات کوکی، تنظیمات اشتباه URL سایت، ناسازگاری افزونه‌های امنیتی یا کش‌شدن صفحه ورود است.

برای عیب‌یابی، ابتدا ورود در مرورگر ناشناس (incognito) را آزمایش کنید. سپس کوکی‌های مربوط به دامنه را پاک کنید و مطمئن شوید آدرس سایت و وردپرس به‌درستی تنظیم شده‌اند. اگر فقط یک کاربر با مشکل مواجه است، وضعیت همان حساب، نقش کاربری و محدودیت‌های امنیتی را بررسی کنید. اما اگر هیچ مدیری نمی‌تواند وارد شود، احتمال مشکل در تنظیمات عمومی سایت بیشتر است.

۱۸) خطای «آیا مطمئن هستید؟»

وردپرس ممکن است در برخی عملیات مدیریتی، پیام «از انجام این کار مطمئن هستید؟» را نمایش دهد. این پیام در بسیاری از موارد با اعتبارسنجی امنیتی درخواست یا Nonce مرتبط است، اما به‌تنهایی علت دقیق مشکل را مشخص نمی‌کند.

دلایل احتمالی: منقضی‌شدن Nonce، کش‌شدن صفحه مدیریت، کدنویسی نادرست فرم یا تغییر نشست کاربر.

برای رفع مشکل، صفحه را مجدداً بارگذاری کنید و عملیات را دوباره انجام دهید. اگر مشکل در یک افزونه اختصاصی رخ می‌دهد، ایجاد Nonce با wp_nonce_field() و بررسی آن با توابع مناسب مانند check_admin_referer() را بررسی کنید. دقت کنید که Nonce جایگزین بررسی سطح دسترسی نیست. در عملیات حساس، اعتبارسنجی قابلیت کاربر با current_user_can() نیز ضروری است.

۱۹) خطای ۴۰۳ یا عدم دسترسی به wp-admin

اگر صفحه عمومی سایت درست کار می‌کند اما wp-admin مسدود شده است، احتمال دارد مشکل به قوانین امنیتی یا تنظیمات دسترسی مربوط باشد. لاگ فایروال، قوانین محدودکننده IP، تنظیمات CDN و افزونه‌های امنیتی را بررسی کنید.

اگر مشکل بلافاصله پس از نصب افزونه امنیتی شروع شده است، آن افزونه یکی از نخستین مواردی است که باید بررسی شود. البته غیرفعال‌کردن دائمی لایه امنیتی راهکار مناسبی نیست!

گروه ۵: خطاهای گوتنبرگ و REST API

۲۰) خطای به‌روزرسانی ناموفق یا انتشار ناموفق

یکی از مشکلات شناخته‌شده هنگام ذخیره یا انتشار نوشته در ویرایشگر بلوکی وردپرس، نمایش پیام «به‌روزرسانی ناموفق بود. پاسخ یک پاسخ JSON معتبر نیست.» یا «انتشار ناموفق بود. پاسخ یک پاسخ JSON معتبر نیست.» است.

ادیتور گوتنبرگ برای بسیاری از عملیات خود از REST API استفاده می‌کند. اگر درخواست با پاسخ غیرمنتظره مواجه شود، فرایند ذخیره یا انتشار محتوا ممکن است شکست بخورد.

دلایل احتمالی: خطای PHP که خروجی پاسخ API را تغییر داده است، مسدودشدن درخواست توسط فایروال، تنظیمات اشتباه پیوندهای یکتا، مشکلات SSL یا تغییر مسیر، ناسازگاری افزونه‌ها و اختلال در احراز هویت یا اعتبارسنجی REST API می‌توانند از مهم‌ترین دلایل بروز این خطا باشند.

مراحل رفع خطا:

1. ابزار Developer Tools مرورگر را باز کنید.
2. به تب Network بروید و عملیات ذخیره نوشته را تکرار کنید.
3. درخواست ناموفق مربوط به /wp-json/ را پیدا کنید.
4. کد وضعیت HTTP و محتوای Response را بررسی کنید.
5. اگر به‌جای JSON یک صفحه HTML، خطای PHP یا صفحه امنیتی دریافت شده است، منشأ آن را پیدا کنید.

برای آزمایش اولیه در دسترس‌بودن REST API، آدرس https://example.com/wp-json/ را در مرورگر خود باز کنید. این آزمایش تنها نشان می‌دهد مسیر پایه API چه پاسخی برمی‌گرداند؛ موفق‌بودن آن تضمین نمی‌کند که درخواست‌های احراز هویت‌شده ادیتور نیز درست کار کنند.

۲۱) خطای REST API Encountered an Error

این هشدار معمولاً در بخش سلامت سایت نمایش داده می‌شود. REST API برای ارتباط بخش‌های مختلف وردپرس، از جمله ویرایشگر بلوکی و برخی افزونه‌ها، نقش مهمی دارد. برای تشخیص علت، ابتدا جزئیات خطای سلامت سایت را مطالعه کنید. وضعیت پاسخ ممکن است ۴۰۱، ۴۰۳، ۴۰۴، ۵۰۰ یا تایم‌اوت باشد و هرکدام مسیر متفاوتی برای عیب‌یابی دارند.

اگر خطا ۴۰۳ است، محدودیت‌های امنیتی را بررسی کنید. اگر پاسخ ۵۰۰ است، به سراغ لاگ PHP بروید. اگر درخواست تایم‌اوت می‌شود، وضعیت شبکه و زمان پاسخ‌گویی سرور را بررسی کنید.

۲۲) خطای درخواست Loopback در وردپرس

پیام «Your site could not complete a loopback request» هنگامی مشاهده می‌شود که وردپرس نتواند یک درخواست داخلی مورد انتظار را با موفقیت انجام دهد. درخواست Loopback زمانی اتفاق می‌افتد که خود سرور به یکی از آدرس‌های سایت درخواست HTTP ارسال می‌کند. وردپرس از این سازوکار در برخی فعالیت‌های زمان‌بندی‌شده و بررسی‌های داخلی استفاده می‌کند.

دلایل احتمالی: محدودیت اتصال خروجی سرور، مشکل DNS، تنظیمات فایروال، خطای گواهی SSL، اختلال در احراز هویت یا تایم‌اوت شدن درخواست.

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

گروه ۶: خطاهای آپلود تصاویر و فایل‌ها

۲۳) خطای HTTP هنگام آپلود تصویر

گاهی وردپرس در کتابخانه رسانه هنگام بارگذاری تصویر فقط پیام «HTTP Error» را نمایش می‌دهد. این خطا پیام عمومی است و می‌تواند علت‌های متفاوتی داشته باشد. از مهم‌ترین علت‌ها می‌توان به محدودیت حافظه PHP، پردازش ناموفق تصویر، کمبود فضای دیسک، سطح دسترسی اشتباه و محدودیت فایروال اشاره کرد.

راهکار پیشنهادی: ابتدا یک تصویر کوچک‌تر با فرمت JPEG یا PNG آپلود کنید. اگر این تصویر موفقیت‌آمیز بود، اندازه و پیچیدگی پردازش فایل اصلی را بررسی کنید. در ادامه، وضعیت کتابخانه‌های پردازش تصویر مانند GD یا Imagick و لاگ سرور را بررسی کنید. برای فایل‌هایی با ابعاد بسیار بزرگ، تغییر اندازه تصویر پیش از بارگذاری ممکن است فشار حافظه و پردازش را کاهش دهد.

۲۴) خطای Exceeds the Maximum Upload Size

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

• upload_max_filesize: حداکثر اندازه یک فایل آپلودی
• post_max_size: حداکثر اندازه داده‌های ارسال‌شده با درخواست POST

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

upload_max_filesize = 64M
post_max_size = 80M

این کد مربوط به پیکربندی PHP است و نباید مستقیماً در فایل wp-config.php قرار بگیرد! ممکن است لازم باشد تنظیمات وب‌سرور یا محدودیت‌های هاست نیز اصلاح شوند. در nginx، محدودیت client_max_body_size هم می‌تواند مانع آپلود فایل شود.

۲۵) خطای Unable to Create Directory

پیام «امکان ایجاد شاخه wp-content/uploads/... نیست.» اغلب نشان‌دهنده مشکل در ایجاد پوشه یا نوشتن اطلاعات در مسیر مقصد است.

دلایل احتمالی: دسترسی نامناسب پوشه، مالکیت اشتباه فایل‌ها، پرشدن فضای ذخیره‌سازی یا تنظیم نادرست مسیر آپلود.

ابتدا بررسی کنید که پوشه wp-content/uploads وجود دارد و فرایند PHP مجوز لازم برای نوشتن در آن را دارد. اگر مشکل بعد از مهاجرت سایت اتفاق افتاده است، مسیر آپلود و مالکیت پوشه‌ها را با دقت بیشتری بررسی کنید. از دادن مجوز عمومی 777 برای رفع این مشکل خودداری کنید.

۲۶) خطای Missing a Temporary Folder

PHP معمولاً فایل‌های ارسالی را پیش از انتقال به مقصد نهایی، به‌صورت موقت ذخیره می‌کند. اگر مسیر موقت نامعتبر باشد یا وجود نداشته باشد یا دسترسی نوشتن به آن ممکن نباشد، ممکن است خطای «نوشتن درخواست در پروندهٔ موقتی شکست خورد.» یا «Missing a temporary folder» نمایش داده شود.

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

۲۷) خطای Failed to Write File to Disk

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

گروه ۷: خطاهای نصب و به‌روزرسانی وردپرس

۲۸) خطای حالت نگهداری

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

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

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

۲۹) خطای Installation Failed

خطای «Installation Failed: Could Not Create Directory» هنگام نصب قالب یا افزونه دیده می‌شود و معمولاً به ناتوانی وردپرس در ایجاد پوشه در مسیر مقصد مربوط است. برای مثال، ممکن است وردپرس نتواند پوشه جدیدی داخل wp-content/plugins ایجاد کند. مهم‌ترین موارد قابل بررسی عبارت‌اند از مجوز نوشتن، مالکیت فایل‌ها، فضای دیسک، محدودیت هاست و تنظیمات دسترسی به فایل‌سیستم. اگر مشکل پس از انتقال سایت به هاست جدید شروع شده است، مالکیت فایل‌ها را در اولویت قرار دهید.

۳۰) خطا در دانلود یا آپلود

گاهی وردپرس نمی‌تواند بسته به‌روزرسانی قالب، افزونه یا هسته را دانلود یا نصب کند. در این مواقع ممکن است خطایی به صورت Download Failed یا Update Failed نمایش دهد.

دلایل احتمالی: اختلال DNS، محدودیت درخواست‌های خروجی، خطای SSL، کمبود فضای دیسک، مشکل مجوز فایل‌ها یا در دسترس نبودن موقت سرور مقصد.

جزئیات پیام خطا اهمیت زیادی دارند. برای مثال، خطای cURL error 28 معمولاً به تایم‌اوت اشاره می‌کند، اما cURL error 60 اغلب به مشکل اعتبارسنجی گواهی SSL مربوط است. برای مشکل SSL، تنظیم درست CA Certificate و پیکربندی PHP/cURL را بررسی کنید. غیرفعال‌کردن دائمی اعتبارسنجی SSL یک راهکار امن نیست.

۳۱) خطای Destination Folder Already Exists

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

۳۲) خطای Another Update Is Currently in Progress

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

برای عیب‌یابی پیشرفته می‌توان وضعیت قفل core_updater.lock را بررسی کرد. حذف دستی آن فقط زمانی مناسب است که مطمئن باشید هیچ به‌روزرسانی فعالی وجود ندارد.

گروه ۸: خطاهای SSL، ایمیل و کران جاب

۳۳) خطای Mixed Content بعد از فعال‌سازی HTTPS

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

برای رفع مشکل، در کنسول مرورگر نشانی منابع ناامن را پیدا کنید. سپس URLهای هاردکدشده در قالب، افزونه یا محتوای پایگاه داده را اصلاح کنید. در مهاجرت از HTTP به HTTPS، برای جایگزینی گسترده URLها از ابزارهایی استفاده کنید که داده‌های Serialized وردپرس را به‌درستی مدیریت می‌کنند.

۳۴) خطای گواهی SSL

پیغام‌هایی مانند NET::ERR_CERT_AUTHORITY_INVALID یا ERR_CERT_COMMON_NAME_INVALID می‌توانند نشان‌دهنده مشکل در اعتبارسنجی گواهی باشند. دلایل احتمالی شامل منقضی‌شدن گواهی، عدم تطابق نام دامنه، ناقص‌بودن زنجیره گواهی یا تنظیم اشتباه CDN هستند.

برای رفع مشکل، وضعیت گواهی ارائه‌شده به مرورگر، دامنه‌های پوشش‌داده‌شده و تنظیمات TLS را بررسی کنید. توجه کنید که تنظیمات SSL میان بازدیدکننده و CDN با ارتباط SSL میان CDN و سرور مبدأ ممکن است متفاوت باشند.

۳۵) مشکل ارسال‌نشدن ایمیل‌های وردپرس

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

دلایل احتمالی: پیکربندی نامناسب سرویس ارسال ایمیل، محدودیت ارسال توسط هاست، خطای احراز هویت SMTP، تنظیم نادرست SPF، DKIM یا DMARC، قرارگرفتن ایمیل در پوشه اسپم و ردشدن پیام توسط سرور دریافت‌کننده از مهم‌ترین دلایل این سبک خطا هستند.

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

۳۶) خطای Missed Schedule در نوشته‌های زمان‌بندی‌شده

اگر نوشته‌ای را برای آینده زمان‌بندی کرده‌اید اما در موعد مقرر منتشر نشده، احتمال دارد سیستم زمان‌بندی وظایف وردپرس به‌درستی اجرا نشده باشد. وردپرس از WP-Cron استفاده می‌کند که در حالت پیش‌فرض به فراخوانی ناشی از درخواست‌های سایت وابسته است. در سایت‌های کم‌ترافیک یا محیط‌هایی که درخواست Loopback مسدود شده، اجرای وظایف ممکن است به تأخیر بیفتد.

برای سایت‌هایی که زمان‌بندی دقیق اهمیت دارد، می‌توان از کران واقعی سرور استفاده کرد؛ اما ابتدا باید از درست بودن تنظیمات، نبود خطای اجرایی و شیوه جلوگیری از اجرای تکراری وظایف مطمئن شد. برای بررسی وقایع ثبت‌شده نیز WP-CLI کاربرد دارد:

wp cron event list

۳۷) خطای cURL در وردپرس

وردپرس و افزونه‌ها برای ارتباط با APIها و سرویس‌های خارجی از لایه HTTP وردپرس استفاده می‌کنند که بسته به محیط می‌تواند از امکانات cURL بهره ببرد. برخی خطاهای متداول عبارت‌اند از:

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

گروه ۹: سایر مشکلات رایج وردپرس

۳۸) خطای Missing Stylesheet هنگام نصب پوسته

هنگام آپلود پوسته ممکن است با پیغام «این بسته نمی‌تواند نصب شود. پوسته، پرونده استایل style.css را کم دارد.» مواجه شوید. این خطا معمولاً زمانی رخ می‌دهد که فایل ZIP انتخاب‌شده ساختار مورد انتظار وردپرس را ندارد. برای مثال، بعضی پوسته‌های تجاری در یک بسته کامل عرضه می‌شوند که شامل مستندات، فایل‌های طراحی و نسخه قابل‌نصب پوسته است.

برای رفع مشکل، فایل ZIP مخصوص نصب پوسته را پیدا و بارگذاری کنید. اگر پوسته را توسعه داده‌اید، بررسی کنید که فایل style.css با هدر معتبر پوسته در مسیر مناسب قرار دارد.

۳۹) خطای This Site Can’t Be Reached

پیغام‌هایی مانند ERR_NAME_NOT_RESOLVED، ERR_CONNECTION_REFUSED یا ERR_CONNECTION_TIMED_OUT الزاماً خطاهای خود وردپرس نیستند. این مشکلات ممکن است پیش از آنکه درخواست به وردپرس برسد، در لایه DNS، شبکه، وب‌سرور یا فایروال اتفاق بیفتند.

برای رفع مشکل ابتدا وضعیت DNS دامنه، IP سرور، سرویس وب‌سرور، گواهی SSL و تنظیمات فایروال را بررسی کنید. اگر دامنه به سرور اشتباه اشاره کند، ویرایش فایل‌های وردپرس کمکی به حل مشکل نخواهد کرد.

۴۰) نمایش خطای ۴۰۴ پس از انتقال سایت

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

برای عیب‌یابی، تنظیمات home و siteurl، پیوندهای یکتا، پیکربندی وب‌سرور و آدرس‌های قدیمی باقی‌مانده را بررسی کنید. برای جایگزینی آدرس‌ها، ابزار WP-CLI امکان انجام عملیات سازگار با داده‌های Serialized را فراهم می‌کند:

wp search-replace \
  'https://old.example.com' \
  'https://new.example.com' \
  --all-tables-with-prefix \
  --dry-run

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

۴۱) خطاهای جاوا اسکریپت در پوسته و افزونه‌ها

برخی مشکلات وردپرس هیچ پیغام PHP مشخصی ندارند. مثلاً دکمه‌ای در پیشخوان کار نمی‌کند، پنجره تنظیمات باز نمی‌شود یا بلوک سفارشی گوتنبرگ درست نمایش داده نمی‌شود.

در این شرایط، کنسول مرورگر یکی از مهم‌ترین ابزارهای بررسی است. خطاهایی مانند Uncaught TypeError یا ReferenceError معمولاً به مشکلات کدنویسی جاوا اسکریپت، وابستگی‌های بارگذاری‌نشده یا دسترسی نامعتبر به متغیرها و اشیا اشاره دارند.

برای عیب‌یابی، ابتدا پیام کامل و Stack Trace را بررسی کنید. سپس فایل و افزونه مسئول خطا را شناسایی کنید. در محیط توسعه می‌توان از تنظیم زیر برای استفاده از نسخه‌های غیر Minified برخی فایل‌های هسته وردپرس بهره گرفت:

define('SCRIPT_DEBUG', true);

این گزینه جایگزین Source Map یا Build توسعه افزونه‌های اختصاصی نیست و پس از عیب‌یابی باید به تنظیم مناسب محیط بازگردانده شود.

عیب‌یابی حرفه‌ای وردپرس با WP-CLI

برای توسعه‌دهندگان و مدیرانی که به SSH دسترسی دارند، ابزار WP-CLI امکان بررسی بسیاری از مشکلات را بدون ورود به پیشخوان فراهم می‌کند. برای نمونه، فهرست افزونه‌های نصب‌شده را می‌توان با دستور زیر مشاهده کرد:

wp plugin list

اگر افزونه مشخصی باعث خطا شده است، می‌توانید پس از تهیه بکاپ و بررسی وابستگی‌ها آن را غیرفعال کنید:

wp plugin deactivate plugin-slug

برای بررسی صحت فایل‌های هسته وردپرس:

wp core verify-checksums

این دستور فایل‌های هسته را با Checksumهای رسمی وردپرس مقایسه می‌کند و می‌تواند در شناسایی فایل‌های تغییرکرده یا آسیب‌دیده کمک کند. البته تغییر فایل الزاماً به معنای آلوده‌بودن سایت نیست و نتیجه باید بررسی شود.

برای افزونه‌هایی که از مخزن رسمی وردپرس نصب شده‌اند نیز امکان بررسی Checksum وجود دارد:

wp plugin verify-checksums --all

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

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

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

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

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

پرسش‌های متداول

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

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

برای مطالعه عمیق‌تر و بررسی مستندات فنی، منابع رسمی وردپرس پیشنهاد می‌شود:

• مستندات رسمی وردپرس برای خطاهای رایج
• مستندات رسمی وردپرس برای ابزار سلامت سایت
• مستندات رسمی وردپرس برای عیب‌یابی وردپرس
• مستندات رسمی وردپرس برای تهیه نسخه پشتیبان