چگونه افزونه مشکل‌ساز وردپرس را پیدا کنیم

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

آماده‌سازی قبل از تشخیص

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

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

شناسایی نشانه‌ها

نشانه‌ها به شما می‌گویند به کدام دستهٔ تعارض نگاه کنید. جدول زیر، شایع‌ترین نشانه‌ها را با گمانهٔ اولیه می‌آورد:

این جدول، اولین نقشهٔ راه است. اگر نشانه‌تان در هیچ‌کدام جا نمی‌گیرد، سراغ گام اول بروید و از حذف دسته‌ای شروع کنید. برای دیدن اثر افزونه‌ها روی سرعت سایت (که گاهی همان نشانهٔ غیرمستقیم است)، افزونه‌ها و سرعت سایت را ببینید.

گام اول: غیرفعال‌سازی دسته‌ای

اگر پیشخوان باز می‌شود، از آنجا؛ اگر نه، از FTP. پنج دسته بسازید: سئو/امنیت، کش/بهینگی، فرم/ارتباط، نمایشی (اسلایدر، گالری)، و «یادتان نیست چرا نصب کردید». یک دسته را با هم غیرفعال کنید، تست بگیرید. اگر مشکل برطرف شد، مقصر در همان دسته است؛ اگر نه، دستهٔ بعدی. این روش «دسته‌ای»، به‌جای «تک‌به‌تک»، در تجربه‌ام در نصف زمان به نتیجه می‌رسد. الگوی دسته‌بندی را همان‌طور که در شناسایی افزونه‌های اضافی آورده‌ام، می‌توانید استفاده کنید.

اگر پیشخوان باز نمی‌شود، از طریق FTP پوشهٔ wp-content/plugins را به plugins-disabled تغییر نام دهید. وردپرس خودش همهٔ افزونه‌ها را غیرفعال می‌کند. سپس نام را برگردانید و از پیشخوان، افزونه‌ها را یک‌به‌یک فعال کنید. این پروتکل، قاتلِ صفحهٔ سفید است.

گام دوم: تست تک‌متغیر

در دسته‌ای که مقصر را پیدا کردید، حالا یکی‌یکی فعال کنید. بین هر فعال‌سازی، سه صفحهٔ کلیدی (خانه، پیشخوان، صفحهٔ فرم یا محصول) را باز کنید. اگر مشکل برگشت، مقصر لو رفته است. یک نکتهٔ عملی: ممکن است دو افزونه با هم تعارض داشته باشند، نه هر کدام به‌تنهایی. اگر تک‌به‌تک هیچ خطایی نداد، ترکیب دوتاییِ شک‌برانگیز را در کنار هم فعال کنید. تجربه‌ام: این حالت دوم، در حدود ۱۵٪ موارد رخ می‌دهد، ولی معمولاً بین دو افزونهٔ هم‌دسته (دو کش، دو minify، دو امنیت) یا بین یک افزونه و خودِ قالب است.

گام سوم: دیباگ با لاگ

اگر تعارض پیچیده است، لاگ‌گیری الزامی است. در 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 را باز کنید. چهار الگو را جستجو کنید: نام تابع یا کلاس، ارجاع به فایل افزونهٔ خاص، هشدار PHP در نسخه‌های جدید، و پیام‌های deprecated. راهنمای کامل خطایابی PHP در پیدا کردن خطاهای کنسول مرورگر برای سمت سرور، در رفع خطای Fatal error PHP و دیباگ کدهای سفارشی وردپرس آمده است.

گام چهارم: تست تعارض با قالب

اگر با غیرفعال‌کردن همهٔ افزونه‌ها، مشکل برطرف شد، مقصر در افزونه‌هاست. اما اگر با همهٔ افزونه‌ها خاموش هم مشکل باقی ماند، مقصر قالب است. برای اطمینان، قالب پیش‌فرض وردپرس (Twenty Twenty-X) را فعال کنید. اگر مشکل برطرف شد، تعارض بین قالب و افزونه یا خودِ قالب است. تفصیل این بخش در بررسی سازگاری قالب با افزونه‌ها آمده است.

پس از یافتن مقصر

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

یافتن مقصر، نصف کار است. تصمیمِ درست پس از یافتن مقصر، نصفِ دیگر — و آنجاست که پروژه‌ها معمولاً وقت تلف می‌کنند.

پیشگیری

• آپدیت مرحله‌ای: یک-دو افزونه در هر نوبت، نه همه با هم.
• بکاپ پیش از هر تغییر: پشتوانهٔ امن، افزونه‌های بکاپ.
• فهرست «افزونه‌های امن»: نگه‌داشتنِ نسخه‌های تست‌شده در پروژه.
• پایش ماهانهٔ لاگ: warningها را جدی بگیرید.
• تست روی استیجینگ قبل از تولید: پروتکلش در بهترین روش تست.
• محدودکردن تعداد افزونه‌ها: مرز سالم در چند افزونه نصب کنیم.

جمع‌بندی

یافتن افزونهٔ مشکل‌ساز، چهار گام دارد: غیرفعال‌سازی دسته‌ای، تست تک‌متغیر، دیباگ با لاگ، و تست تعارض با قالب. اگر امروز فقط یک کار می‌کنید: یک فایل متنی برای لاگ خطاهای سایت خودتان بسازید و ماهی یک بار نگاهی به آن بیندازید؛ این کار، از هر فایروال و افزونهٔ امنیتی ارزان‌تر و مؤثرتر است. تجربه‌تان از یک تعارض که مدتی پنهان ماند، در دیدگاه‌ها ارزشمند است. 🔍