تداخل افزونه زمانی رخ می‌دهد که دو مؤلفه جداگانه به‌تنهایی کار می‌کنند اما ترکیب آن‌ها رفتار سایت را خراب می‌کند؛ برای مثال هر دو checkout را تغییر می‌دهند، نسخه متفاوت یک کتابخانه را بارگذاری می‌کنند یا روی یک hook با فرض ناسازگار عمل می‌کنند. صرفاً خاموش کردن آخرین افزونه و بازگشت سایت، احتمال را بالا می‌برد ولی هنوز نوع تداخل را ثابت نمی‌کند.
پاسخ سریع: مشکل را به یک سناریوی تکرارپذیر تبدیل کنید، clone نزدیک به production بسازید، لاگ و Network را ثبت کنید و افزونه‌ها را با روش مرحله‌ای یا تقسیم مجموعه آزمایش کنید. بعد از یافتن جفت مسئله‌ساز، نسخه‌ها، تنظیمات و hook خطادار را مشخص کنید؛ خاموش گذاشتن تصادفی افزونه‌ها راه‌حل نگهداری‌پذیر نیست.
نشانه‌های واقعی تداخل چیست؟
- فرم یا checkout تنها با فعال بودن دو افزونه مشخص خراب می‌شود.
- JavaScript صفحه خطای duplicate declaration یا dependency گمشده می‌دهد.
- PHP از class/function تکراری یا نوع داده غیرمنتظره خطا می‌دهد.
- یک افزونه داده را در hook تغییر می‌دهد و افزونه بعدی همان ساختار را معتبر فرض می‌کند.
- REST API یا cron کار می‌کند، اما با فعال شدن مؤلفه امنیت یا cache متوقف می‌شود.
کندی به‌تنهایی اثبات تداخل نیست. ممکن است مجموع queryها یا درخواست‌های خارجی زیاد باشد، بدون آنکه دو افزونه منطق هم را بشکنند.
پیش‌نیاز: سناریوی قابل تکرار بسازید
به‌جای جمله «سایت گاهی خراب است»، مراحل دقیق بنویسید: نقش کاربر، URL، محصول یا فرم، ورودی، نتیجه مورد انتظار، نتیجه واقعی و زمان. cache مرورگر و CDN را کنترل کنید. اگر خطا فقط برای کاربر واردشده رخ می‌دهد، تست ناشناس جایگزین مناسبی نیست.
چرا staging برای این تست ضروری است؟
غیرفعال کردن افزونه پرداخت، امنیت، membership یا ارسال سفارش روی production اثر تجاری دارد. clone باید تا حد امکان نسخه PHP، وردپرس، افزونه‌ها، قالب و تنظیمات مشابه داشته باشد، ولی ایمیل، پیامک، webhook و درگاه واقعی آن ایزوله شود. داده شخصی staging نیز باید محدود و محافظت شود.
روش مرحله‌ای برای تعداد کم افزونه
- همه نسخه‌ها و وضعیت فعال بودن را ثبت کنید.
- افزونه‌ای را که قابلیت خراب به آن وابسته است فعال نگه دارید.
- سایر افزونه‌ها را موقتاً غیرفعال و سناریو را تکرار کنید.
- افزونه‌ها را یکی‌یکی فعال کنید و بعد از هر تغییر همان تست را انجام دهید.
- هنگام بازگشت خطا، ترکیب را دوباره تکرار کنید تا false positive حذف شود.
wp plugin list --status=active
wp plugin deactivate plugin-slug
wp plugin activate plugin-slugاین فرمان‌ها state سایت را تغییر می‌دهند و باید فقط با slug صحیح، backup و آگاهی از وابستگی‌ها اجرا شوند. در multisite وضعیت network-active را نیز لحاظ کنید.
برای تعداد زیاد افزونه از تقسیم مجموعه استفاده کنید
اگر ۴۰ افزونه دارید، فعال‌سازی تک‌تک زمان‌بر است. نیمی از افزونه‌های غیرضروری را فعال و نیم دیگر را غیرفعال کنید. اگر مشکل وجود داشت، عامل در مجموعه فعال است؛ در غیر این صورت مجموعه دیگر را آزمایش کنید. هر بار مجموعه مشکوک را نصف کنید تا به چند گزینه برسید. افزونه پایه‌ای که سناریو به آن نیاز دارد باید در تمام دورها ثابت بماند.
نتیجه را در جدول ثبت کنید؛ حافظه انسانی در چند دور تست قابل اعتماد نیست. بعد از هر تغییر، cache مرتبط را به شکل یکسان پاک کنید تا نتیجه به پاسخ قدیمی وابسته نباشد.
لاگ و ابزار مرورگر چه می‌گویند؟
برای خطای backend، PHP error log و debug.log را در timestamp درخواست ببینید. برای رابط کاربری، Console و Network نام script، status درخواست XHR و پاسخ API را نشان می‌دهند. HAR، cookie و token ممکن است حساس باشند و قبل از اشتراک‌گذاری باید پاک‌سازی شوند.
Query Monitor در محیط کنترل‌شده می‌تواند hook، query و درخواست HTTP را روشن کند، ولی خودش سربار دارد و نباید بدون نیاز روی production روشن بماند. مشاهده نام افزونه در آخرین stack frame همیشه به معنی مقصر بودن آن نیست؛ جریان فراخوانی را از نخستین خط مرتبط دنبال کنید.
بعد از پیدا کردن افزونه مسئله‌ساز
جفت نسخه‌ها و تنظیمی را که خطا را تولید می‌کند ثبت کنید. changelog و issue رسمی هر دو سازنده را بررسی کنید. گزینه‌های پایدار شامل ارتقا به نسخه سازگار، بازگشت کنترل‌شده به نسخه امن قبلی، حذف قابلیت هم‌پوشان یا patch قابل نگهداری است. ویرایش مستقیم فایل vendor در آپدیت بعدی از بین می‌رود.
اگر یکی از افزونه‌ها بدون نگهداری است، جایگزینی آن معمولاً از انباشتن workaround بهتر است؛ اما مهاجرت داده و وابستگی قالب باید قبل از حذف سنجیده شود.
اشتباه‌های رایج
- تست چند تغییر هم‌زمان و نامعلوم شدن عامل.
- غیرفعال کردن افزونه امنیتی روی سایت عمومی بدون کنترل جایگزین.
- حذف پوشه افزونه به‌جای deactivate قابل بازگشت.
- فراموش کردن cache، object cache یا OPcache میان دو آزمایش.
- نتیجه‌گیری از صفحه اصلی، در حالی که خطا فقط در checkout یا cron رخ می‌دهد.
- نصب افزونه «حل تداخل» دیگری پیش از فهم علت.
آزمون پذیرش و پیشگیری
پس از اصلاح، سناریوی اصلی و مسیرهای مجاور را با نقش‌های مرتبط تست کنید. لاگ تازه، cron، REST API و عملکرد موبایل را ببینید. به‌روزرسانی‌ها را در staging و به‌صورت دسته‌های کوچک انجام دهید تا پنجره تغییر معلوم بماند. فهرست وابستگی‌ها و مالک هر قابلیت را نیز نگه دارید.
چه زمانی بررسی تخصصی مناسب است؟
اگر تداخل فقط زیر بار، در job زمان‌بندی‌شده یا میان درگاه و webhook رخ می‌دهد، تست روشن/خاموش ساده کافی نیست. سرویس رفع مشکل فنی وردپرس می‌تواند trace، hook و درخواست‌های شبکه را در یک سناریوی کنترل‌شده بررسی کند. اگر خطا پس از ارتقای یک افزونه شروع شده، راهنمای بازیابی پس از آپدیت افزونه را نیز دنبال کنید.
پرسش‌های متداول
آیا Health Check بدون اثر روی کاربران تست می‌کند؟
ابزارهای troubleshooting می‌توانند وضعیت را فقط برای session مدیر تغییر دهند، اما همه cronها، webhookها و cacheها را شبیه‌سازی نمی‌کنند. محدوده ابزار را بشناسید.
آخرین افزونه نصب‌شده همیشه مقصر است؟
نه. ممکن است تغییر جدید یک اشکال قدیمی یا محدودیت مشترک را آشکار کرده باشد. ترکیب نسخه‌ها را بازتولید کنید.
چرا تداخل در staging رخ نمی‌دهد؟
تفاوت داده، PHP، cache، ترافیک، cron یا سرویس خارجی محتمل است. محیط‌ها را با یک checklist مقایسه کنید.
آیا خاموش کردن دائمی یکی از افزونه‌ها کافی است؟
اگر قابلیت آن لازم نیست و حذف داده امن است، ممکن است. در غیر این صورت راه‌حل باید نسخه سازگار یا معماری بدون هم‌پوشانی باشد.