خطای عدم پشتیبانی افزونه از نسخه وردپرس

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

چرا نسخه وردپرس این‌قدر برای افزونه‌ها حیاتی است؟

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

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

نسخه وردپرس، فقط یک عدد نیست؛ یک تعهد است که هسته به همه اکوسیستم می‌دهد. اگر افزونه‌ای این تعهد را نشکند، ولی هسته آن را تغییر دهد، اکوسیستم با افزونه‌های ناسازگار رو‌به‌رو می‌شود.

الگوی تشخیص که در پرونده‌های واقعی استفاده می‌کنم

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

1. ابتدا نسخه وردپرس، نسخه PHP و نام افزونه مشکوک را یادداشت می‌کنم.
2. در فایل اصلی افزونه، هدر آن را باز می‌کنم و سه خط Requires at least، Tested up to و Requires PHP را می‌خوانم.
3. در صفحه افزونه در مخزن رسمی وردپرس، بخش Tested up to را با نسخه سایت مقایسه می‌کنم.
4. اگر اختلاف نسخه معنی‌دار بود — معمولاً بیش از دو نسخه اصلی — به‌عنوان مظنون اصلی در نظر می‌گیرم.
5. در غیر این صورت، به سراغ تعارض با افزونه دیگر یا قالب می‌روم که در مقالات دیگر به آن پرداخته‌ام.

نکته مهمی که در این الگو رعایت می‌کنم: قبل از هر اقدامی، بکاپ کامل از سایت می‌گیرم. حتی اگر پرونده ساده به‌نظر برسد. مسیر درست بکاپ و بازگردانی در چگونه از سایت وردپرسی بکاپ بگیریم آمده است.

دوازده نشانه‌ای که به ناسازگاری نسخه اشاره می‌کند

پیش از ورود به علت‌ها، بد نیست دوازده نشانه‌ای را بشناسید که در تجربه‌ام بیشترین همبستگی را با ناسازگاری نسخه داشته‌اند:

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

علت اول: هدر افزونه با نسخه تست‌نشده

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

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

علت دوم: استفاده از توابع هسته که حذف شده‌اند

هر چند نسخه وردپرس، چندین تابع قدیمی را حذف می‌کند. این توابع در نسخه‌های قبل کار می‌کردند ولی حالا نه. اگر افزونه‌ای هنوز به این توابع وابسته باشد، بعد از آپدیت وردپرس خطای Fatal error: Call to undefined function می‌دهد. مثال‌های تاریخی: حذف wp_get_sites در نسخه ۴.۶، حذف چند تابع قدیمی کتابخانه Walker در نسخه‌های بعدی، و حذف تدریجی برخی توابع کتابخانه‌های قدیمی.

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

علت سوم: تغییر رفتار API داخلی وردپرس

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

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

علت چهارم: افزونه‌های رهاشده و بدون نگهداری

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

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

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

علت پنجم: افزونه‌های قدیمی روی PHP جدید

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

راه تشخیص: صفحه Info در ابزار سلامت سایت، نسخه‌های PHP و افزونه‌های PHP نصب‌شده را نشان می‌دهد. تفاوت‌های رفتاری بین نسخه‌های PHP را در خطای عدم سازگاری افزونه با نسخه PHP مفصل باز کرده‌ام.

علت ششم: تغییر رفتار Gutenberg و بلوک‌ها

Gutenberg یا ویرایشگر بلوکی وردپرس، در هر نسخه تغییراتی دارد. بعضی افزونه‌هایی که بلوک سفارشی اضافه می‌کنند، ممکن است بعد از آپدیت وردپرس در ویرایشگر خطا بدهند یا بلوکشان از فهرست ناپدید شود. علت معمولاً تغییر در API بلوک‌ها یا نسخه پکیج‌های @wordpress/* است. مثال واقعی: تغییری در نسخه‌ای از وردپرس باعث شد بلوک‌های افزونه‌ای که از wp.blocks.registerBlockType به‌شکل قدیمی استفاده می‌کرد، خطای جاوااسکریپت بدهد.

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

علت هفتم: تغییر رفتار REST API ووکامرس

در فروشگاه‌های ووکامرس، ناسازگاری نسخه وردپرس با افزونه‌های ووکامرسی شایع است چون REST API ووکامرس به ساختار هسته وردپرس بسیار وابسته است. تغییر در ساختار REST API وردپرس می‌تواند افزونه‌های ووکامرسی که با آن کار می‌کنند را از کار بیندازد. مثال واقعی: تغییر در ساختار authentication در REST API نسخه‌ای از وردپرس، باعث شد افزونه‌های پرداخت ووکامرس نتوانند با درگاه‌ها ارتباط برقرار کنند.

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

علت هشتم: کلاس‌های حذف‌شده و تغییر فضای نام

وردپرس در نسخه‌های جدید، کلاس‌های قدیمی را در فضای نام متفاوتی قرار می‌دهد یا حذف می‌کند. اگر افزونه‌ای با نام کلاس کامل به آنها ارجاع داده باشد و آن کلاس دیگر موجود نباشد، خطای Class not found می‌دهد. این نوع خطا در افزونه‌های قدیمی که با نسخه‌های ۵.x یا ابتدای ۶.x نوشته شده‌اند، شایع‌تر است.

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

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

گاهی هیچ افزونه‌ای به‌تنهایی با وردپرس ناسازگار نیست، ولی ترکیب چند افزونه بعد از آپدیت وردپرس ناسازگار می‌شود. مثلاً وردپرس یک هوک جدید اضافه می‌کند، افزونه A روی آن هوک گوش می‌دهد، افزونه B هم روی آن گوش می‌دهد، ولی ترتیب اجرایشان بعد از آپدیت تغییر می‌کند و نتیجه منطق اشتباه می‌شود. این نوع ناسازگاری بدترین حالت است چون با تست یک افزونه به‌تنهایی کشف نمی‌شود.

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

علت دهم: فایل ترجمه ناسازگار با نسخه وردپرس

گاهی خطا در ظاهر ناسازگاری نسخه است ولی در واقع مربوط به فایل ترجمه است. وردپرس در نسخه‌های جدید، ساختار فایل‌های ترجمه را تغییر می‌دهد. اگر افزونه‌ای فایل .mo یا .po داشته باشد که با نسخه جدید سازگار نیست، بخشی از متن‌های پیشخوان فارسی نمایش داده نمی‌شود یا به‌شکل عجیبی به نمایش درمی‌آید. این نوع خطا شایع نیست ولی وقتی رخ می‌دهد، گیج‌کننده است چون کد اصلی افزونه سالم است.

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

علت یازدهم: ناسازگاری پنهان از نگاه ابزارها

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

راه تشخیص: تست عملی و دقیق. بلافاصله بعد از هر آپدیت وردپرس، مسیرهای اصلی سایت را با افزونه‌های مختلف تست کنید. خودکارسازی این تست می‌تواند به شکل اسکریپت‌های Playwright یا Puppeteer اجرا شود. مسیر ساخت این تست‌ها در بهترین روش تست قالب وردپرس برای قالب توضیح داده شده، ولی منطقش برای افزونه هم عیناً قابل انتقال است.

علت دوازدهم: افزونه‌های نال و نسخه‌های دست‌کاری‌شده

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

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

چگونه نسخه سازگار را به‌درستی تشخیص دهیم

پس از این همه علت‌ها، احتمالاً می‌پرسید چگونه بفهمم کدام افزونه ناسازگار است. سه ابزار را در پروژه‌ها استفاده می‌کنم:

• ابزار سلامت سایت وردپرس: در پیشخوان ← ابزارها ← سلامت سایت ← گزارش. این ابزار هدر افزونه‌ها را می‌خواند و ناسازگاری‌های ظاهری را نشان می‌دهد.
• فایل debug.log: با روشن کردن WP_DEBUG، خطاهای واقعی زمان اجرا را می‌بینید.
• صفحه افزونه در مخزن رسمی: بخش Tested up to و بخش changelog، آخرین نسخه تست‌شده را نشان می‌دهد.

یک نکته که در تجربه‌ام به‌کار آمده: اگر افزونه‌ای در مخزن رسمی وردپرس Tested up to برابر با آخرین نسخه وردپرس دارد، ولی به‌تازگی آپدیت نشده، احتمالاً توسعه‌دهنده فقط هدر را تغییر داده ولی کد را آپدیت نکرده. این نوع افزونه‌ها گاهی سکوت می‌کنند و در زمان واقعی خطا می‌دهند.

پروتکل بازگشت امن بعد از ناسازگاری

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

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

در همه این سه گزینه، مرحله اول همیشه یک چیز است: بکاپ کامل. اگر بکاپ تازه‌ای ندارید، مسیر بازیابی سایت از بکاپ را بخوانید تا در صورت خرابی بتوانید سریع بازگردید.

سه عادت پیشگیرانه

سه عادتی که بیشترین اثر را روی کاهش این دسته از پرونده‌ها داشته‌اند:

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

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

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

نگاه عمیق‌تر: نسخه وردپرس به‌عنوان مرز ABI

برای مهندسانی که با معماری نرم‌افزار سروکار دارند، ارزش دارد نسخه وردپرس را در چارچوب مفهوم ABI (Application Binary Interface یا رابط دودویی برنامه) نگاه کنند. در دنیای نرم‌افزار کامپایل‌شده، هر نسخه از یک کتابخانه یک ABI دارد که مشخص می‌کند کدام توابع و کلاس‌ها در دسترس هستند. اگر کدی با ABI نسخه قبلی نوشته شده باشد و کتابخانه آپدیت شود، آن کد ممکن است دیگر لینک نشود. در وردپرس، گرچه PHP یک زبان تفسیری است و مفهوم ABI به معنای کلاسیک آن معنا ندارد، ولی همان نقش را هسته وردپرس بازی می‌کند.

سه مشاهده دقیق‌تر از تجربه‌های میدانی: اول، در پروژه‌های بزرگ با ده‌ها افزونه، مسأله ناسازگاری نسخه به یک پروژه مدیریت وابستگی تبدیل می‌شود. تیم‌های بالغ، فهرست افزونه‌ها را با نسخه‌های قفل‌شده در یک فایل مدیریت می‌کنند و پیش از هر آپدیت وردپرس، این فهرست را با نسخه‌های سازگار تطبیق می‌دهند. این همان انضباطی است که در مدیریت پکیج‌های مدرن مثل npm و Composer وجود دارد، ولی در اکوسیستم وردپرس کمتر دیده می‌شود.

دوم، در معماری multisite (چندسایتی)، مشکل ناسازگاری نسخه در سطح شبکه بزرگ‌تر می‌شود چون همه سایت‌ها از یک هسته وردپرس استفاده می‌کنند ولی ممکن است افزونه‌های متفاوتی داشته باشند. یک آپدیت وردپرس در این ساختار می‌تواند روی همه سایت‌های شبکه اثر بگذارد و ناسازگاری یک افزونه، به بحران شبکه‌ای تبدیل شود. راه‌حل، آپدیت مرحله‌ای روی یک سایت نمونه، پایش دقیق چند روزه، و سپس اعمال روی بقیه شبکه است.

سوم، در معماری Headless که فرانت‌اند جدا از وردپرس سرو می‌شود، ناسازگاری نسخه وردپرس به شکلی غیرمستقیم ظاهر می‌شود: افزونه‌ای که با REST API کار می‌کند ممکن است بعد از آپدیت، ساختار داده متفاوتی برگرداند و فرانت‌اند را به‌هم بزند. در این معماری، تست وابستگی‌ها به‌صورت مستقل از تست ظاهری ضروری است. مقاله SEO تکنیکال: از خزش تا ایندکس به‌طور جانبی به لایه‌های پایین‌تر این ساختار می‌پردازد.

چهارم، در CI/CD (Continuous Integration / Continuous Deployment یا یکپارچه‌سازی و استقرار پیوسته)، ناسازگاری نسخه را می‌توان به‌صورت خودکار تشخیص داد. تیم‌های بالغ، یک مرحله در خط تولید خود دارند که پیش از استقرار هر آپدیت وردپرس، ناسازگاری‌های شناخته‌شده افزونه‌ها را چک می‌کند و در صورت وجود مشکل، استقرار را متوقف می‌کند. این نوع اتوماسیون، از بروز پرونده‌های پشتیبانی در ساعات نامناسب جلوگیری می‌کند.

آنچه از دفتر تجربه ماند

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

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

اگر در پروژه‌ای با ناسازگاری نسخه وردپرس مواجه شده‌اید که در این فهرست نبوده — به‌خصوص اگر در معماری multisite، Headless یا با افزونه‌های خاص بوده — برایم بنویسید کدام علت ریشه‌ای بود و چطور به جواب رسیدید. تجربه‌های واقعی شما همان چیزی است که این فهرست را برای نفر بعدی دقیق‌تر می‌کند. 🧩