بررسی تداخل افزونه‌های وردپرس زمانی لازم است که پس از نصب یا به‌روزرسانی یک افزونه، بخشی از سایت درست کار نکند. خطای ۵۰۰، اختلال فرم یا خرابی ویرایشگر می‌تواند نشانهٔ تداخل باشد؛ اما از روی ظاهر خطا نمی‌توان افزونه‌ای را مقصر دانست. ابتدا مشکل را بازتولید کنید و بعد با آزمون کنترل‌شده، عامل آن را پیدا کنید.
بازبینی فنی: ۲۷ مهر ۱۴۰۵. تاریخ انتشار اولیه و نشانی این مقاله حفظ شده است.
تداخل افزونه وردپرس چیست؟
ممکن است یک افزونه به‌تنهایی کار کند، اما کنار افزونه یا قالب دیگری خطا بدهد. گاهی نیز مشکل از ناسازگاری با PHP، تنظیمات سرور یا کش است و ارتباطی با تداخل دو افزونه ندارد. هدف عیب‌یابی، پیدا کردن شرایط تکرار خطاست؛ نه حذف تصادفی افزونه‌ها.
پیش از بررسی تداخل افزونه‌های وردپرس
- از فایل‌ها و پایگاه داده پشتیبان بگیرید و مطمئن شوید راه بازگردانی آن در دسترس است.
- فهرست افزونه‌های فعال، قالب و نسخه‌های وردپرس و PHP را ثبت کنید. زمان شروع مشکل و آخرین تغییرات را یادداشت کنید.
- از سایت یک کپی آزمایشی بسازید. ارسال ایمیل، پرداخت و اتصال‌های بیرونی را در آن طوری تنظیم کنید که سفارش یا پیام واقعی تولید نشود.
- یک سناریوی کوتاه و مشخص تعریف کنید؛ مثلاً «فرم تماس با این ورودی ارسال نمی‌شود». بعد از هر تغییر، همان سناریو را تکرار کنید.
در سایت فعال، غیرفعال‌کردن گروهی افزونه‌های فروشگاه، عضویت، امنیت یا پرداخت می‌تواند خدمت‌رسانی را مختل کند. روش اصلی این راهنما آزمون روی محیط تست است.
روش اول: آزمون مرحله‌ای در محیط تست
- ابتدا بررسی کنید مشکل در کپی آزمایشی نیز رخ می‌دهد. تفاوت نسخه‌ها، تنظیمات و سرویس‌های بیرونی می‌تواند نتیجه را تغییر دهد.
- افزونهٔ مرتبط با قابلیت معیوب و وابستگی‌های ضروری آن را نگه دارید. سایر افزونه‌ها را فقط در محیط تست غیرفعال کنید و دوباره آزمایش بگیرید.
- اگر مشکل برطرف شد، افزونه‌ها را یکی‌یکی فعال کنید. بعد از هر فعال‌سازی، آزمون را تکرار و نتیجه را ثبت کنید.
- وقتی خطا برگشت، افزونهٔ آخر را دوباره غیرفعال کنید. بازگشت عملکرد به حالت سالم، سرنخ مهمی است؛ اما برای تشخیص تداخل، ترکیب افزونهٔ اصلی و افزونهٔ مشکوک را جداگانه هم امتحان کنید.
- اگر خطا با حداقل افزونه‌های لازم باقی ماند، روی همان محیط تست یک قالب پیش‌فرض سازگار را امتحان کنید. خرابی ظاهر پس از تغییر قالب، به‌تنهایی اثبات خطای افزونه نیست.
ممکن است افزونهٔ آخر فقط یک مشکل موجود در افزونهٔ دیگر را آشکار کند. برای گزارش فنی، ترکیب دقیق نسخه‌ها و نتیجهٔ هر آزمون را نگه دارید.
روش دوم: حالت عیب‌یابی مخصوص مدیر
در آموزش‌های قدیمی، حالت عیب‌یابی با نام Health Check & Troubleshooting معرفی می‌شود. این قابلیت به‌صورت افزونهٔ مستقل Troubleshooting در مخزن رسمی وردپرس هم ارائه شده است. پیش از نصب، ناشر، سازگاری و راهنمای نسخهٔ فعلی را بررسی کنید؛ نام منوها ممکن است با نسخهٔ قدیمی فرق داشته باشد.
این حالت تلاش می‌کند افزونه‌ها و قالب را فقط برای نشست مدیر تغییر دهد، بدون اینکه تجربهٔ بازدیدکنندگان عادی تغییر کند. بااین‌حال تضمین بدون‌خطر بودن نیست: کش تهاجمی یا رفتار خاص بعضی افزونه‌ها می‌تواند نتیجه را تغییر دهد. داشتن پشتیبان و ترجیح محیط تست همچنان ضروری است.
پس از فعال‌کردن حالت عیب‌یابی، افزونه‌ها را تدریجی و همراه وابستگی‌هایشان فعال کنید. در پایان، از گزینهٔ خروج از حالت عیب‌یابی استفاده کنید و سایت را در پنجره‌ای که وارد حساب نیست بررسی کنید. اگر نمایش نامناسب باقی ماند، کش را از مسیر معمول سرویس یا افزونهٔ مربوط پاک و دوباره آزمون کنید.
اگر پیشخوان باز نمی‌شود چه کنیم؟
اگر ایمیل بازیابی وردپرس رسیده است، از همان مسیر رسمی استفاده کنید و لینک آن را عمومی نفرستید. در غیر این صورت، از پشتیبانی هاست برای بررسی لاگ و غیرفعال‌کردن موقت افزونهٔ مشکوک کمک بگیرید. تغییر نام پوشهٔ افزونه با حذف آن فرق دارد، اما روی سایت واقعی اثر می‌گذارد؛ نام و محل اصلی پوشه و روش برگشت باید مشخص باشد.
تغییر نام کل پوشهٔ plugins، راه‌حل عادی برای هر خطا نیست. این اقدام همهٔ افزونه‌های معمول را تحت تأثیر قرار می‌دهد و فعال‌سازی مجدد آن‌ها باید کنترل‌شده انجام شود. افزونه‌های اجباری و بعضی لایه‌های کش نیز با غیرفعال‌کردن افزونه‌های معمول کنار نمی‌روند.
لاگ خطا و نتیجهٔ آزمون را چطور بخوانیم؟
لاگ PHP سرور و خطاهای کنسول مرورگر می‌توانند مسیر بررسی را روشن کنند. نام یک افزونه در خطا، به‌تنهایی اثبات مقصر بودن آن نیست. زمان خطا را با سناریوی آزمایش تطبیق دهید. اگر عیب‌یابی وردپرس لازم شد، آن را موقت و ترجیحاً روی محیط تست انجام دهید؛ خطاها نباید برای بازدیدکننده نمایش داده شوند.
لاگ‌ها ممکن است مسیرهای داخلی یا داده‌های شخصی داشته باشند. پیش از ارسال برای پشتیبانی، اطلاعات محرمانه را بپوشانید و از ارسال رمز، کوکی نشست یا کلید API خودداری کنید. پس از پایان، تنظیمات موقت عیب‌یابی را به وضعیت مناسب محیط برگردانید.
رفع تداخل و کنترل نهایی
نسخهٔ اصلاح‌شده یا تنظیم پیشنهادی توسعه‌دهنده را ابتدا در محیط تست آزمایش کنید. اگر جایگزینی افزونه لازم است، فقط شباهت قابلیت‌ها کافی نیست؛ انتقال تنظیمات، داده‌ها و فرم‌ها را نیز بررسی کنید. ویرایش مستقیم فایل افزونه معمولاً با به‌روزرسانی بعدی از بین می‌رود.
برای درخواست پشتیبانی، نسخه‌ها، مراحل بازتولید، نتیجهٔ آزمون قالب و افزونه‌ها و بخش پاک‌سازی‌شدهٔ لاگ را ارائه دهید. سپس تغییر تأییدشده را با امکان برگشت به سایت اصلی منتقل کنید و فرم‌ها، ورود، جست‌وجو و در صورت وجود، خرید آزمایشی را کنترل کنید.
پرسش‌های رایج
آیا هر خطای ۵۰۰ ناشی از تداخل افزونه است؟
خیر. محدودیت منابع، خطای PHP یا تنظیمات سرور هم می‌توانند چنین خطایی بسازند. برای بررسی گسترده‌تر، راهنمای خطای ۵۰۰ را ببینید.
آیا فعال‌کردن دوبارهٔ افزونه‌ها کافی است؟
خیر. باید سناریوی خطا و قابلیت‌های مهم سایت را دوباره امتحان کنید. ظاهر سالم صفحهٔ اصلی، سلامت فرم‌ها یا پرداخت را ثابت نمی‌کند.
