چگونه خطای افزونه وردپرس را پیدا کنیم؟
چرا سایت شما بعد از یک آپدیت ناگهان می‌شکند و هیچ پیامی هم نمیدهد؟ در این راهنما، پروتکل گامبهگام پیدا کردن افزونه‌ی مقصر را با روش حذف دستهای و لاگ‌گیری عملی، مرحلهبهمرحله بررسی می‌کنم.
در پشتیبانی سایت‌های وردپرسی، یکی از پرتکرارترین تماس‌ها این است: «سایتم کار نمی‌کند، ولی نمی‌دانم مشکل از کجاست». و در نود درصد مواقع، وقتی وارد پیشخوان می‌شوم، الگو تکراری است: سایت صبح سالم بوده، بعد از یک آپدیت خودکار یا نصب یک افزونه‌ی جدید، سفید شده یا کند شده یا بخش‌هایی از آن از کار افتاده. آنچه این لحظه را ترسناک می‌کند، این است که هیچ افزونه‌ای نمی‌گوید «من مقصرم». تنها راه، یک عیب‌یابیِ سیستماتیک است که مقصر را از میان ده‌ها افزونه بیرون بکشد. این راهنما، همان پروتکل عیب‌یابی است که در پروژه‌های واقعی به‌کار می‌برم — نه یک چک‌لیست تئوری.
اگر تازه با افزونه‌ها آشنا شده‌اید، پیشنهاد می‌کنم اول افزونه وردپرس چیست و چگونه افزونه مناسب انتخاب کنیم و آموزش نصب افزونه در وردپرس برای مبتدیان را بخوانید. اگر قبلاً با افزونه‌ها کار کرده‌اید ولی در لحظه‌ی خرابی نمی‌دانید از کجا شروع کنید، این مقاله برای شماست.
خطای افزونه، در چه شکل‌هایی ظاهر می‌شود؟
قبل از ورود به پروتکل، بیایید ببینیم «خطای افزونه» در عمل چه شکل‌هایی می‌گیرد. تجربه‌ی من در پروژه‌های واقعی نشان می‌دهد که شش سناریو، تقریباً همه‌ی موارد را پوشش می‌دهند:
| نشانه | محتمل‌ترین ریشه |
|---|---|
| صفحه‌ی سفید یا سایت با هیچ پیامی بالا نمی‌آید | خطای Fatal PHP در یک افزونه |
| بخش‌هایی از سایت کار نمی‌کند (منو، فرم، گالری) | تضاد بین دو افزونه یا بین افزونه و قالب |
| پیشخوان باز می‌شود ولی front-end مشکل دارد | افزونه‌ای که فقط در فرانت اجرا می‌شود |
| سایت به‌طور تصادفی کند می‌شود | افزونه با کوئری‌های سنگین یا cron مشکل‌دار |
| بعد از آپدیت، بخشی از قابلیت‌ها از بین رفته | ناسازگاری نسخه یا تابع حذف‌شده |
| پیام‌های خطای کوتاه در بالا یا پایین صفحه | خطای Warning یا Notice در یک افزونه |
هر سناریو، نشانه‌ای برای پیدا کردن دامنه‌ی مسئله است. مثلاً اگر front-end کار می‌کند ولی بخش‌هایی از پیشخوان نه، احتمالاً افزونه‌ای است که فقط روی admin اجرا می‌شود — نه یک افزونه‌ی عمومی. یا اگر کندی به‌طور تصادفی رخ می‌دهد، احتمالاً مسئله در cron یا کوئری‌های زمان‌بندی‌شده است. جزئیات مربوط به اثر افزونه‌ها بر سرعت، در افزونه‌های وردپرس چگونه روی سرعت سایت اثر می‌گذارند آمده است.
یک نکته‌ی مهم: این شش نشانه، در نود درصد موارد یکی از این سه ریشه را دارند: خطای سینتکس PHP، تضاد نسخه‌ها، یا تضاد بین دو افزونه. اگر این سه را در ذهن داشته باشید، عیب‌یابی سریع‌تر می‌شود.
افزونه‌ی خراب، مثل مسافری است که در جلسه‌ی رسمی، صدایش را کسی نمی‌شنود ولی تمام جلسه را مختل می‌کند. باید یکی‌یکی از اتاق بیرونشان کنی تا مقصر معلوم شود.
قاعده‌ی اول: هرگز روی سایت زنده دیباگ نکنید
این مهم‌ترین قاعده‌ای است که در تمام این راهنما می‌گویم. دیباگ روی سایت زنده، مثل جراحی در خیابان است. اگر تازه با محیط لوکال یا استجینگ آشنا نیستید، پیشنهاد می‌کنم اول توسعه وردپرس با محیط لوکال چگونه انجام می‌شود را بخوانید. محیط لوکال، به شما اجازه می‌دهد بدون استرس، همه‌ی افزونه‌ها را غیرفعال کنید، سایت را خراب کنید، و دوباره بسازید.
اگر استجینگ یا لوکال ندارید، دو کار حداقلی انجام دهید:
- بکاپ کامل بگیرید: قبل از هر تغییری، از فایل‌ها و دیتابیس نسخه‌ی پشتیبان تهیه کنید. مسیر در چگونه از وردپرس بکاپ بگیریم؟ راهنمای مبتدیان.
- در ساعات کم‌ترافیک کار کنید: اگر مجبورید روی سایت زنده تغییر دهید، در ساعات کم‌ترافیک انجام دهید. حتی در این حالت، قبل از غروب، یک بکاپ بگیرید.
یک تجربه‌ی تلخ که همیشه به‌عنوان هشدار تعریف می‌کنم: در پروژه‌ای، به‌دلیل عجله، بدون بکاپ شروع به عیب‌یابی کردم. در میانه‌ی کار، فایل functions.php قالب را خراب‌تر کردم و مجبور شدم سایت را از صفر بازسازی کنم. از آن روز، هرگز بدون بکاپ دست به دیباگ نمی‌زنم — حتی روی پروژه‌های شخصی خودم.
گام اول: غیرفعال‌سازی سریع همه‌ی افزونه‌ها
اولین گام، یک تست ساده است: همه‌ی افزونه‌ها را غیرفعال کنید و ببینید آیا سایت درست می‌شود. اگر سایت با همه‌ی افزونه‌های غیرفعال سالم بالا آمد، یک افزونه (یا چند افزونه در ترکیب) مقصر است. اگر با افزونه‌های غیرفعال هم سایت خراب بود، مسئله در افزونه نیست — ممکن است قالب، هسته‌ی وردپرس، یا پیکربندی سرور باشد.
اگر به پیشخوان دسترسی دارید، از مسیر «افزونه‌ها ← افزونه‌های نصب‌شده»، همه‌ی افزونه‌ها را انتخاب و غیرفعال کنید. اگر پیشخوان باز نمی‌شود یا خطای 500 می‌دهد، به سه روش زیر مراجعه کنید.
سه روش برای غیرفعال‌سازی، وقتی پیشخوان کار نمی‌کند
وقتی خطای افزونه به‌قدری جدی است که پیشخوان هم باز نمی‌شود، سه راه‌حل در اختیار دارید. هر کدام، سناریوی خاصی دارد:
روش اول: تغییر نام پوشه‌ی plugins از FTP
سریع‌ترین و قاطع‌ترین روش: به پوشه‌ی wp-content/plugins بروید و نامش را به plugins-disabled تغییر دهید. این کار، همه‌ی افزونه‌ها را به‌طور یک‌جا غیرفعال می‌کند. اگر سایت بعد از این تغییر بالا آمد، یک افزونه مقصر است. حالا پوشه را به نام اصلی برگردانید و از پیشخوان، افزونه‌ها را یکی‌یکی فعال کنید تا مقصر مشخص شود.
یک نکته‌ی مهم: این روش را با احتیاط استفاده کنید. اگر هاست‌تان لیست سفید دارد (بعضی هاست‌ها فایل mu-plugins را اجبار می‌کنند)، این روش ممکن است آن‌ها را هم تحت تأثیر قرار دهد. در این حالت، از روش سوم استفاده کنید.
روش دوم: غیرفعال‌سازی از طریق دیتابیس
اگر به FTP دسترسی ندارید ولی به phpMyAdmin دارید، می‌توانید از این روش استفاده کنید. در جدول wp_options، ردیف active_plugins را پیدا کنید و مقدارش را خالی کنید. این کار، همه‌ی افزونه‌ها را غیرفعال می‌کند.
UPDATE wp_options SET option_value = '' WHERE option_name = 'active_plugins';قبل از اجرای این کوئری، حتماً از دیتابیس بکاپ بگیرید. یک اشتباه کوچک در این کوئری، می‌تواند سایت را کاملاً از کار بیندازد.
روش سوم: غیرفعال‌سازی از طریق افزونه‌ی مدیریت خارجی
بعضی هاست‌ها یا افزونه‌های امنیتی، امکان «غیرفعال‌سازی در حالت اضطراری» را از خارج پیشخوان می‌دهند. مثلاً افزونۀ Wordfence، امکان خاموشیِ اضطراری را دارد که از URL خاصی در دسترس است. مسیر کامل این ابزارها در بهترین افزونه‌های امنیتی وردپرس برای محافظت از سایت آمده است.
سه روش بالا، بسته به سطح دسترسی شما انتخاب می‌شوند. در تجربه‌ی خودم، روش اول سریع‌ترین است ولی روش دوم امن‌تر، و روش سوم کم‌ریسک‌ترین.
گام دوم: روش تقسیم دودویی (Binary Search)
حالا فرض کنید سایت با همه‌ی افزونه‌های غیرفعال سالم است و باید مقصر را پیدا کنید. دو روش وجود دارد: فعال‌سازی یکی‌یکی، یا تقسیم دودویی. دومی، بسیار سریع‌تر است.
روش تقسیم دودویی:
- افزونه‌ها را به دو نیمه تقسیم کنید.
- نیمه‌ی اول را فعال کنید و سایت را باز کنید.
- اگر سایت خراب شد، مقصر در همین نیمه است؛ اگر نشد، در نیمه‌ی دوم.
- نیمه‌ی مقصر را به دو نیمه‌ی کوچک‌تر تقسیم کنید و مراحل را تکرار کنید.
- بعد از چند مرحله، به یک افزونه‌ی تنها می‌رسید.
مثال عملی با ۱۶ افزونه:
- مرحله‌ی اول: ۸ + ۸ — با فعال‌کردن ۸ تای اول، یک طرف مشخص می‌شود.
- مرحله‌ی دوم: ۴ + ۴ — یک چهارم مقصر مشخص می‌شود.
- مرحله‌ی سوم: ۲ + ۲ — یک دو‌تایی مقصر.
- مرحله‌ی چهارم: ۱ + ۱ — مقصر پیدا می‌شود.
با ۱۶ افزونه، به‌جای ۱۶ مرحله، فقط ۴ مرحله نیاز دارید. این تفاوت، در عیب‌یابی روی سایت زنده (که هر مرحله زمان می‌برد) بسیار مهم است. یادآوری می‌کنم که این کار را روی محیط لوکال یا استجینگ انجام دهید — نه سایت زنده.
یک نکته‌ی ظریف: اگر در مرحله‌ی اول، سایت با هر دو نیمه سالم بود، یعنی مشکل از یک افزونه نیست؛ ممکن است تضاد بین دو افزونه در دو نیمه‌ی مختلف باشد. این نوع تضاد، در ادامه بحث می‌شود.
تقسیم دودویی، همان روشی است که در برنامه‌نویسی برای جستجو در آرایه‌های مرتب استفاده می‌شود. در عیب‌یابی افزونه هم همان منطق کار می‌کند: هر مرحله، نصف فضای جستجو را حذف می‌کند.
گام سوم: خواندن لاگ خطا
روش تقسیم دودویی، کاربردی است ولی زمان می‌برد. اگر می‌خواهید سریع‌تر باشید، از لاگ خطا استفاده کنید. برای این کار، در فایل wp-config.php این چهار خط را اضافه کنید:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SCRIPT_DEBUG', true );سپس سایت را باز کنید و فایل wp-content/debug.log را ببینید. این فایل، پر از پیام‌های دقیق خطاهای PHP است. سه الگویی که در پیدا کردن افزونه‌ی مقصر کمک می‌کنند:
- مسیر فایل: خطا از کدام پوشه آمده؟ اگر مسیر شامل
/wp-content/plugins/است، افزونه مقصر است و نام پوشه، نام افزونه. - شماره خط: دقیقاً کدام خط مشکل داشته.
- نوع خطا: Fatal Error جدی است، Warning متوسط، Notice کم.
مسیر کامل خواندن لاگ و تفسیر آن در چگونه خطای قالب را در وردپرس دیباگ کنیم و رفع خطای Parse error در فایل functions.php آمده است — منطق مشترک است، تفاوت فقط در مسیر فایل است.
یک تجربه‌ی شخصی: در پروژه‌ای، سایت به‌طور تصادفی خطا می‌داد ولی در لاگ، همه‌چیز سالم به نظر می‌رسید. بعد از بررسی دقیق‌تر، متوجه شدم که یک افزونه‌ی آمار، در هر صفحه یک کوئری سنگین به دیتابیس می‌زند که در اوج ترافیک، timeout می‌شود. آن افزونه، هیچ خطای PHP نمی‌داد — فقط یک «Warning: Query timeout» در لاگ دیتابیس بود، نه در debug.log. این نوع مسئله، فقط با نگاه به لایه‌های مختلف پیداش می‌شود.
گام چهارم: تست سازگاری نسخه‌ها
یکی از شایع‌ترین دلایل خطای افزونه، ناسازگاری نسخه است. سه سطح سازگاری که باید چک کنید:
- نسخه‌ی PHP: اگر افزونه‌ای روی PHP 7.4 نوشته شده و سایت شما روی PHP 8.2 است، احتمال خطا بالاست. مسیر در خطای عدم سازگاری افزونه با نسخه PHP.
- نسخه‌ی وردپرس: اگر افزونه‌ای روی وردپرس 5.x نوشته شده و سایت شما روی نسخه‌ی 6.6 است، ممکن است از توابع منقضی استفاده کند. مسیر در خطای عدم پشتیبانی افزونه از نسخه وردپرس.
- نسخه‌ی خود افزونه: اگر از نسخه‌ی قدیمی افزونه استفاده می‌کنید، احتمال آسیب‌پذیری بالاست. مسیر در خطای بروزرسانی افزونه و راه حل آن.
روش تست سازگاری در محیط لوکال، پیش از هر آپدیت، در چگونه سازگاری افزونه‌های وردپرس را بررسی کنیم آمده است. این روش، در پروژه‌های زیادی از فاجعه‌ی بزرگ‌تری جلوگیری کرده — چون وقتی افزونه‌ای روی محیط تست می‌شکند، در سایت زنده خرابی نده.
گام پنجم: تشخیص تضاد بین دو افزونه
بعضی وقت‌ها، دو افزونه به‌تنهایی سالم هستند ولی در ترکیب، سایت را می‌شکنند. این نوع تضاد، در روش تقسیم دودویی، دیده نمی‌شود — چون هر افزونه در نیمه‌ی جداگانه است. برای پیدا کردن این نوع تضاد، از روش زیر استفاده کنید:
- همه‌ی افزونه‌ها را غیرفعال کنید.
- افزونه‌ی اول را فعال کنید و سایت را باز کنید.
- افزونه‌ی دوم را فعال کنید و سایت را باز کنید.
- اگر سایت خراب شد، تضاد بین افزونه‌ی اول و دوم است.
- اگر نشد، افزونه‌ی سوم را فعال کنید و مراحل را تکرار کنید.
این روش، زمان‌بر است ولی در نهایت، تضاد را پیدا می‌کند. مسیر دقیق‌تر این فرآیند در رفع خطای تضاد افزونه‌ها در وردپرس آمده است. یک تجربه‌ی واقعی: در پروژه‌ای، تضاد بین یک افزونه‌ی سئو و یک افزونه‌ی کش باعث می‌شد که سایت در ساعات اوج، خطای 500 بدهد. هر کدام به‌تنهایی سالم بودند ولی در ترکیب، دو لایه‌ی کش روی هم می‌افتادند و به سقف منابع می‌رسیدند.
گام ششم: بعد از پیدا کردن مقصر، چه کنیم؟
حالا که افزونه‌ی مقصر را پیدا کرده‌اید، سه تصمیم در پیش دارید:
| تصمیم | شرایط | اقدام |
|---|---|---|
| حذف | افزونه غیرضروری است | حذف کامل، همراه با پاک‌سازی ردی‌های دیتابیس |
| جایگزینی | افزونه ضروری است ولی مشکل‌دار | جستجوی جایگزین با امتیاز بالاتر |
| بازگشت به نسخه‌ی قبل | آپدیت اخیر مقصر است | نصب نسخه‌ی قبلی از سازنده و انتظار برای patch |
سه قاعده‌ی مهم در این تصمیم:
- اگر افزونه ضروری نیست، حذف کنید. هر افزونه‌ی نصب‌شده، یک ریسک امنیتی و یک بارِ سرعت است. مسیر حذف امن در چگونه افزونه خراب را بدون از دست دادن تنظیمات حذف کنیم.
- اگر افزونه ضروری است، جایگزین پیدا کنید. اما جایگزین را روی محیط لوکال با همه‌ی افزونه‌های فعلی تست کنید — چون یک افزونه‌ی سالم جایگزین، می‌تواند با افزونه‌ی دیگری تضاد داشته باشد.
- اگر آپدیت مقصر است، به نسخه‌ی قبل برگردید. نسخه‌ی قبلی را از مخزن یا از سایت سازنده بگیرید و منتظر بمانید تا patch منتشر شود. مسیر در خطای بروزرسانی افزونه و راه حل آن.
یک نکته‌ی مهم: پس از حذف افزونه، حتماً یک بکاپ تازه بگیرید و آن را در کنار بکاپ قبلی نگه دارید. اگر بعد از حذف، مسئله‌ی دیگری پیش آمد، می‌توانید به نسخه‌ی قبل برگردید. مسیر کامل در چند نسخه بکاپ باید نگهداری کنیم آمده است.
پیشگیری: چطور از این درد در آینده دوری کنیم؟
عیب‌یابی، درمان است. ولی بهتر از درمان، پیشگیری است. چهار عادت که در پروژه‌های بلندمدت، خطاهای افزونه را به‌طور محسوس کم می‌کنند:
- آپدیت‌ها را روی استجینگ انجام دهید، بعد روی سایت زنده. این ساده‌ترین کار، نیمی از فاجعه‌های افزونه را حذف می‌کند.
- افزونه‌ها را از منابع رسمی نصب کنید. نسخه‌های نال و کرک‌شده، احتمال آلودگی و خطا دارند. مسیر در چگونه یک افزونه وردپرس مطمئن دانلود کنیم.
- لیست افزونه‌های خود را کوتاه نگه دارید. هر شش ماه، فهرست را مرور کنید و هر افزونه‌ای که در سه ماه گذشته «لم نخورده»، کاندیدای حذف است. فهرست ضروری‌ها در بهترین افزونه‌های ضروری وردپرس برای هر سایت.
- بعد از هر آپدیت، سایت را دستی چک کنید. نه فقط پیشخوان، بلکه فرم تماس، صفحه‌ی محصول، چک‌اوت و منو. اگر بعد از هر آپدیت این پنج دقیقه را بگذارید، خرابی‌ها قبل از این‌که بزرگ شوند، پیدا می‌شوند. مسیر تست در بهترین روش تست قالب وردپرس قبل از انتشار و تست و دیباگ پروژه‌های توسعه وردپرس آمده است.
این چهار عادت، در تجربه‌ی خودم، خطاهای افزونه را به‌طور محسوس کم کرده‌اند. تفاوت بین سایتی که هر ماه به‌دنبال مقصر می‌گردد و سایتی که سال‌ها بی‌دردسر کار می‌کند، معمولاً در همین چهار عادت است — نه در کیفیت افزونه‌ها.
اشتباهاتی که عیب‌یابی را به فاجعه تبدیل می‌کنند
در تجربه‌ی خودم، این پنج اشتباه را بیشتر از همه دیده‌ام:
| اشتباه | پیامد |
|---|---|
| دیباگ بدون بکاپ | در بدترین حالت، از دست دادن کل سایت |
| حذف فوری افزونه‌ی مشکوک | اگر افزونه واقعاً مقصر نبود، قابلیت‌های سایت از دست می‌رود |
| عیب‌یابی روی سایت زنده در ساعات اوج | خرابی بیشتر، کاربران ناراضی |
| فعال‌کردن همه‌ی افزونه‌ها یک‌جا بعد از پایان عیب‌یابی | مسئله ممکن است برگردد و مقصر معلوم نشود |
| حذف افزونه بدون پاک‌سازی ردی‌های دیتابیس | باقی‌ماندن داده‌های بی‌استفاده، کندی تدریجی |
یک قاعده‌ی طلایی که همیشه یادآور می‌شوم: هر تغییر، یک ثبت. یعنی هر بار که افزونه‌ای را فعال یا غیرفعال می‌کنید، در یک فایل متنی یادداشت کنید. این یادداشت، اگر عیب‌یابی طولانی شود، نقشه‌ی بازگشت شماست. اگر فهرست کامل‌تری می‌خواهید، اشتباهات رایج هنگام نصب افزونه وردپرس و اشتباهات رایج در توسعه قالب و افزونه وردپرس را در کنار این بحث بخوانید.
نگاهی از بالاتر: عیب‌یابی به‌مثابه یک فرایند سیستماتیک
برای کسی که سال‌ها روی سیستم‌های پیچیده کار کرده، «عیب‌یابی افزونه» در نگاه اول یک فعالیت موردی است. اما اگر عمیق‌تر نگاه کنید، این کار یک فرایند سیستماتیک با چهار مرحله‌ی مشخص است — همان فرایندی که در SRE و DevOps هم به‌کار می‌رود:
- مرحله‌ی ۱ — مشاهده (Observation): قبل از هر تغییری، دقیقاً ببینید چه اتفاقی افتاده. کدام صفحه، کدام مرورگر، کدام لحظه، کدام کاربر. یک عیب‌یابِ حرفه‌ای، هشتاد درصد وقت خود را صرف مشاهده می‌کند و بیست درصد صرف تغییر. اکثر افراد مبتدی، این نسبت را معکوس می‌کنند و به همین دلیل، عیب‌یابی‌شان طولانی می‌شود.
- مرحله‌ی ۲ — فرضیه‌سازی (Hypothesis): بر اساس مشاهدات، یک یا دو فرضیه‌ی محتمل بسازید. فرضیه‌ی بدون مشاهده، فقط حدس است. مثلاً «سایت بعد از آپدیت افزونه‌ی سئو خراب شده» یک فرضیه است، ولی «سایت خراب است، حتماً افزونه‌ی سئو مقصر است» یک حدس.
- مرحله‌ی ۳ — آزمون کنترل‌شده (Isolation): هر فرضیه را با یک آزمون جداگانه بسنجید. یک تغییر در یک زمان. اگر هم‌زمان سه افزونه را غیرفعال کنید، نه می‌فهمید کدام مؤثر بوده، نه می‌توانید مطمئن باشید مسئله برگشته یا نه.
- مرحله‌ی ۴ — تأیید (Verification): بعد از یافتن مقصر و رفع آن، حتماً تأیید کنید که مشکل واقعاً حل شده. تأیید، بخشی جداگانه از عیب‌یابی است، نه بخشی از رفع. اگر این مرحله را حذف کنید، ممکن است مسئله در شرایط خاصی برگردد و شما هیچ‌وقت متوجه نشوید.
در چارچوب‌های جدی مهندسی، این چهار مرحله را با مفهوم «Root Cause Analysis» می‌شناسند: تحلیل ریشه‌ای، نه فقط رفع سطحی. تفاوت بین کسی که «افزونه‌ی مقصر را حذف کردم و سایت درست شد» می‌گوید و کسی که «افزونه‌ی مقصر را حذف کردم، دلیل ریشه‌ای‌اش هم این بود که نسخه‌ی PHP سایت قدیمی بود، و آن را هم به‌روز کردم» می‌گوید، در همین نگاه است. اولی، سایت را تا حادثه‌ی بعدی سالم نگه می‌دارد؛ دومی، آن را برای سال‌ها سالم می‌کند.
یک نکته‌ی مهم دیگر که در پروژه‌های بلندمدت یاد گرفته‌ام: عیب‌یابی، مهارتی است که با تکرار قوی‌تر می‌شود، نه با خواندن. می‌توانید ده مقاله درباره‌ی عیب‌یابی بخوانید، ولی اگر یک‌بار روی یک سایت واقعی، تقسیم دودویی را اجرا نکنید، در لحظه‌ی بحران، دستتان می‌لرزد. توصیه‌ی من: هر پروژه‌ای که تمام می‌کنید، در محیط لوکال خودتان، عمداً یک افزونه را خراب کنید و مراحل عیب‌یابی را تمرین کنید. این تمرین، در روز واقعی، ساعت‌ها وقت شما را ذخیره می‌کند. برای درک عمیق‌تر این نگاه، ساختار هسته وردپرس چگونه کار می‌کند، هوک‌های وردپرس چیستند و چگونه کار می‌کنند و چگونه یک پروژه توسعه وردپرس را ساختاربندی کنیم را در کنار این بحث بخوانید.
یک کلام آخر: عیب‌یابی، مهارتی که با تکرار قوی‌تر می‌شود
خلاصه‌ی این راهنما در یک جمله: پیدا کردن افزونه‌ی مقصر، یک شکار سیستماتیک است، نه یک حدس. اول بکاپ بگیرید، بعد همه را غیرفعال کنید، بعد با تقسیم دودویی یا لاگ‌گیری، مقصر را پیدا کنید. اگر روش تقسیم دودویی را به‌خاطر بسپارید، با ۱۶ افزونه، فقط ۴ مرحله نیاز دارید — نه ۱۶.
قدم عملی امشب‌تان: در محیط لوکال یا استجینگ، همه‌ی افزونه‌ها را غیرفعال کنید و یکی‌یکی فعال کنید. حتی اگر سایت‌تان سالم است، همین تمرین ده‌دقیقه‌ای، شما را با رفتار هر افزونه در لایه‌ی عیب‌یابی آشنا می‌کند. روزی که به آن نیاز دارید، آماده خواهید بود.
اگر تجربه‌ای از پیدا کردن افزونه‌ی مقصر دارید — چه با موفقیت سریع، چه با ساعت‌ها سردرگمی — برای من جذاب است بدانم کدام روش (تقسیم دودویی، لاگ‌گیری، یا تست سازگاری) بیشترین کمک را در پروژه‌ی شما کرد. تجربه‌تان را در دیدگاه‌ها بنویسید؛ مخصوصاً اگر الگوی جدیدی برای عیب‌یابی کشف کرده‌اید که در این راهنما نبوده، آن هم داده‌ای است که برای نفر بعدی، ساعت‌ها وقت ذخیره می‌کند. 🛠️
نویسنده در وردپرس کار.