آموزش رفع خطای Critical Error و 500 در وردپرس؛ عیب‌یابی افزونه، قالب، PHP و ووکامرس

ارسال توسط Dev Source

24 مهر 1405

منتشرشده در 7 مرداد 1405

🗓 آخرین به‌روزرسانی: 24 مهر 1405

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

خطای Critical Error وردپرس یا پاسخ 500 Internal Server Error معمولاً به این معنی است که اجرای PHP، ارتباط دیتابیس، وب‌سرور یا یکی از اجزای WordPress قبل از تولید پاسخ کامل متوقف شده است. پیام روی صفحه فقط نشانه است؛ علت واقعی ممکن است یک افزونه ناسازگار، کد سفارشی، قالب، نسخه PHP، کمبود حافظه، فایل خراب، Rule اشتباه وب‌سرور یا خطای یک عملیات پس‌زمینه WooCommerce باشد.

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

در این راهنما، Recovery Mode، PHP Error Log، WP_DEBUG_LOG، تعارض افزونه و قالب، Memory Exhausted، خطای 500، خرابی .htaccess، فایل‌های هسته، دیتابیس، REST API، AJAX، WooCommerce Checkout، Action Scheduler و روش تست پس از رفع خطا را بررسی می‌کنیم.

وضعیت سایت فعلی: dev-source.ir روی WordPress 7.0.2، WooCommerce 10.9.4 و قالب WoodMart 8.3.7 اجرا می‌شود. LiteSpeed Cache، Rank Math و چند افزونه سفارشی محصول، PDF و Checkout نیز فعال‌اند. نسخه PHP و تنظیمات واقعی Error Log از اتصال فعلی قابل تأیید نیست. در این مقاله هیچ افزونه، قالب، Debug، Cache، فایل یا تنظیم عملیاتی سایت زنده تغییر نمی‌کند.

Critical Error، خطای 500 و صفحه سفید چه تفاوتی دارند؟

Critical Error

WordPress هنگامی که Fatal Error قابل مدیریت را در یک درخواست عادی تشخیص دهد، ممکن است پیام «یک خطای مهم در این وب‌سایت رخ داده است» نمایش دهد و جزئیات را به ایمیل مدیر ارسال کند. این پیام علت را مشخص نمی‌کند؛ فقط نشان می‌دهد اجرای برنامه متوقف شده است.

500 Internal Server Error

کد 500 یک پاسخ عمومی وب‌سرور است. ممکن است PHP Fatal Error، Rule خراب، Permission، Timeout، Module سرور یا خطای Application علت باشد. گاهی WordPress حتی فرصت نمایش صفحه Critical Error را پیدا نمی‌کند.

White Screen of Death

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

خطا فقط در بخشی از سایت

اگر فقط ویرایش محصول، Checkout، REST API یا یک صفحه خاص خطا دارد، افزونه یا کدی که فقط در همان Context اجرا می‌شود محتمل‌تر است. خطایی که تمام Frontend و Admin را از کار می‌اندازد معمولاً در Bootstrap عمومی سایت رخ می‌دهد.

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

قبل از هر تغییر این موارد را ثبت کنید:

متن کامل خطا و Screenshot
URL دقیق و Method درخواست
زمان رخداد با منطقه زمانی
کاربر واردشده یا مهمان
آخرین افزونه، قالب، PHP یا کد به‌روزشده
آخرین Import، Cron یا تغییر تنظیمات
آخرین سفارش سالم و اولین سفارش مشکل‌دار
Correlation ID یا Transaction ID در صورت وجود

سپس از فایل و دیتابیس Backup بگیرید. اگر سایت سفارش جدید می‌گیرد، Backup باید تازه باشد و Restore آن روی محیط جدا قابل آزمایش باشد.

راهنمای کامل در مقاله آموزش بکاپ و بازیابی وردپرس قرار دارد.

چه کارهایی را در دقیقه اول انجام ندهیم؟

همه افزونه‌ها را بدون ثبت فهرست فعلی حذف نکنید.
دیتابیس را با SQL ناشناس ویرایش نکنید.
Permission را روی 777 قرار ندهید.
نسخه PHP، WordPress و قالب را هم‌زمان تغییر ندهید.
فایل‌های Core را روی wp-content بازنویسی نکنید.
Log را پیش از ذخیره شواهد پاک نکنید.
Backup قدیمی را مستقیم روی فروشگاه فعال Restore نکنید.

هدف این است که یک متغیر در هر مرحله تغییر کند تا علت قابل شناسایی باشد.

مرحله اول: ایمیل Recovery Mode را بررسی کنید

WordPress در بعضی Fatal Errorهای درخواست عادی، ایمیلی به آدرس مدیریت سایت می‌فرستد. این ایمیل معمولاً شامل نام افزونه یا قالب درگیر، نوع خطا، مسیر فایل، شماره خط و لینک ورود به Recovery Mode است.

Recovery Mode چه کاری انجام می‌دهد؟

جزء خطادار را فقط برای Session مدیریتی شما Pause می‌کند.
امکان ورود به Dashboard را فراهم می‌سازد.
هشدار مربوط به افزونه یا قالب خطادار را نمایش می‌دهد.
اجازه می‌دهد جزء مشکل‌دار را غیرفعال یا اصلاح کنید.

Recovery Mode جای رفع علت نیست. پس از Deactivate یا اصلاح، باید سایت را خارج از Session بازیابی و روی مرورگر ناشناس آزمایش کنید.

اگر ایمیل Recovery Mode نرسید

Spam و ایمیل مدیریت در Settings → General را بررسی کنید.
SMTP و Log ارسال را کنترل نمایید.
ممکن است خطا در Cron یا Background Task رخ داده باشد و Recovery Mode فعال نشود.
ممکن است PHP یا وب‌سرور قبل از Fatal Error Handler متوقف شده باشد.
از Error Log هاست، PHP-FPM یا LiteSpeed استفاده کنید.

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

مرحله دوم: Error Log اصلی را پیدا کنید

بهترین منبع معمولاً Log سرور است، نه صفحه خطا. مسیر دقیق به هاست بستگی دارد:

cPanel → Errors
PHP-FPM Error Log
LiteSpeed یا Apache Error Log
فایل error_log در Document Root یا پوشه درگیر
WooCommerce → Status → Logs
wp-content/debug.log در عیب‌یابی موقت

Log را براساس Timestamp و URL فیلتر کنید. وجود صدها Warning قدیمی نباید شما را از اولین Fatal Error همان درخواست منحرف کند.

ساختار یک Fatal Error را چگونه بخوانیم؟

[timestamp] PHP Fatal error: Uncaught TypeError: ...
in /home/account/public_html/wp-content/plugins/example/file.php:125
Stack trace:
#0 ...
#1 ...
thrown in ... on line 125

برای تحلیل:

نوع خطا را ثبت کنید: TypeError، Error، Exception یا Memory Exhausted.
اولین فایل متعلق به افزونه، قالب یا کد سفارشی را پیدا کنید.
شماره خط را با نسخه همان فایل تطبیق دهید.
Stack Trace را برای Caller اصلی بخوانید.
زمان را با Update، سفارش یا Job مرتبط مقایسه کنید.
مطمئن شوید Log مربوط به همان Request است.

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

مرحله سوم: فعال‌سازی موقت WP_DEBUG_LOG

اگر Log هاست در دسترس نیست، روی Staging یا برای دوره کوتاه می‌توان تنظیم زیر را پیش از خط پایان ویرایش در wp-config.php قرار داد:

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

خطاها معمولاً در wp-content/debug.log ثبت می‌شوند. برای جلوگیری از دسترسی عمومی، می‌توان مسیر امن خارج از Web Root تعیین کرد:

define( 'WP_DEBUG_LOG', '/secure-path/wp-errors.log' );

WP_DEBUG_LOG فقط زمانی عمل می‌کند که WP_DEBUG واقعاً Boolean و برابر true باشد. نوشتن 'false' داخل کوتیشن، یک String غیرخالی و از دید PHP Truthy است.

چرا WP_DEBUG_DISPLAY باید خاموش باشد؟

نمایش خطا در Frontend می‌تواند مسیر سرور، نام افزونه، Query، Token یا ساختار داخلی را افشا کند و همچنین پاسخ JSON، AJAX یا Checkout را خراب سازد. خطا باید در Log ثبت شود، نه در صفحه مشتری.

پس از پایان عیب‌یابی، Debug را خاموش کنید. نگهداری دائمی Log بدون Rotation می‌تواند فضای دیسک را پر و داده حساس جمع‌آوری کند.

مرحله چهارم: Scope خطا را مشخص کنید

فقط Frontend خراب است

قالب، Page Builder، Cache، Minify، Hookهای نمایش یا افزونه‌ای که فقط در Frontend اجرا می‌شود محتمل است.

فقط wp-admin خراب است

Admin Hook، افزونه مدیریت، صفحه تنظیمات، AJAX مدیریتی یا Memory بالاتر در Dashboard را بررسی کنید.

فقط یک صفحه محصول یا نوشته

Shortcode، Block، Meta خاص، Template یا داده خراب همان Object محتمل است.

فقط Checkout

درگاه، فیلد سفارشی، Session، Cart Fragment، Validation، Shipping، Coupon، AJAX و Cache بررسی شوند.

فقط Cron یا Action Scheduler

Recovery Mode ممکن است فعال نشود. Log Job، Hook، Argument و PHP CLI یا Loopback اهمیت دارد.

مرحله پنجم: آخرین تغییر را بررسی کنید

بیشتر خطاها پس از یکی از این رویدادها شروع می‌شوند:

Update افزونه یا قالب
تغییر نسخه PHP
افزودن Snippet به functions.php
فعال‌سازی افزونه جدید
Import محصول یا دیتابیس
تغییر Cache و Minify
مهاجرت هاست
تغییر Permission یا مالکیت فایل

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

مرحله ششم: عیب‌یابی افزونه‌ها

وقتی نام افزونه در Fatal Error مشخص است

نسخه افزونه و WordPress/PHP را ثبت کنید.
افزونه را موقتاً غیرفعال نمایید.
Frontend، Admin و عملکرد وابسته را تست کنید.
Changelog و گزارش ناسازگاری را بررسی نمایید.
نسخه سالم قبلی را فقط از منبع معتبر Restore کنید.

غیرفعال‌سازی ممکن است سرویس مهمی مانند درگاه یا امنیت را متوقف کند. Checkout را تا پایان تست کنترل کنید.

وقتی به Dashboard دسترسی دارید

افزونه‌های مشکوک را یکی‌یکی غیرفعال کنید. پس از هر مرحله همان URL و Action را دوباره اجرا کنید.

وقتی Dashboard باز نمی‌شود

از SFTP یا File Manager پوشه افزونه مشخص را تغییر نام دهید:

wp-content/plugins/example-plugin
wp-content/plugins/example-plugin.disabled

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

غیرفعال‌کردن همه افزونه‌ها

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

در WooCommerce، غیرفعال‌کردن همه افزونه‌ها می‌تواند درگاه، Download، SEO، Security و اتصال‌های خارجی را متوقف کند؛ روی Production بدون Maintenance Window انجام ندهید.

عیب‌یابی افزونه با WP-CLI

مشاهده فهرست:

wp plugin list

غیرفعال‌کردن افزونه مشخص:

wp plugin deactivate plugin-slug

غیرفعال‌کردن همه برای تست:

wp plugin deactivate --all

WP‑CLI نیز WordPress را Bootstrap می‌کند و ممکن است خودش با Fatal Error متوقف شود. در این حالت از --skip-plugins یا تغییر نام پوشه استفاده کنید.

MU Plugin و Drop-inها را فراموش نکنید

Must‑Use Pluginها در wp-content/mu-plugins قرار دارند و در صفحه معمولی افزونه‌ها مانند Plugin عادی غیرفعال نمی‌شوند. همچنین فایل‌های Drop‑in مانند این موارد ممکن است دخیل باشند:

object-cache.php
advanced-cache.php
db.php
maintenance.php

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

مرحله هفتم: عیب‌یابی قالب

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

در سایت فعلی، WoodMart 8.3.7 قالب اصلی است. خطا ممکن است از خود قالب، WoodMart Core، Template Override ووکامرس، Custom CSS/JS یا Snippetهای قالب باشد.

وقتی Dashboard باز نمی‌شود

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

Child Theme و Parent Theme

اگر Child Theme فعال است، خطا می‌تواند در functions.php یا فایل Override آن باشد. تست Parent Theme کمک می‌کند تفاوت مشخص شود، اما سفارشی‌سازی‌های Child در این حالت اجرا نمی‌شوند.

Template Overrideهای WooCommerce

در WooCommerce → Status، بخش Templateها را بررسی کنید. Override قدیمی ممکن است با نسخه جدید WooCommerce ناسازگار شود. راه‌حل، کپی کورکورانه فایل جدید نیست؛ تغییرهای سفارشی باید با نسخه جدید Merge شوند.

مرحله هشتم: خطای Memory Exhausted

پیام رایج:

Allowed memory size of ... bytes exhausted

این خطا می‌گوید Request از Memory Limit مجاز عبور کرده است. افزایش Limit می‌تواند موقتاً سایت را بالا بیاورد، اما اگر افزونه Loop یا داده غیرعادی ایجاد کرده باشد، علت اصلی باقی می‌ماند.

موارد بررسی

نام فایل و تابع آخر
حجم محصول یا Query درگیر
Import، Backup یا Image Processing
تعداد افزونه‌ها و Object Cache
Memory Limit واقعی PHP
تفاوت Frontend و Admin

WP_MEMORY_LIMIT

نمونه تنظیم در wp-config.php:

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

این مقدار درخواست WordPress است و نمی‌تواند محدودیت سخت هاست یا PHP را همیشه بالاتر ببرد. عدد مناسب به سرویس و منابع سرور بستگی دارد؛ افزایش نامحدود راهکار نیست.

WP_MAX_MEMORY_LIMIT

برای بعضی عملیات مدیریتی:

define( 'WP_MAX_MEMORY_LIMIT', '512M' );

این مثال نسخه عمومی نیست. ابتدا مصرف واقعی و محدودیت پلن هاست بررسی شود.

مرحله نهم: نسخه PHP و Extensionها

کد قدیمی ممکن است روی نسخه PHP جدید Fatal Error دهد و کد جدید روی نسخه بسیار قدیمی اجرا نشود. بعد از تغییر PHP این موارد رایج‌اند:

TypeErrorهای سخت‌گیرانه‌تر
تابع یا Syntax پشتیبانی‌نشده
Extension گمشده مانند mbstring، intl، curl یا zip
تفاوت تنظیمات php.ini
تفاوت PHP وب و PHP CLI

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

مرحله دهم: خطای 500 و فایل .htaccess

روی Apache یا LiteSpeed، Rule خراب در .htaccess می‌تواند 500 ایجاد کند. قبل از تغییر یک نسخه کپی بگیرید و فایل را موقتاً تغییر نام دهید:

.htaccess
.htaccess.backup

اگر سایت باز شد، در Settings → Permalinks روی Save بزنید تا Ruleهای WordPress بازسازی شوند. سپس Ruleهای امنیت، Cache و Redirect را مرحله‌ای برگردانید.

در Nginx، .htaccess استفاده نمی‌شود و باید Configuration سرور بررسی گردد.

خطاهای رایج داخل .htaccess

Directive پشتیبانی‌نشده
Rewrite Loop
Rule تکراری WordPress و CDN
دستور PHP مخصوص Apache روی LiteSpeed متفاوت
فایل دارای Syntax ناقص
Rule امنیتی که REST یا Callback را مسدود می‌کند

مرحله یازدهم: فایل .maintenance

اگر پس از Update پیام «برای انجام تعمیرات زمان‌بندی‌شده به‌طور موقت در دسترس نیست» باقی مانده است، فایل .maintenance ممکن است در Root حذف نشده باشد.

ابتدا مطمئن شوید Update واقعاً متوقف شده و Process دیگری فعال نیست؛ سپس فایل را حذف و سلامت Core، Plugin و Database Update را بررسی کنید.

مرحله دوازدهم: فایل‌های هسته وردپرس

فایل ناقص یا تغییرکرده Core می‌تواند Fatal Error یا 500 ایجاد کند.

بررسی Checksum

wp core verify-checksums --include-root

این دستور فایل‌های Core را با Checksum رسمی نسخه مقایسه می‌کند. فایل‌های Root اضافی نیز با --include-root گزارش می‌شوند.

بازنصب Core از Dashboard

در Dashboard → Updates می‌توان نسخه فعلی را Reinstall کرد. این کار نباید wp-content و دیتابیس را حذف کند، اما Backup همچنان لازم است.

بازنصب دستی

فقط پوشه‌های wp-admin و wp-includes و فایل‌های Root استاندارد را از بسته رسمی جایگزین کنید. wp-content و wp-config.php را بازنویسی نکنید.

Checksum افزونه‌ها

برای افزونه‌های مخزن رسمی:

wp plugin verify-checksums --all

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

مرحله سیزدهم: Permission و مالکیت فایل

Permission اشتباه می‌تواند خواندن، نوشتن Cache، Upload یا اجرای PHP را مختل کند.

فایل‌ها معمولاً از 644 شروع می‌شوند.
پوشه‌ها معمولاً از 755 شروع می‌شوند.
wp-config.php می‌تواند محدودتر باشد.
Owner و Group باید با مدل اجرای PHP هماهنگ باشند.

این مقادیر مطلق نیستند و معماری هاست تعیین‌کننده است. 777 راه‌حل عمومی نیست و سطح حمله را افزایش می‌دهد.

مرحله چهاردهم: Error Establishing a Database Connection

این پیام با Critical Error متفاوت است و نشان می‌دهد WordPress به دیتابیس دسترسی ندارد.

موارد بررسی

DB_NAME
DB_USER
DB_PASSWORD
DB_HOST
مجوز User روی Database
فعال‌بودن MySQL/MariaDB
Quota و Disk
Table Crash یا Connection Limit

Credentialها را در تیکت عمومی یا Screenshot منتشر نکنید.

Repair دیتابیس

Repair فقط برای Table خراب است و خطای Credential یا Query بد را حل نمی‌کند.

wp db check
wp db repair

WordPress همچنین Constant زیر را برای فعال‌سازی صفحه Repair دارد:

define( 'WP_ALLOW_REPAIR', true );

صفحه Repair بدون Login قابل دسترسی است؛ بعد از پایان، Constant را فوراً حذف یا غیرفعال کنید.

مرحله پانزدهم: خطای REST API و AJAX

گاهی صفحه اصلی سالم است، اما Editor، Checkout یا ذخیره تنظیمات با خطای 500 روبه‌رو می‌شود.

در مرورگر

Developer Tools → Network را باز کنید.
Request قرمز را انتخاب نمایید.
URL، Method، Status و Response را ثبت کنید.
زمان را با Error Log تطبیق دهید.

مسیرهای رایج

/wp-json/
/wp-admin/admin-ajax.php
/?wc-ajax=...
Callback درگاه

نمایش Warning PHP قبل از JSON می‌تواند پاسخ را نامعتبر کند؛ به همین دلیل WP_DEBUG_DISPLAY باید خاموش باشد.

مرحله شانزدهم: JavaScript Error را از PHP Error جدا کنید

اگر صفحه باز می‌شود اما دکمه کار نمی‌کند، Console مرورگر را بررسی کنید. JavaScript Error معمولاً 500 نیست، ولی ممکن است Request AJAX را نادرست بسازد.

خطای JavaScript و Stack را ثبت کنید.
Minify و Combine را موقتاً روی Staging خاموش کنید.
با مرورگر ناشناس و Cache پاک تست کنید.
فایل Theme و Plugin تولیدکننده Script را مشخص نمایید.

مرحله هفدهم: LiteSpeed Cache

Cache معمولاً علت Fatal Error PHP نیست، اما می‌تواند صفحه خطای قدیمی را نگه دارد یا Minify باعث شکست JavaScript شود.

تست کنترل‌شده

Purge All انجام دهید.
صفحه را با Query String جدید تست کنید.
Optimization CSS/JS را روی Staging موقتاً غیرفعال کنید.
Object Cache Connection را بررسی نمایید.
Cart، Checkout و My Account را از Cache عمومی خارج نگه دارید.

پاک‌کردن Cache بدون رفع خطای اصلی فقط علامت را موقتاً پنهان می‌کند.

مرحله هجدهم: خطاهای WooCommerce

در WooCommerce → Status → Logs این Sourceها را جست‌وجو کنید:

fatal-errors
نام درگاه پرداخت
transactional-emails
Webhookها
Import یا افزونه سفارشی

Order Note و WooCommerce Log را با PHP Log و Timestamp یکسان مقایسه کنید.

Critical Error در Checkout

Checkout یک زنجیره چندمرحله‌ای است:

اعتبارسنجی Cart و Session
محاسبه تخفیف و موجودی
ساخت Order
اجرای Hookهای افزونه‌ها
ارسال به درگاه
دریافت Callback
تغییر Status و ارسال ایمیل

Fatal Error در هر مرحله ممکن است سفارش نیمه‌ساخته ایجاد کند. قبل از تکرار پرداخت، Order و Transaction را بررسی کنید تا دوباره‌پرداخت رخ ندهد.

روش ایزوله‌کردن خطای Checkout

یک محصول ساده و کم‌قیمت آزمایشی بسازید.
کوپن و Shipping پیچیده را حذف کنید.
روش پرداخت آفلاین یا Sandbox را تست کنید.
Checkout مهمان و حساب‌دار را جدا بررسی نمایید.
فیلدهای سفارشی و افزونه‌های Checkout را مرحله‌ای غیرفعال کنید.
Network Request و Woo Log را تطبیق دهید.

تست پرداخت واقعی باید کنترل‌شده و با برنامه Refund انجام شود.

خطای درگاه و Callback

اگر مشتری پرداخت کرده ولی سفارش Pending یا Failed مانده است:

Order Note
Transaction ID
Log درگاه
Callback URL
WAF و Rate Limit
SSL و DNS
Clock سرور

را بررسی کنید. وضعیت سفارش را فقط براساس ادعای مشتری به Completed تغییر ندهید؛ تراکنش باید در پنل پذیرنده تأیید شود.

HPOS و خطاهای سفارش

سایت فعلی HPOS را فعال دارد. افزونه‌ای که مستقیم به posts و postmeta برای سفارش وابسته باشد ممکن است خطا یا داده ناقص تولید کند.

سازگاری افزونه با HPOS را بررسی کنید.
از CRUD رسمی WooCommerce استفاده شود.
جدول‌های سفارش و Schema Version کنترل شوند.
Compatibility Mode در صورت وجود بررسی گردد.

Action Scheduler و خطای پس‌زمینه

در WooCommerce → Status → Scheduled Actions، وضعیت Failed و In‑progress قدیمی را بررسی کنید.

Log هر Action شامل Hook، Argument و زمان اجراست. Run مجدد بدون شناخت می‌تواند ایمیل، Import یا عملیات مالی را تکرار کند.

خطای Import و فایل PDF

در سایت فعلی افزونه‌های سفارشی Import و پردازش PDF فعال‌اند. خطاهای رایج:

Memory Exhausted هنگام پردازش تصویر
Timeout در فایل بزرگ
Extension گمشده PHP
Permission پوشه موقت
فایل ناقص یا MIME نامعتبر
Job نیمه‌تمام Action Scheduler

ورودی، اندازه فایل، شناسه Job و Log اختصاصی باید ثبت شوند.

مرحله نوزدهم: Timeouts

پیام Connection Timed Out یا 504 می‌تواند از اجرای طولانی PHP، Worker کم، Query کند یا سرویس خارجی باشد.

موارد بررسی

max_execution_time
PHP-FPM Request Timeout
Proxy و CDN Timeout
Database Slow Query
API خارجی
Lock و Queue

افزایش Timeout بدون اصلاح عملیات طولانی، فقط زمان انتظار کاربر را بیشتر می‌کند. Job سنگین باید Batch و Background شود.

مرحله بیستم: Loop و Redirect

Too Many Redirects معمولاً Fatal Error نیست، اما ممکن است پس از SSL، Proxy یا تغییر URL ظاهر شود.

home و siteurl
HTTP/HTTPS Detection
Cloudflare SSL Mode
Ruleهای .htaccess
افزونه Redirect
Cookie Domain

را بررسی کنید. Redirect را در فقط یک یا دو لایه کنترل‌شده نگه دارید.

مرحله بیست‌ویکم: بازتولید روی Staging

پس از بازگردانی فوری سایت، علت را روی Staging بازتولید کنید:

نسخه نزدیک به زمان Incident بسازید.
نسخه PHP و افزونه‌ها را هماهنگ کنید.
همان URL و ورودی را تکرار نمایید.
Debug و Query ابزارها را فقط آنجا فعال کنید.
هر بار یک متغیر را تغییر دهید.
Fix را قبل از Production چندبار آزمایش کنید.

راهنمای ساخت محیط تست در مقاله آموزش ساخت Staging وردپرس قرار دارد.

Health Check و Troubleshooting Mode

افزونه رسمی Health Check & Troubleshooting می‌تواند برای Session مدیر یک محیط عیب‌یابی ایجاد کند که در آن افزونه‌ها غیرفعال و قالب پیش‌فرض فعال‌اند، بدون اینکه بازدیدکنندگان همان وضعیت را ببینند.

بااین‌حال:

ابتدا Backup بگیرید.
روی فروشگاه پرترافیک اثر Session، Cache و Background Task را بسنجید.
خطاهای Cron و Webhook ممکن است در Session عیب‌یابی بازتولید نشوند.
برای تست Checkout با کاربر مهمان به Staging نیاز است.

Query Monitor چه زمانی مفید است؟

Query Monitor برای بررسی Query، Hook، HTTP API، PHP Error و Assetها مفید است، اما روی Production سربار و اطلاعات حساس ایجاد می‌کند. آن را روی Staging یا برای بازه کوتاه و دسترسی محدود استفاده کنید.

یک Decision Tree عملی

سایت کاملاً از دسترس خارج است

Uptime و سرور را بررسی کنید.
Error Log و Recovery Email را بخوانید.
افزونه یا قالب نام‌برده‌شده را غیرفعال کنید.
در صورت نامشخص‌بودن، Plugin Conflict Test انجام دهید.
.htaccess و Core را بررسی کنید.

فقط Admin خراب است

Request خطادار را در Network پیدا کنید.
Log همان زمان را بخوانید.
Admin Plugin یا Memory را بررسی کنید.
با WP‑CLI یا Recovery Mode جزء خطادار را غیرفعال کنید.

فقط Checkout خراب است

Checkout را موقتاً تحت کنترل قرار دهید.
Order و Transactionهای نیمه‌تمام را بررسی کنید.
Woo Log، PHP Log و Network را تطبیق دهید.
درگاه، افزونه Checkout و Session را مرحله‌ای تست کنید.

تست پس از رفع خطا

عمومی

صفحه اصلی، نوشته و جست‌وجو
ورود و خروج مدیر
آپلود رسانه
ذخیره نوشته
REST API و Cron
صفحه 404 و Permalink

WooCommerce

محصول ساده و دانلودی
Variation و موجودی
Cart و Coupon
Checkout مهمان و حساب‌دار
درگاه و Callback
ایمیل و Download
Refund آزمایشی
Action Scheduler

فنی

عدم وجود Fatal Error جدید
مصرف Memory و CPU
خطاهای 500 و 504
Object Cache و LiteSpeed
Uptime و TTFB

بعد از رفع خطا چه چیزی مستند شود؟

زمان شروع و پایان Incident
اثر روی کاربر و سفارش
Root Cause
تغییر موقت و Fix نهایی
فایل یا نسخه درگیر
روش Rollback
تست‌های انجام‌شده
اقدام پیشگیرانه

یک Postmortem بدون سرزنش کمک می‌کند خطا تکرار نشود.

اقدام‌های پیشگیرانه

Update ابتدا روی Staging
Backup خودکار و Restore آزمایشی
مانیتور Uptime و Error Rate
Log Rotation و Retention
Version Control برای کد سفارشی
Release Note و Rollback Plan
تست Checkout پس از هر تغییر
حداقل‌سازی افزونه‌های بلااستفاده
سازگاری HPOS و PHP قبل از Update

مقاله به‌روزرسانی امن وردپرس فرایند Update کنترل‌شده را توضیح می‌دهد.

برنامه پیشنهادی برای dev-source.ir

محل PHP و LiteSpeed Error Log در پنل هاست مستند شود.
ایمیل مدیریت و تحویل Recovery Mode تست گردد.
یک Staging نزدیک به Production نگهداری شود.
WoodMart، WoodMart Core و Template Overrideها قبل از Update بررسی شوند.
برای افزونه‌های سفارشی Source Log و Correlation ID تعریف شود.
Critical Error در Import، PDF و Checkout با Job ID ثبت گردد.
Runbook غیرفعال‌سازی امن درگاه و Checkout نوشته شود.
HPOS Compatibility افزونه‌ها دوره‌ای کنترل شود.
پس از هر Release یک سفارش و Download آزمایشی انجام شود.
Fatal Error، 500 و Failed Action در داشبورد مانیتورینگ هشدار داشته باشند.

خطاهای رایج و راه‌حل سریع

There has been a critical error on this website

Recovery Email، Fatal Error و افزونه یا قالب نام‌برده‌شده را بررسی کنید.

Allowed memory size exhausted

مصرف‌کننده Memory را پیدا کنید؛ افزایش Limit فقط پس از تحلیل انجام شود.

Call to undefined function

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

Class not found

Autoloader، ترتیب Load، فایل ناقص یا Dependency را بررسی کنید.

Cannot redeclare function

تابع دوبار تعریف شده؛ Snippet، Child Theme یا Plugin تکراری را پیدا کنید.

Headers already sent

خروجی زودهنگام، Space قبل از PHP Tag یا Warning نمایش‌داده‌شده را بررسی کنید.

Maximum execution time exceeded

Job را Batch کنید و Query یا API کند را اصلاح نمایید.

Briefly unavailable for scheduled maintenance

پس از اطمینان از توقف Update، فایل .maintenance را حذف و نسخه‌ها را کنترل کنید.

چک‌لیست نهایی رفع Critical Error

زمان، URL و متن خطا ثبت شده است.
Backup تازه و قابل Restore وجود دارد.
Recovery Email بررسی شده است.
Error Log براساس Timestamp خوانده شده است.
WP_DEBUG_DISPLAY روی سایت عمومی خاموش است.
افزونه و قالب مرحله‌ای تست شده‌اند.
MU Plugin و Drop-in بررسی شده‌اند.
Memory، PHP و Extensionها کنترل شده‌اند.
.htaccess و فایل Maintenance بررسی شده‌اند.
Checksum هسته و افزونه‌ها کنترل شده است.
Database Connection و Disk سالم‌اند.
REST، AJAX و JavaScript جدا تحلیل شده‌اند.
Woo Log، Order Note و Callback تطبیق داده شده‌اند.
HPOS و Action Scheduler تست شده‌اند.
Fix روی Staging تأیید شده است.
Checkout، ایمیل و Download پس از رفع خطا تست شده‌اند.

📌 همچنین بخوانید: ارتقای نسخه PHP وردپرس، نگهداری دوره‌ای وردپرس و انتقال وردپرس به هاست جدید

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

آیا Critical Error یعنی سایت هک شده است؟

خیر. علت معمولاً ناسازگاری کد، افزونه، قالب، PHP یا Memory است. نفوذ یکی از احتمال‌هاست، نه نتیجه قطعی.

آیا غیرفعال‌کردن همه افزونه‌ها اطلاعات را حذف می‌کند؟

غیرفعال‌سازی معمولاً داده را حذف نمی‌کند، اما عملکرد سایت را متوقف می‌سازد. Uninstall یا حذف بعضی افزونه‌ها ممکن است داده را پاک کند.

آیا افزایش Memory Limit همیشه خطا را رفع می‌کند؟

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

چرا خطا فقط برای مدیر دیده می‌شود؟

افزونه مدیریتی، صفحه خاص Dashboard، Query سنگین یا Capability Hook ممکن است فقط برای مدیر اجرا شود.

چرا Checkout فقط برای بعضی مشتریان خطا دارد؟

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

آیا می‌توان WP_DEBUG را دائمی روشن گذاشت؟

برای Production توصیه نمی‌شود. از Error Logging سرور و مانیتورینگ کنترل‌شده استفاده کنید.

خطای 500 بعد از حذف Cache باقی مانده؛ چرا؟

Cache علت اصلی نیست یا Error در PHP، Rule سرور، دیتابیس یا Permission ادامه دارد. Log را بررسی کنید.

جمع‌بندی

رفع خطای Critical Error وردپرس با خواندن شواهد شروع می‌شود. Recovery Mode و Error Log معمولاً نام جزء و محل توقف را مشخص می‌کنند. بعد از آن باید افزونه، قالب، PHP، Memory، Ruleهای سرور، Core و دیتابیس به‌ترتیب و با یک تغییر در هر مرحله بررسی شوند.

در فروشگاه WooCommerce، بازشدن صفحه اصلی معیار کافی نیست. Checkout، درگاه، Callback، HPOS، Action Scheduler، ایمیل و دانلود باید پس از Fix آزمایش شوند. هر Fatal Error ممکن است سفارش نیمه‌تمام یا پرداخت تأییدنشده ایجاد کند.

برای سایت فعلی، مهم‌ترین اقدام پیشگیرانه مستندسازی Log هاست، Staging مشابه Production، کنترل سازگاری WoodMart و افزونه‌های سفارشی و ساخت Runbook مشخص برای Checkout و درگاه است. Debug دائمی و خاموش‌کردن کورکورانه افزونه‌ها جای فرایند عیب‌یابی را نمی‌گیرد.

منابع رسمی

آموزش‌های تازه، کد آماده و رفع خطاهر هفته در کانال Dev Source؛ رایگان.

✈️ کانال تلگرام 🟣 کانال روبیکا