خطای عدم فعال شدن افزونه در وردپرس
چرا افزونهتان فعال نمی‌شود یا بلافاصله بعد از فعال‌سازی سایت را از کار میاندازد؟ این راهنما دوازده علت ریشه‌ای خطای فعال‌سازی افزونه در وردپرس — از ناسازگاری PHP و حافظه کم تا مجوز فایل و محدودیت سرور — را با راه‌حل گام‌به‌گام بررسی می‌کند.
یادم می‌آید اولین باری که یک افزونه روی سایت مشتری فعال نشد، ساعت ۱۱ شب بود و من ساده‌ترین کار ممکن را کردم: دکمه فعال‌سازی را چندین بار پشت سر هم زدم. نتیجه‌اش پیام کوتاهی بود که کل سایت را سفید کرد. آن شب فهمیدم فعال‌سازی افزونه در وردپرس، در ظاهر یک کلیک ساده است، ولی در واقع لحظه‌ای است که کد جدید در عمیق‌ترین لایه‌های سایت اجرا می‌شود. از آن روز، هر بار که افزونه‌ای فعال نمی‌شود، مسیر مشخصی را طی می‌کنم که در این مقاله به آن پرداخته‌ام.
چرا فعال‌سازی افزونه نقطه‌ای حساس در وردپرس است؟
در نگاه اول، فعال‌سازی افزونه شبیه یک کلید روشن/خاموش است. ولی در واقع لحظه‌ای است که وردپرس اولین بار کد افزونه را اجرا می‌کند: توابعش ثبت می‌شوند، هوک‌هایش به هسته وصل می‌شوند، جدول‌هایش ساخته می‌شوند و تنظیمات پیش‌فرضش در دیتابیس نوشته می‌شوند. اگر هر کدام از این مراحل با شکست مواجه شود، فعال‌سازی نیمه‌کاره می‌ماند و همان چیزی اتفاق می‌افتد که همه ما از آن می‌ترسیم: سایت از کار می‌افتد یا افزونه در حالت معلق می‌ماند.
نکته‌ای که در افزونه وردپرس چیست و چگونه انتخاب کنیم توضیح داده‌ام این است که هر افزونه در واقع یک قطعه کد اجرایی است که به هسته وردپرس متصل می‌شود؛ و مثل هر اتصال دیگری، اگر یکی از دو طرف با دیگری سازگار نباشد، اتصال شکسته می‌شود. همین سازوکار، ریشه بیشتر خطاهای فعال‌سازی است. برای درک عمیق‌تر این لایه، مقاله تأثیر افزونه‌ها بر سرعت و پایداری سایت هم تصویر جامعی از رفتار افزونه‌ها می‌دهد.
فعال‌سازی افزونه، اولین قرار حضوری با کد آن است. هر خطای پنهانی در آن کد، دقیقاً همان لحظه خودش را نشان می‌دهد.
الگوی عیب‌یابی که در پروژه‌ها استفاده می‌کنم
پیش از ورود به فهرست علت‌ها، بد نیست الگویی را ببینید که خودم در همه پرونده‌های فعال‌سازی طی می‌کنم. این الگو، بی‌هدف شلیک نمی‌کند؛ هر گام، نیمی از فهرست مظنون‌ها را حذف می‌کند:
- اول از همه، فایل
wp-content/debug.logرا نگاه می‌کنم تا پیام خطای واقعی را ببینم. - افزونه را از طریق FTP غیرفعال می‌کنم تا سایت برگردد و پنل قابل استفاده شود.
- نسخه PHP، نسخه وردپرس و حافظه مجاز را چک می‌کنم.
- افزونه‌ها و قالب را در محیط استجینگ یا لوکال یکی‌یکی خاموش می‌کنم تا نقطه تعارض مشخص شود.
- اگر هنوز مظنون باقی ماند، سراغ مجوز فایل، افزونه‌های PHP و محدودیت‌های سرور می‌روم.
در نود درصد پرونده‌هایی که تا حالا دیده‌ام، مقصر در پنج گام اول مشخص شده. بقیه پرونده‌ها معمولاً محدودیت هاست یا نبود یک اکستنشن PHP بوده است.
علت اول: خطای کشنده PHP بعد از فعال‌سازی
شایع‌ترین سناریو این است: دکمه فعال‌سازی را می‌زنید، سایت سفید می‌شود یا خطای Fatal error می‌آید. علت رایج، یک خطای داخلی در کد افزونه است که با نسخه فعلی PHP سایت شما سازگار نیست یا به تابعی ارجاع می‌دهد که وجود ندارد. اول از همه باید خطای واقعی را ببینید، نه فقط صفحه سفید. در فایل wp-config.php این سه خط را فعال کنید:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );بعد از آن، فایل wp-content/debug.log را باز کنید. معمولاً یک خطای دقیق با نام فایل و شماره خط پیدا می‌کنید. اگر افزونه کد شکسته دارد، راه‌حل جایگزینی است نه تعمیر؛ ولی اگر خطا مربوط به نبود یک تابع یا کلاس خاص بود، شاید افزونه‌ای جانبی لازم است. مسیر کامل این سناریو را در رفع خطای Fatal error بعد از فعال‌سازی افزونه گام‌به‌گام آورده‌ام.
علت دوم: ناسازگاری با نسخه PHP
هر افزونه‌ای برای بازه مشخصی از نسخه‌های PHP (Hypertext Preprocessor یا پیش‌پردازنده فرامتن) نوشته شده است. اگر سایت شما روی PHP 8.2 باشد ولی افزونه فقط تا PHP 8.0 پشتیبانی شده باشد، فعال‌سازی ممکن است با خطاهای عجیب و غیرمنتظره شکست بخورد. برعکسش هم صادق است: افزونه‌ای که مخصوص PHP 8.x است، روی PHP 7.4 کار نمی‌کند.
تشخیص این حالت با ابزار سلامت سایت وردپرس ساده است. در پیشخوان به بخش سلامت بروید و ببینید چه افزونه‌هایی به‌عنوان ناسازگار با PHP فعلی علامت‌گذاری شده‌اند. سپس یا نسخه PHP را با احتیاط ارتقا یا تنزل دهید، یا افزونه را به نسخه‌ای سازگار ارتقا دهید. روش دقیق این عیب‌یابی را در خطای عدم سازگاری افزونه با نسخه PHP باز کرده‌ام.
علت سوم: ناسازگاری با نسخه وردپرس
هر افزونه‌ای هدری دارد که در آن مشخص می‌کند با چه نسخه‌ای از وردپرس تست شده است. اگر سایت شما روی نسخه‌ای قدیمی‌تر یا بسیار جدیدتر از این بازه باشد، ممکن است فعال‌سازی شکست بخورد یا افزونه فعال شود ولی کار نکند. این مسئله در سایت‌های قدیمی که مدتی آپدیت نشده‌اند، یا در سایت‌های تازه که هنوز نسخه جدید وردپرس رویشان به‌طور کامل تست نشده، شایع‌تر است.
در صفحه معرفی افزونه در مخزن رسمی وردپرس، بخش Tested up to دقیقاً همین را می‌گوید. اگر نسخه شما از آن بالاتر یا پایین‌تر است، احتمال خطا بالا می‌رود. راه‌حل معمولاً آپدیت وردپرس یا انتخاب افزونه‌ای است که بازه پشتیبانی وسیع‌تری دارد.
علت چهارم: تعارض با افزونه دیگر
شایع‌ترین پرونده‌هایی که در پشتیبانی می‌بینم، دقیقاً این است: دو افزونه‌ای که هرکدام به‌تنهایی بی‌عیب کار می‌کنند، ولی وقتی هر دو فعال باشند، فعال‌سازی یکی از دیگری شکست می‌خورد. مثال‌های واقعی که دیده‌ام: افزونه کش با افزونه امنیتی روی همان هوک گلاویز می‌شوند؛ دو افزونه سئو که هم‌زمان sitemap تولید می‌کنند؛ دو افزونه بکاپ که هم‌زمان با یک جدول دیتابیس کار می‌کنند.
راه عیب‌یابی روی محیط استجینگ، خاموش کردن همه افزونه‌ها به‌جز وردپرس هسته و سپس روشن کردن یکی‌یکی است. افزونه‌ای که لحظه شکست را ایجاد می‌کند، مظنون اول است؛ ولی افزونه‌ای که قبل از آن فعال بوده را هم بررسی کنید، چون تعارض دوطرفه است. روش سیستماتیک این عیب‌یابی در رفع خطای تضاد افزونه‌ها در وردپرس آمده است.
تعارض افزونه‌ها هیچ‌وقت تصادفی نیست؛ همیشه یک فرض مشترک اشتباه در لایه‌های عمیق دو افزونه وجود دارد که در روز فعال‌سازی بروز می‌کند.
علت پنجم: تعارض با قالب
گاهی مسئله در افزونه نیست؛ در قالبی است که به‌طور ناخواسته از همان نام تابع یا همان کلاس استفاده می‌کند که افزونه جدید تعریف کرده. در این حالت، فعال‌سازی افزونه با خطای Fatal error: Cannot redeclare function... شکست می‌خورد. این خطا در قالب‌های قدیمی که سازنده‌شان در نوشتن کد دقت کافی نداشته، شایع‌تر است.
یک راه تشخیص سریع: قالب را موقتاً به یکی از قالب‌های پیش‌فرض وردپرس تغییر دهید و دوباره افزونه را فعال کنید. اگر مشکل حل شد، مقصر قالب است. در این صورت یا قالب باید به‌روزرسانی شود یا افزونه جایگزین پیدا کند. نکات تکمیلی درباره تعارض افزونه و قالب در شناسایی افزونه مشکل‌دار وردپرس آمده است.
علت ششم: کمبود حافظه PHP و محدودیت اجرا
بعضی افزونه‌ها در لحظه فعال‌سازی، فرآیند سنگینی مثل ساخت جدول، اسکن دیتابیس یا کش اولیه اجرا می‌کنند. اگر حافظه PHP سایت شما کم باشد یا زمان اجرای اسکریپت محدود باشد، فعال‌سازی نیمه‌کاره می‌ماند و خطای Allowed memory size exhausted یا Maximum execution time exceeded می‌دهد.
راه‌حل: در wp-config.php مقدار حافظه را افزایش دهید و زمان اجرای اسکریپت را بالا ببرید:
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
set_time_limit( 300 );البته این راه‌حل باید با هاستینگ هماهنگ باشد، چون بعضی هاست‌ها خودشان سقف بالاتری اعمال می‌کنند. جزئیات فنی‌تر را در خطای حافظه در وردپرس باز کرده‌ام. اگر مصرف منابع سایت شما به‌طور کلی بالاست، کاهش مصرف منابع هاست را هم ببینید.
علت هفتم: مجوز فایل و پوشه
اگر مجوز فایل‌های افزونه در پوشه wp-content/plugins نامناسب باشد، وردپرس نمی‌تواند فایل‌های جدید را از داخل پوشه بخواند. مجوز استاندارد پوشه‌ها ۷۵۵ و فایل‌ها ۶۴۴ است؛ ولی در بعضی موقعیت‌ها (مثلاً انتقال سایت از سرورهای ویندوزی به لینوکس) مجوزها به‌هم می‌ریزند و فعال‌سازی شکست می‌خورد.
راه‌حل: از طریق FTP یا File Manager هاست، مجوز پوشه افزونه و فایل‌های داخلش را به ۷۵۵ و ۶۴۴ برگردانید. این کار در افزونه‌های بزرگ که تعداد فایل‌های زیادی دارند، وقت می‌گیرد؛ ولی اگر مشکل از همین باشد، اثرش آنی است. توضیح کامل این نوع خطا در خطای دسترسی به فایل‌ها در وردپرس آمده است.
علت هشتم: فایل ناقص یا ناسالم
اگر فایل افزونه ناقص آپلود شده باشد یا فایل زیپ آن هنگام دانلود آسیب دیده باشد، پوشه افزونه در سرور ممکن است ناقص باشد. نشانه‌اش این است که افزونه در فهرست دیده می‌شود، ولی فعال نمی‌شود یا پس از فعال‌سازی، بخشی از قابلیت‌هایش کار نمی‌کند. علت دوم این مشکل، نصب افزونه از منابع ناشناس است؛ در این نوع نصب‌ها، فایل‌ها ممکن است دست‌کاری شده یا با کد اضافه همراه باشند.
راه‌حل: پوشه افزونه را به‌طور کامل حذف کنید و از مخزن رسمی وردپرس یا سایت معتبر سازنده، نسخه جدید را دانلود و دستی نصب کنید. راهنمای کامل درباره تفاوت منابع امن و ناامن را در دانلود افزونه مطمئن وردپرس آورده‌ام. یک نگاه به نشانه‌های یک افزونه آلوده هم در آسیب‌پذیری افزونه‌های وردپرس ارزش دارد.
علت نهم: خطاهای دیتابیس در زمان فعال‌سازی
بعضی افزونه‌ها در لحظه فعال‌سازی، جدول جدید می‌سازند یا ستون جدید به جدول موجود اضافه می‌کنند. اگر کاربر دیتابیس، دسترسی کافی برای این عملیات را نداشته باشد، فعال‌سازی شکست می‌خورد. علت دوم، وجود جدول با نام مشابه از یک نصب قبلی است. علت سوم، پرشدن حجم دیتابیس یا محدودیت هاست در تعداد جدول‌هاست.
راه‌حل: در wp-config.php حالت دیباگ را روشن کنید تا خطای دقیق دیتابیس را ببینید. اگر پیام مربوط به Table already exists بود، جدول قدیمی را با احتیاط حذف کنید (بعد از بکاپ کامل). اگر پیام مربوط به دسترسی بود، با مدیر هاست درباره مجوزهای کاربر دیتابیس صحبت کنید. توضیح کامل خطاهای رایج دیتابیس در زمان فعال‌سازی افزونه را در تأثیر دیتابیس بر سرعت سایت به‌طور جانبی بررسی کرده‌ام.
علت دهم: نبود افزونه‌های PHP موردنیاز
برخی افزونه‌ها به افزونه‌های PHP (PHP Extensions) نیاز دارند که باید در سرور نصب و فعال باشند. مثال‌های رایج: curl، gd، mbstring، intl، zip، imagick. اگر هاست شما یکی از این‌ها را نداشته باشد، فعال‌سازی افزونه شکست می‌خورد یا افزونه فعال می‌شود ولی در اجرا خطا می‌دهد.
راه تشخیص: در پیشخوان وردپرس به بخش سلامت سایت بروید و صفحه Info را باز کنید. در بخش سرور، فهرست افزونه‌های PHP نصب‌شده دیده می‌شود. اگر افزونه‌ای که موردنیاز افزونه وردپرسی است در این فهرست نیست، یا از هاستینگ بخواهید نصبش کند یا افزونه جایگزین انتخاب کنید. اگر با مفهوم کلی هاست آشنا نیستید، راهنمای انتخاب هاست تصویر روشنی از این لایه می‌دهد.
علت یازدهم: خطای اعتبارسنجی لایسنس
افزونه‌های تجاری معمولاً در زمان فعال‌سازی، لایسنس را با سرور سازنده چک می‌کنند. اگر سرور سازنده پاسخ ندهد — به‌خاطر فیلتر بودن، اختلال شبکه یا منقضی شدن لایسنس — فعال‌سازی نیمه‌کاره می‌ماند یا با پیام خطا شکست می‌خورد. این مسئله در سرورهای ایران به‌دلیل محدودیت‌های بین‌المللی شایع‌تر است.
راه‌حل: اول مطمئن شوید که لایسنس منقضی نشده است. دوم، اگر مسئله ارتباط شبکه‌ای است، با پشتیبانی سازنده یا نمایندگی محلی تماس بگیرید. سوم، اگر افزونه به‌طور کل با شرایط شبکه شما سازگار نیست، به‌سراغ جایگزین رایگان یا افزونه‌ای بروید که نیازی به اعتبارسنجی آنلاین ندارد.
علت دوازدهم: محدودیت‌های سرور و هاست
گاهی همه‌چیز در کد درست است ولی سرور شما اجازه اجرای فعال‌سازی را نمی‌دهد. مثال‌های واقعی: محدودیت max_input_vars برای افزونه‌هایی که فهرست طولانی تنظیمات دارند، محدودیت پورت خروجی برای افزونه‌هایی که به API خارجی وصل می‌شوند، و محدودیت تعداد process در هاست‌های اشتراکی که در زمان فعال‌سازی چند درخواست هم‌زمان اجرا می‌شوند.
راه‌حل: ابتدا از هاستینگ سؤال کنید که کدام محدودیت را اعمال می‌کند. اگر محدودیت‌ها قابل تغییر باشند، از آن‌ها بخواهید برای سایت شما باز کنند. اگر قابل تغییر نباشند، یا افزونه را در ساعت کم‌ترافیک فعال کنید یا هاست را ارتقا دهید. تصویر کامل‌تری از این لایه در تأثیر هاست بر سرعت و پایداری سایت آمده است.
روش فعال‌سازی امن که در پروژه‌ها رعایت می‌کنم
بعد از این همه سال، روش شخصی‌ام در فعال‌سازی افزونه یک الگوی ثابت دارد:
- بکاپ کامل فایل و دیتابیس می‌گیرم، حتی اگر افزونه ساده به‌نظر برسد.
- افزونه را در محیط استجینگ یا لوکال فعال می‌کنم، نه روی سایت زنده.
- بعد از فعال‌سازی، سه صفحه کلیدی (خانه، نوشته، تماس یا محصول) را باز می‌کنم.
- با حالت دیباگ روشن، لاگ خطا را بررسی می‌کنم.
- اگر همه‌چیز درست بود، در ساعات کم‌ترافیک روی سایت زنده فعال می‌کنم.
- در هفته اول، لاگ خطا و Search Console را روزانه پایش می‌کنم.
اگر افزونه در محیط استجینگ خوب کار کرد ولی روی زنده خطا داد، معمولاً یک تفاوت محیطی مقصر است: نسخه PHP، افزونه‌های دیگر، یا محدودیت هاست. تفاوت‌های محیطی بین استجینگ و زنده را در بهترین روش تست در محیط امن تا حدی بررسی کرده‌ام؛ همان منطق برای افزونه هم صدق می‌کند.
سه عادت پیشگیرانه
سه عادتی که بیشترین اثر را روی کاهش این دسته از خطاها داشته‌اند:
اول، هیچ‌وقت روی سایت زنده افزونه فعال نمی‌کنم؛ حتی برای افزونه‌های کوچک. این یک قاعده شخصی است که در طول سال‌ها از من در برابر بحران‌های بزرگی محافظت کرده است.
دوم، تعداد افزونه‌های فعال را کم نگه می‌دارم. هر افزونه‌ای که نصب می‌کنم، ابتدا به سؤال جواب می‌دهم که «کدام نیاز امروزم را حل می‌کند؟». اگر فقط یک «شاید فردا» است، نصب نمی‌کنم. این عادت را در آسیب‌پذیری افزونه‌ها به‌عنوان یک اصل مدیریتی هم گفته‌ام.
سوم، قبل از هر فعال‌سازی، فهرست افزونه‌های فعال فعلی را مرور می‌کنم تا ببینم آیا افزونه‌ای با کارکرد مشابه قبلاً نصب شده. نیمی از تعارض‌ها از افزونه‌هایی می‌آید که کارکردهای هم‌پوشان دارند.
نگاه عمیق‌تر: فعال‌سازی به‌عنوان یک تراکنش
برای مهندسانی که با معماری سیستم‌های بزرگ سروکار دارند، ارزش دارد فعال‌سازی افزونه را از منظر مهندسی تراکنش (Transaction) نگاه کنند. در دنیای نرم‌افزار مدرن، یک عملیات چندمرحله‌ای که باید یا کاملاً موفق شود یا کاملاً ناموفق، با مفهوم تراکنش مدیریت می‌شود. اما در وردپرس، فعال‌سازی افزونه به‌طور پیش‌فرض تراکنشی نیست؛ اگر در میانه عملیات شکست بخورد، ممکن است بخشی از تغییرات انجام شده باشد و بخشی نه. این همان چیزی است که در علم مهندسی به آن state partially applied می‌گویند.
سه مشاهده دقیق‌تر از تجربه‌های میدانی: اول، در افزونه‌های پیچیده که ساختار جدول و تنظیمات زیادی دارند، الگوی درست این است که در زمان فعال‌سازی، ابتدا تمام پیش‌نیازها بررسی شوند و فقط اگر همه‌شان پاس شدند، تغییرات اجرا شوند. اما بسیاری از افزونه‌ها این ترتیب را رعایت نمی‌کنند و به همین دلیل فعال‌سازی نیمه‌کاره شایع است. روزی که به‌عنوان توسعه‌دهنده افزونه می‌نویسید، این نکته را جدی بگیرید.
دوم، در محیط‌های multisite که یک شبکه از سایت‌ها مدیریت می‌شود، فعال‌سازی افزونه در سطح شبکه با فعال‌سازی در سطح سایت کاملاً متفاوت است. اگر افزونه‌ای فقط برای یک سایت شبکه فعال شده باشد، بقیه سایت‌ها آن را نمی‌بینند و می‌توانند رفتار سایت شما را گیج‌کننده کنند. این تفاوت در معماری چندسایتی، یکی از پرتکرارترین اشتباهاتی است که در پرونده‌های پشتیبانی دیده‌ام.
سوم، در معماری‌های Headless که فرانت‌اند جدا از وردپرس سرو می‌شود، فعال‌سازی افزونه‌هایی که روی فرانت‌اند اثر می‌گذارند، اغلب نتیجه‌شان دیده نمی‌شود. اینجا باید بین دو لایه تفکیک قائل شوید: افزونه‌هایی که رفتار بک‌اند را تغییر می‌دهند، و افزونه‌هایی که فقط روی پیشخوان یا فرانت‌اند وردپرس اثر دارند. تنها دسته اول برای معماری Headless مفید است و بقیه، فقط سربار خواهند بود.
چهارم، در CI/CD (Continuous Integration / Continuous Deployment یا یکپارچه‌سازی و استقرار پیوسته)، فعال‌سازی افزونه در محیط تولید باید از یک فرآیند قابل‌تکرار عبور کند، نه از دکمه‌ای در پیشخوان. تیم‌های بالغ، افزونه‌ها را در کدبیس پروژه می‌آورند و از طریق اسکریپت‌های استقرار فعال یا غیرفعال می‌کنند. این انضباط، زمان فعال‌سازی دستی را از چند دقیقه به چند ثانیه کاهش می‌دهد و امکان بازگشت سریع را هم فراهم می‌کند.
آنچه از دفتر تجربه ماند
اگر بخواهم کل این مقاله را در سه نکته خلاصه کنم: اول، خطای فعال‌سازی افزونه تقریباً همیشه یک علت ریشه‌ای مشخص دارد که با لاگ خطا و آزمایش مرحله‌ای قابل تشخیص است؛ دست‌زدن کورکورانه به تنظیمات، فقط وضع را بدتر می‌کند. دوم، پیش از هر فعال‌سازی، بکاپ و استجینگ دو بیمه ضروری هستند که در پروژه‌های فروشگاهی و شرکتی هرگز نباید نادیده گرفته شوند. سوم، اگر افزونه‌ای مرتب خطا می‌دهد، هزینه جایگزینی‌اش تقریباً همیشه کمتر از هزینه اصرار بر نگه داشتنش است.
اگر در پروژه‌ای با خطای فعال‌سازی افزونه مواجه شده‌اید که در این فهرست نبوده — به‌خصوص اگر در یک محیط خاص مثل multisite یا هدلس بوده — برایم بنویسید کدام علت ریشه‌ای بود و چطور به جواب رسیدید. تجربه‌های واقعی شما همان چیزی است که این فهرست را برای نفر بعدی دقیق‌تر می‌کند. 🔌
نویسنده در وردپرس کار.