چگونه افزونه‌های مشکل‌ساز را غیرفعال کنیم؟ بی‌آنکه سایت از کار بیفتد

یک شب جمعه، مشتری‌ای زنگ زد که پیشخوان سایتش با پیام «There has been a critical error» بالا نمی‌آید. آخرین کاری که کرده بود، به‌روزرسانی یک افزونهٔ فرم‌ساز بود. هیچ تغییری در قالب یا هسته نداده بود، هیچ کاربر جدیدی اضافه نکرده بود؛ فقط یک دکمهٔ «به‌روزرسانی». و حالا کل سایت از دسترس خارج بود. آن تجربه به من یاد داد که غیرفعال‌کردن یک افزونه، وقتی سایت سالم است، یک کلیک است؛ اما وقتی سایت از کار افتاده، دیگر یک کلیک نیست — یک پروتکل است. این مقاله، همان پروتکلی است که امروز برای هر پروژهٔ وردپرسی اجرا می‌کنم.

چرا افزونه‌ها سایت را می‌شکنند؟

پیش از هر تکنیکی، باید درک کنیم افزونه دقیقاً چه چیزی است. افزونه وردپرس چیست و چگونه افزونه مناسب انتخاب کنیم را پیش‌تر نوشته‌ام؛ خلاصه‌اش این است: افزونه یک بستهٔ کد است که با هوک‌های وردپرس (WordPress Hooks) به هسته وصل می‌شود و قابلیت جدیدی اضافه می‌کند. همین مکانیزمِ هوک، دلیل انعطاف‌پذیری وردپرس است، اما همان دلیل، شکنندگی هم دارد: اگر یک افزونه هوکی را درست فراخوانی نکند، یا با افزونهٔ دیگری برخورد کند، یا در نسخهٔ ناسازگار با نسخهٔ فعلی PHP اجرا شود، می‌تواند کل سایت را از کار بیندازد.

در عمل، افزونه‌ها به چند دلیل رایج سایت را می‌شکنند. یک، به‌روزرسانی خودکار افزونه در زمان نامناسب؛ افزونه‌ای که کدش با نسخهٔ فعلی وردپرس سازگار نیست، بعد از آپدیت، فراخوانی یک تابع ناموجود را انجام می‌دهد و خطای مرگبار (Fatal Error) صادر می‌کند. دو، تعارض بین دو افزونه که هر دو یک هوک مشترک یا یک کلاس PHP مشترک را تعریف می‌کنند. سه، نسخهٔ PHP که روی هاست به‌روز شده و افزونه‌ای که سازگاری‌اش را با نسخهٔ جدید اعلام نکرده. چهار، حجم دادهٔ دیتابیس که با افزونه‌ای بزرگ و بی‌توجه به کوئری‌های بهینه، از حد تحمل هاست عبور کرده — این مورد چهارم، بیشتر از آنکه سایت را از کار بیندازد، آن را کند می‌کند؛ و همان کندی، در بعضی هاست‌ها به‌صورت خطای منبع تمام‌شده ظاهر می‌شود. مکانیزم دقیق این اثر را در تأثیر افزونه‌ها بر سرعت سایت وردپرس با عدد سنجیده‌ام.

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

نشانه‌های یک افزونهٔ مشکل‌ساز

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

• صفحهٔ سفید یا پیام «Critical Error» که بعد از آپدیت افزونه ظاهر شده: این تیزترین نشانه است. اگر بین لحظهٔ آپدیت و لحظهٔ بروز مشکل فاصلهٔ زمانی کمی بوده، احتمال مقصر بودن افزونه بسیار بالاست. این نوع خطا را در خطای سفید شدن صفحه وردپرس مفصل تحلیل کرده‌ام.
• کندی ناگهانی که بعد از فعال‌سازی یک افزونه جدید ظاهر شد: اگر روی بخش‌های خاصی از سایت تأثیر می‌گذارد (مثلاً فقط پیشخوان کند است، یا فقط صفحهٔ محصول)، احتمال بسیار زیادی هست که افزونه‌ای که روی همان صفحات اجرا می‌شود مقصر باشد.
• خطای PHP با نام یک افزونهٔ خاص در متن خطا: وقتی حالت دیباگ (Debug Mode) در وردپرس فعال باشد، خطاها در لاگ ذخیره می‌شوند و مسیر فایلِ خطا، نام پوشهٔ افزونه را افشا می‌کند. روش خواندن این لاگ را در دیباگ کردن کدهای سفارشی وردپرس توضیح داده‌ام.
• ناسازگاری با ویژگی‌های دیگر سایت: مثلاً بعد از فعال‌سازی یک افزونهٔ جدید، فرم تماس جواب نمی‌دهد، یا محصولات در فروشگاه نمایش داده نمی‌شوند، یا پرداخت از کار می‌افتد. این الگو بسیار دقیق به یک تعارض اشاره می‌کند.

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

پیش از هر غیرفعال‌سازی: سه اقدام ضروری

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

۱. یک بکاپ کامل بگیرید

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

۲. وضعیت فعلی را ثبت کنید

قبل از هر تغییری، یک عکس از فهرست افزونه‌های فعال و تنظیمات هر افزونه بگیرید. اگر بعداً مشخص شد که افزونهٔ مقصر، تنظیمات مهمی داشته، می‌توانید از این اطلاعات برای بازیابی استفاده کنید. تجربه‌ام می‌گوید ثبت وضعیت با یک اسکرین‌شات ساده، ارزشش را در پنج دقیقهٔ بعدی نشان می‌دهد.

۳. حالت دیباگ را فعال کنید

در فایل wp-config.php، سه ثابت زیر را اضافه کنید. اولین خط، ثبت خطاها را فعال می‌کند؛ دومین خط، لاگ را در فایل ذخیره می‌کند؛ سومین خط، صفحه را از نمایش خطاها پاک می‌کند تا فقط از طریق فایل بتوانید خطاها را ببینید:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

بعد از این تغییر، فایل wp-content/debug.log محل ثبت خطاها خواهد بود. اگر با ویرایش فایل‌های وردپرس آشنا نیستید، پیشنهاد می‌کنم ابتدا قالب فرزند چیست و چه زمانی به آن نیاز داریم را بخوانید؛ هرچند این تغییر در wp-config به قالب مربوط نیست، اصل «از ویرایش هسته پرهیز کن» در سراسر سایت یکسان است. اگر هم نمی‌خواهید به کد دست بزنید، چگونه کدهای سفارشی به وردپرس اضافه کنیم روش‌های امن را نشان می‌دهد.

پیش از هر تغییر روی سایت زنده، سه سؤال را از خودتان بپرسید: بکاپ دارم؟ وضعیت را ثبت کرده‌ام؟ اگر همه‌چیز خراب شود، چطور برمی‌گردم؟ اگر پاسخ یکی از این‌ها «نمی‌دانم» است، شروع نکنید.

روش اول: غیرفعال‌سازی از پنل مدیریت

اگر پیشخوان سایت بالا می‌آید، این ساده‌ترین و بی‌خطرترین مسیر است. سه گام:

1. به «افزونه‌ها ← افزونه‌های نصب‌شده» بروید.
2. افزونهٔ مشکوک را از فهرست پیدا کنید و روی لینک «غیرفعال» زیر نامش بزنید.
3. صفحه را رفرش کنید و ببینید مشکل حل شده یا نه.

اگر با پیشخوان آشنایی کامل ندارید، پیشنهاد می‌کنم اول آشنایی با پیشخوان وردپرس برای مبتدیان را مرور کنید. این روش یک نکتهٔ مهم دارد: اگر افزونه‌ای که غیرفعال می‌کنید، در زمان خودش با کدهای سفارشی یا وابستگی‌های دیگر گره خورده باشد، غیرفعال‌سازی ساده می‌تواند ظاهر سایت را تغییر دهد — مثلاً اگر افزونهٔ سازندهٔ صفحه بوده، ممکن است شورت‌کدهایی که آن افزونه ساخته بودند، به‌صورت متن خام روی سایت ظاهر شوند. اصول این سناریو را در چگونه افزونه مشکل‌ساز وردپرس را پیدا کنیم با جزئیات بررسی کرده‌ام.

روش دوم: غیرفعال‌سازی از FTP یا فایل‌منیجر

اگر پیشخوان بالا نمی‌آید، باید از یک کانال دیگر به فایل‌ها دسترسی داشته باشید. اگر با سرویس‌های مشابه آشنا نیستید، cPanel چیست و چه کاربردی دارد را ببینید. دو مسیر:

مسیر الف: از فایل‌منیجر هاست

وارد cPanel شوید و File Manager را باز کنید. به پوشهٔ wp-content/plugins/ بروید. پوشهٔ افزونهٔ مشکوک را پیدا کنید. حالا به‌جای حذف، فقط نام پوشه را تغییر دهید — مثلاً plugin-name را به plugin-name.disabled تغییر دهید. وقتی پوشهٔ افزونه از دید وردپرس ناپدید شود، وردپرس آن را به‌طور خودکار غیرفعال می‌کند. با این روش، اگر مقصر آن افزونه نبود، فقط نام پوشه را به حالت اول برمی‌گردانید و همه‌چیز به حالت قبلی برمی‌گردد.

مسیر ب: از FTP

اگر دسترسی به cPanel ندارید یا فایل‌منیجر هاست کار نمی‌کند، از یک کلاینت FTP مثل FileZilla استفاده کنید. آدرس هاست، نام کاربری و رمز FTP را معمولاً از هاست‌تان گرفته‌اید. اتصال برقرار که شد، مسیر /public_html/wp-content/plugins/ یا مسیر مشابه آن را دنبال کنید. یک راهکار کاربردی: اگر مطمئن نیستید کدام افزونه مشکل‌ساز است، نام همهٔ پوشه‌های افزونه را با پیشوند x- عوض کنید (به‌جز افزونه‌های حیاتی مثل افزونهٔ امنیتی) و بعد یکی‌یکی آن‌ها را برگردانید تا مقصر مشخص شود. این روش در پروژه‌های بحرانی، سریع‌ترین مسیر تشخیص بوده.

یک تذکر: تغییر نام پوشه، روی فایل‌های افزونه تغییری نمی‌دهد، ولی اگر افزونه جدول‌های اختصاصی دیتابیس داشته باشد، آن جدول‌ها دست‌نخورده باقی می‌مانند. یعنی وقتی پوشه را برمی‌گردانید، همان تنظیمات قبلی برمی‌گردند. برای همین، این روش در پروژه‌های من محبوب است — بی‌خطر، برگشت‌پذیر، سریع.

روش سوم: غیرفعال‌سازی از دیتابیس

گاهی نه پیشخوان بالا می‌آید، نه دسترسی FTP دارید، یا کلاینت FTP هاست از کار افتاده. در آن صورت، تنها راه باقی‌مانده، دیتابیس است. مسیرش از طریق phpMyAdmin در cPanel یا یک کلاینت دیگر مثل Adminer است. برای این کار باید با دیتابیس و جدول‌های وردپرس آشنا باشید؛ اگر نیستید، بهینه‌سازی دیتابیس وردپرس چیست را به‌عنوان پیش‌زمینه ببینید.

پروسه ساده است اما باید با احتیاط انجام شود:

1. در phpMyAdmin، دیتابیس سایت را باز کنید و جدول wp_options را پیدا کنید.
2. روی «جستجو» بزنید و در ستون option_name عبارت active_plugins را جستجو کنید.
3. روی «ویرایش» رکورد کلیک کنید. مقدار option_value یک ساختار سریالایز‌شده (Serialized) است که با a: شروع می‌شود و طول آرایه را نشان می‌دهد. اینجا نکتهٔ حیاتی است: اگر شما یک افزونه را از این آرایه حذف می‌کنید، باید طول آرایه (عدد بعد از a:) را هم به‌روز کنید. مثلاً اگر مقدار با a:5: شروع می‌شود و شما یک آیتم حذف می‌کنید، باید به a:4: تبدیل شود.

همین یک نکتهٔ کوچک، تیزترین دام این روش است. اگر طول آرایه را به‌روز نکنید، وردپرس بعد از بازیابی، مقدار سریالایز‌شده را نامعتبر می‌بیند و همهٔ افزونه‌ها را خاموش در نظر می‌گیرد. این اتفاق خودش فاجعه نیست، اما شما را در موقعیتی می‌گذارد که همهٔ افزونه‌ها را دستی باید دوباره فعال کنید. اگر دیتابیس شما پسوند جدول‌ها را (مثل wp_) عوض کرده، اسم جدول را دقیقاً مطابق با پیشوند خودتان بجویید.

راه دوم دیتابیسی، بدون دست‌زدن به دیتابیس: می‌توانید در فایل wp-config.php یک ثابت اضافه کنید که همهٔ افزونه‌ها را غیرفعال کند. اما این روش، برای وردپرس پایدار نیست و بعد از رفع مشکل باید حتماً آن را بردارید:

define( 'WP_DISABLE_PLUGINS', true );

توجه: این ثابت در همهٔ نسخه‌های وردپرس پشتیبانی رسمی نمی‌شود. به‌عنوان روش اضطراری مفید است، اما برای بلندمدت توصیه نمی‌کنم. بهترین گزینه، همان روش دوم از FTP است.

در مواقع بحران، بهترین دوست شما دسترسی به فایل است، نه دسترسی به پنل. اگر دسترسی FTP را از قبل ثبت و تست نکرده‌اید، دقیقاً در لحظه‌ای که بیشترین نیاز را دارید، آن را از دست می‌دهید.

چطور افزونهٔ مقصر را پیدا کنیم؟

اگر مطمئن نیستید کدام افزونه مقصر است، سه روش تشخیص را به‌ترتیب سریع‌ترین پیشنهاد می‌کنم:

روش اول: بازهٔ زمانی

به یاد بیاورید که آخرین تغییر سایت چه بوده. آخرین افزونه‌ای که نصب یا به‌روزرسانی کرده‌اید، قوی‌ترین مظنون است. اگر مطمئن نیستید، لاگ آپدیت‌ها را در پیشخوان (اگر باز می‌شود) یا لاگ سرور بررسی کنید. حتی اگر مطمئن نیستید، شروع از آخرین تغییر، معمولاً سریع‌ترین مسیر تشخیص است.

روش دوم: آزمون تقسیم دامنه (Divide and Conquer)

افزونه‌ها را به دو گروه تقسیم کنید؛ نیمی را غیرفعال کنید و سایت را بررسی کنید. اگر مشکل باقی بود، مقصر در نیمهٔ فعال است؛ اگر مشکل حل شد، مقصر در نیمهٔ غیرفعال است. این روش، تعداد آزمون‌ها را از n به log(n) کاهش می‌دهد. برای سی افزونه، شش یا هفت آزمون کافی است.

روش سوم: بررسی لاگ خطا

اگر حالت دیباگ را فعال کرده باشید، فایل wp-content/debug.log معمولاً مسیر فایل و نام تابعی که خطا در آن رخ داده را نشان می‌دهد. این مسیر معمولاً شامل نام پوشهٔ افزونه است. برای تحلیل دقیق‌تر این لاگ، دیباگ کردن کدهای سفارشی وردپرس مرجع مفیدی است.

یک نکتهٔ حرفه‌ای: اگر سایت شما در مرحله‌ای هست که پیشخوان باز می‌شود اما مشکل روی front-end دیده می‌شود، می‌توانید از افزونه‌های «Health Check» استفاده کنید. این افزونه‌ها به شما اجازه می‌دهند تا با یک کلیک، همهٔ افزونه‌ها را برای بازدیدکننده غیرفعال کنید، بدون اینکه روی ادمین تأثیر بگذارد. تجربه‌ام می‌گوید این ابزار در پروژه‌های تیمی، ابزار نجات‌بخش است.

بعد از غیرفعال‌سازی: چه چیزی را انتظار داشته باشیم؟

غیرفعال‌سازی، پایان کار نیست؛ شروع یک مرحلهٔ جدید است. سه اتفاق ممکن است رخ دهد:

اتفاق اول: مشکل حل می‌شود و سایت به حالت عادی برمی‌گردد

این بهترین سناریو است. باید پیش از هر چیز، وضعیت فعلی سایت را دوباره چک کنید — لینک‌ها، فرم‌ها، پرداخت (اگر فروشگاهی است). یک لاگ از اینکه چه چیزی تغییر کرد و چرا، ثبت کنید. اگر افزونه‌ای که غیرفعال کردید، نقش مهمی در سایت داشت، حالا باید تصمیم بگیرید: به‌روزرسانی را برگردانید، به نسخهٔ قبلی برگردید (Rollback)، یا افزونهٔ جایگزین پیدا کنید.

اتفاق دوم: مشکل حل نمی‌شود

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

اتفاق سوم: سایت حل می‌شود، اما ظاهر یا محتوا تغییر می‌کند

اگر افزونه‌ای که غیرفعال کردید، مسئول شورت‌کد یا ساختار بخشی از محتوا بوده، ممکن است بخشی از سایت به‌هم بریزد. این تغییر، در بعضی موارد قابل برگشت است — ولی باید پیش از حذف نهایی افزونه، محتوا را به شکل جدید جایگزین کنید. مثلاً اگر افزونه‌ای که غیرفعال کرده‌اید گالری پروژه بوده، شورت‌کدهایش باید با بلوک‌های گالری گوتنبرگ جایگزین شوند. برای این نوع انتقال، خطای کار نکردن شورت‌کد وردپرس راهنمای مفیدی است.

حذف یا فقط غیرفعال کردن؟

یکی از رایج‌ترین سؤال‌ها: الان که غیرفعال کردم، حذف کنم یا نگه دارم؟ پاسخ صریح من در اکثر موارد: غیرفعال کنید، حذف نکنید — دست‌کم نه در همان لحظه. دلیلش ساده است: حذف افزونه، روی بعضی از بخش‌های دیتابیس اثر می‌گذارد. اگر بعداً معلوم شود که آن افزونه مقصر نبوده و شما نیازش دارید، حذف، شما را در موقعیتی می‌گذارد که باید از صفر نصبش کنید. در حالی‌که غیرفعال کردن، فقط پوشه را از دید وردپرس پنهان می‌کند و کل کد و تنظیمات، دست‌نخورده باقی می‌ماند.

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

یک نکتهٔ فنی مهم: بعضی افزونه‌ها هنگام حذف، پیام «آیا می‌خواهید تمام داده‌های این افزونه هم حذف شود؟» نشان می‌دهند. اگر این پیام را تأیید کنید، تمام جدول‌ها و آپشن‌های افزونه پاک می‌شوند. پس در این تصمیم دقت کنید. تجربه‌ام می‌گوید در اکثر پروژه‌ها، حذف کامل داده‌های افزونه‌ای که فقط چند روز غیرفعال بوده، تصمیم عجولانه است.

پیشگیری: پروتکلی که همه‌چیز را راحت‌تر می‌کند

در پروژه‌های خودم، پروتکل زیر را پیش از هر آپدیت یا نصب افزونه اجرا می‌کنم. این پروتکل، در اکثر موارد، جلوی بحران را می‌گیرد:

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

با همین پنج مورد، در چند سال گذشته، تعداد بحران‌های آپدیت در پروژه‌های من به کمتر از یک در سال رسیده. پیشگیری، همیشه ارزان‌تر از درمان است.

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

اشتباهات رایج در غیرفعال‌سازی افزونه

پنج اشتباه که در بازبینی پروژه‌ها زیاد دیده‌ام:

• غیرفعال‌سازی بدون بکاپ: سریع‌ترین راه تبدیل یک مشکل کوچک به یک بحران بزرگ. هر تغییری روی سایت زنده، باید با بکاپِ تازه انجام شود.
• حذف فوری به‌جای غیرفعال کردن: حذف، در بعضی افزونه‌ها به‌معنای از دست رفتن تنظیمات است. اول غیرفعال کنید، بعد از مدتی تصمیم بگیرید.
• غیرفعال‌سازی همهٔ افزونه‌ها یک‌جا: حتی اگر مشکل حل شود، نمی‌فهمید کدام یک مقصر بوده. روش تست دو‌به‌دو (Divide and Conquer) خیلی بهتر جواب می‌دهد.
• فراموش‌کردن بازگردانی نام پوشه: اگر پوشهٔ افزونه را با نام جدید (مثل .disabled) غیرفعال کردید، بعد از رفع مشکل، نام را برگردانید. در غیر این صورت، افزونه از دید شما پنهان می‌ماند و اگر مشتری از شما بپرسد «چرا این افزونه نصب نیست»، نمی‌دانید چه اتفاقی افتاده.
• رها کردن سایت در حالت دیباگ: اگر دیباگ را فعال کردید، بعد از رفع مشکل باید آن را خاموش کنید. سایت با دیباگ روشن، خطاهای PHP را روی صفحه نمایش می‌دهد که خودش یک آسیب‌پذیری امنیتی است.

خط پایان: از واکنش به پیشگیری

غیرفعال‌سازی افزونه، تکنیکی است که هر کسی که با وردپرس کار می‌کند، باید بلد باشد. اما تجربهٔ من نشان داده که ارزش واقعی، نه در تکنیک، بلکه در عادت نهفته است: بکاپ قبل از هر تغییر، آپدیت یکی‌یکی، تست روی استجینگ، و داشتن یک پروتکل روشن برای مواقع بحرانی. اگر این چهار عادت را بسازید، تعداد دفعاتی که در موقعیت «سایت از کار افتاده» قرار می‌گیرید، به‌شدت پایین می‌آید. تکنیک، در لحظهٔ بحران به‌کار می‌آید؛ عادت، جلوی رسیدن به بحران را می‌گیرد.

اگر تجربه‌ای از یک بحران افزونه دارید — به‌خصوص افزونه‌ای که با آپدیت شکسته و شما را غافلگیر کرده — خوشحال می‌شوم در دیدگاه‌ها بخوانم. آن افزونه چه بود و چطور مشکل را حل کردید؟ همان تجربه، برای خوانندهٔ بعدی که وسط یک بحران مشابه است، از هر مقالهٔ مرجع مفیدتر خواهد بود. 🔧