وردپرس همیشه یکی از پویاترین و محبوب‌ترین سیستم‌های مدیریت محتوای دنیا بوده است. میلیون‌ها وب سایت کوچک و بزرگ بر پایه‌ی آن ساخته شده‌اند و اکوسیستمی از هزاران افزونه و پوسته‌ی گوناگون، رشد و تنوع آن را تضمین کرده‌اند. اما درست در مرداد ۱۳۹۹ (اوت ۲۰۲۰) اتفاقی رخ داد که موجی از سردرگمی در میان کاربران و توسعه دهندگان به پا کرد: پس از انتشار نسخه‌ی ۵.۵، هزاران سایت وردپرسی در سراسر جهان دچار اختلال شدند. صفحات از کار افتادند، اسکریپت های جاوا اسکریپت دیگر اجرا نمی‌شدند، و حتی برخی قابلیت‌های پایه‌ای نظیر صفحه بندی یا اسلایدرها از کار افتادند.
نکته‌ی مهم این است که این بار مشکل از «باگ» یا «خرابی ذاتی وردپرس» نبود، بلکه از تغییرات ساختاری آگاهانه‌ای ناشی می‌شد که تیم توسعه برای بهبود امنیت، سرعت و سازگاری آینده‌ی وردپرس اعمال کرده بود. اما همین تصمیم‌ها که از منظر فنی پیشرفت محسوب می‌شدند، برای وب سایت هایی که هنوز از افزونه ها و قالب های قدیمی استفاده می‌کردند دردسرساز شد. در این مقاله، به زبان ساده اما تحلیلی، بررسی می‌کنیم که دقیقاً چه تغییراتی در وردپرس ۵.۵ رخ داد، چرا باعث خرابی هزاران وب سایت شد و چگونه می‌توان از بروز چنین مشکلاتی در آینده پیشگیری کرد. تجربه‌ی اختلال‌های گسترده در وردپرس ۵.۵ نشان داد که انتخاب زیرساخت مناسب، نقش مهمی در تحمل خطا و مدیریت بروزرسانی ها دارد؛ به‌ویژه زمانی که سایت روی یک سرور ابری با قابلیت مقیاس پذیری و بازیابی سریع اجرا شود.
نقش jQuery Migrate در پایداری وردپرس و دلیل حذف آن
برای درک مشکل بزرگ وردپرس ۵.۵، ابتدا باید بدانیم که jQuery Migrate چیست و چرا حذف آن چنین پیامدهایی داشت. وردپرس از ابتدای پیدایش تا سال ۲۰۲۰ از نسخه‌های قدیمی jQuery، کتابخانه‌ای پرکاربرد برای تعاملات سمت کاربر استفاده می‌کرد. برای اینکه افزونه ها و قالب هایی که بر پایه‌ی نسخه های قدیمی jQuery نوشته شده بودند همچنان درست کار کنند، یک کتابخانه‌ی واسط به نام jQuery Migrate به وردپرس افزوده شده بود. این کتابخانه همانند پلی میان کدهای قدیمی و استانداردهای جدید عمل می‌کرد و باعث می‌شد افزونه ها حتی بدون بروزرسانی، همچنان کار کنند.
اما در نسخه‌ی ۵.۵، تیم توسعه تصمیم گرفت این پل را حذف کند تا کدهای جاوا اسکریپت وردپرس سبک‌تر، سریع‌تر و مطابق استانداردهای جدید شود. در نگاه اول، تصمیمی فنی و مثبت بود، اما واقعیت این است که هزاران افزونه و قالب در مخزن وردپرس هنوز از توابع و متدهای قدیمی استفاده می‌کردند. به محض انتشار این نسخه، بخش بزرگی از آن‌ها دیگر قادر به اجرا نبودند و همین مسئله باعث شد اسلایدرها، فرم ها، منوهای بازشونده و ده‌ها قابلیت دیگر در وب سایت های واقعی از کار بیفتند.
به‌عبارت دیگر، حذف jQuery Migrate مانند برداشتن چرخ کمکی از دوچرخه‌ای بود که هنوز بسیاری از کاربرانش دوچرخه سواری حرفه‌ای بلد نبودند. وردپرس آماده‌ی حرکت به جلو بود، اما جامعه‌ی کاربرانش هنوز برای این جهش آماده نشده بود. در چنین شرایطی، داشتن یک محیط ایزوله و قابل کنترل برای تست و رفع ناسازگاری‌ها، مانند اجرای وردپرس در یک ابر خصوصی (VPC)، می‌تواند ریسک خرابی سایت اصلی را به حداقل برساند.
چرا این خطاها تقصیر وردپرس نیست؟
در ظاهر، بروزرسانی به نسخه‌ی ۵.۵ باعث خرابی سایت ها شد، اما از دید فنی، مقصر اصلی کدهای قدیمی و نگهداری نشده‌ی افزونه ها و قالب ها بودند. توسعه دهندگان حرفه‌ای معمولاً کدهای خود را با نسخه‌های جدید jQuery آزمایش می‌کنند و از متدهای منسوخ استفاده نمی‌کنند. اما بسیاری از وب سایت های تجاری یا شخصی، افزونه هایی را سال‌ها پیش نصب کرده و هرگز بروزرسانی نکرده بودند.
از آنجا که وردپرس ذاتاً محیطی باز دارد، هر توسعه دهنده ای می‌تواند افزونه یا قالبی تولید کند و در طول زمان آن را رها کند. همین موضوع سبب شده است که تعداد زیادی از افزونه های محبوب، حتی با وجود گذشت سال‌ها، همچنان در سایت ها فعال باشند در حالی که با ساختار جدید ناسازگارند.
نتیجه این شد که حذف jQuery Migrate ضعف‌های پنهان را آشکار کرد؛ یعنی همان افزونه هایی که سال‌ها بدون مشکل کار می‌کردند، اکنون دیگر نتوانستند با وردپرس جدید ارتباط برقرار کنند. پس آنچه «خرابی» به نظر می‌رسد، در واقع نوعی «پاکسازی طبیعی» اکوسیستم وردپرس است که وب سایت ها را وادار می‌کند از فناوری‌های به‌روزتر و امن‌تر استفاده کنند.
چگونه می‌توان خطای jQuery Migrate را در وردپرس ۵.۵ حل کرد؟
اولین و ساده‌ترین گام، بررسی تاریخ آخرین بروزرسانی افزونه ها و قالب هاست. اگر افزونه ای بیش از یک سال است بروزرسانی نشده، احتمال زیادی وجود دارد که از توابع قدیمی jQuery استفاده کند. در این شرایط دو گزینه وجود دارد: یا باید افزونه ای جایگزین و بروز بیابید، یا به‌صورت موقت از افزونه ای کمک بگیرید که نقش همان پل حذف شده را بازی کند.
یکی از افزونه های رسمی و معتبر برای این منظور، Enable jQuery Migrate Helper است. این افزونه توسط تیم رسمی وردپرس معرفی شده تا وب سایت هایی که پس از آپدیت با خطاهای جاوا اسکریپت روبه‌رو می‌شوند بتوانند موقتاً عملکرد سابق خود را حفظ کنند. با نصب این افزونه، نسخه‌ی حذف شده‌ی jQuery Migrate دوباره به وردپرس شما اضافه می‌شود و کدهای قدیمی بار دیگر کار می‌کنند.
البته باید توجه داشت که این راه‌حل صرفاً موقتی است. هدف اصلی آن، فراهم کردن فرصت برای مدیران سایت است تا بتوانند افزونه ها و قالب های ناسازگار را شناسایی و جایگزین کنند. در واقع، Enable jQuery Migrate Helper مانند یک «اکسیژن اضطراری» برای سایت عمل می‌کند تا در حین نوسازی ساختار کدها، وب سایت از کار نیفتد.
از منظر امنیتی نیز استفاده‌ی طولانی مدت از افزونه های قدیمی توصیه نمی‌شود، زیرا هر کد منسوخ شده می‌تواند دروازه‌ای برای نفوذ مهاجمان باشد. پس بهتر است پس از فعال‌سازی موقت این افزونه و رفع خطاها، به‌تدریج همه‌ی افزونه های قدیمی را حذف و جایگزین کنید. استفاده از این راهکارهای موقت، زمانی بیشترین اثربخشی را دارد که سایت روی زیرساختی اجرا شود که امکان Snapshot، بازگشت سریع و تست تغییرات را فراهم کند؛ قابلیتی که در سرورهای ابری ابرآراد به‌صورت ذاتی وجود دارد.
محصولات ابر آراد را ببینید و مشخصات هر سرویس را مقایسه کنید.
باگ صفحه‌بندی در وردپرس ۵.۵ و تأثیر آن بر ساختار پیمایش سایت ها
یکی دیگر از خطاهای مهمی که پس از انتشار وردپرس ۵.۵ گزارش شد، مربوط به عملکرد Pagination یا همان صفحه بندی در سایت ها بود. صفحه بندی از اجزای حیاتی در طراحی تجربه‌ی کاربری و ساختار اطلاعات محسوب می‌شود. هرگاه وب سایتی دارای لیست طولانی از مطالب، محصولات یا نوشته ها باشد، تقسیم آن به صفحات متعدد برای بهبود سرعت و نظم ضروری است. اما باگ جدیدی که در وردپرس ۵.۵ ظاهر شد، باعث شد هزاران سایت نتوانند صفحه‌های داخلی خود را به‌درستی بارگذاری کنند.
این مشکل از آنجا آغاز شد که وردپرس در این نسخه، برای بهبود پشتیبانی از Query های داخلی، پارامتر “page” را تنها برای دریافت مقادیر عددی تعریف کرد. در حالی‌که بسیاری از قالب های قدیمی‌تر از این متغیر برای مقاصد دیگر، مثلاً نمایش محتوای خاص یا فیلتر کردن بر اساس شناسه‌ی رشته‌ای، استفاده می‌کردند. همین تغییر باعث شد وقتی کاربر از صفحه‌ی اول به دوم می‌رفت، وردپرس مقدار رشته‌ای را غیرمجاز بداند و درخواست را ریدایرکت کند. این ریدایرکت گاهی به حلقه‌ی بی‌پایان تبدیل می‌شد (۳۰۱ Redirect Loop) و در برخی موارد نیز موجب می‌شد صفحه‌ی دوم عملاً وجود نداشته باشد.
توسعه دهندگان پس از بررسی دریافتند که ریشه‌ی این رفتار در تابع redirect_canonical() نهفته است؛ تابعی که وظیفه‌ی هدایت خودکار URL ها را بر عهده دارد. از آنجا که redirect_canonical() در وردپرس ۵.۵ دقیق‌تر و سخت‌گیرانه‌تر شده بود، هر گونه آدرس غیراستاندارد را به مسیر صحیح بازمی‌گرداند، اما در سایت هایی که قالبشان از پارامتر page برای مقاصد دیگر استفاده می‌کرد، این رفتار به اختلال تبدیل می‌شد.
روش‌های رفع خطای Pagination در وردپرس ۵.۵
برای رفع این مشکل، وردپرس چند روش فنی پیشنهاد کرده است که بسته به نوع قالب یا افزونه‌ی شما می‌تواند متفاوت باشد. ساده‌ترین روش، تغییر نام پارامتر page در Query هاست. به‌جای استفاده از page=offers&id=xxx باید از عباراتی مانند mypage=offers&id=xxx استفاده شود. این تغییر ساده، از برخورد تابع redirect_canonical() با متغیر داخلی page جلوگیری می‌کند.
روش دوم، غیرفعال کردن موقت تابع redirect_canonical() است. این کار باید با دقت و ترجیحاً توسط یک توسعه دهنده انجام شود، زیرا این تابع نقش مهمی در سئو و هدایت درست صفحات دارد. در صورتی که اطمینان دارید قالب یا افزونه‌ی خاصی باعث بروز خطا شده، می‌توانید این تابع را برای همان درخواست خاص غیرفعال کنید تا از ریدایرکت اشتباه جلوگیری شود.
نمونه‌ی کد برای این کار معمولاً به این شکل در فایل functions.php اضافه می‌شود:
remove_filter(‘template_redirect’, ‘redirect_canonical’);
با این حال، اجرای این دستور به‌صورت کلی توصیه نمی‌شود، زیرا حذف کامل آن می‌تواند بر سئوی داخلی سایت اثر منفی بگذارد. بهترین کار این است که تنها در شرایط خاص یا برای Query هایی که با پارامترهای سفارشی اجرا می‌شوند، این رفتار کنترل شود.
از دیدگاه تجربه‌ی کاربری، هرچند این خطا در ظاهر ساده است، اما می‌تواند به از دست رفتن بخش بزرگی از ترافیک سایت منجر شود. وقتی صفحات ۲ یا ۳ لیست مطالب در دسترس نباشند، خزنده های گوگل نمی‌توانند مطالب قدیمی‌تر را ایندکس کنند و عملاً بخشی از محتوای ارزشمند سایت از دید موتورهای جستجو پنهان می‌ماند.
نقش سازگاری افزونه ها و اهمیت تست نسخه‌های جدید
این تجربه بار دیگر ثابت کرد که مهم‌ترین بخش در مدیریت سایت های وردپرسی، آزمون و کنترل پیش از بروزرسانی اصلی است. بسیاری از مدیران سایت ها مستقیماً وردپرس را در محیط اصلی آپدیت کردند، بدون آنکه نسخه‌ی جدید را در یک محیط تستی (Staging) بررسی کنند. در چنین شرایطی، کوچک‌ترین تغییر در ساختار هسته می‌تواند باعث از کار افتادن کل سایت شود.
بهترین رویکرد این است که پیش از ارتقاء وردپرس به نسخه های اصلی، در یک محیط جداگانه تمام افزونه ها و قالب ها آزمایش شوند. همچنین استفاده از افزونه های امنیتی و مانیتورینگ مانند WP Activity Log یا Wordfence به مدیران کمک می‌کند تا پس از آپدیت، رفتار سیستم را زیر نظر بگیرند و در صورت بروز خطا بلافاصله آن را شناسایی کنند. پیاده سازی محیط Staging روی یک ابر خصوصی (VPC) این امکان را می‌دهد که نسخه‌های جدید وردپرس و افزونه ها بدون تداخل با محیط اصلی، به‌صورت ایمن و کاملاً جداگانه بررسی شوند.
وردپرس ۵.۵ در واقع گامی بزرگ به‌سوی مدرن‌تر شدن بود، اما جامعه‌ی کاربری گسترده‌ی آن نشان داد که هماهنگ‌سازی چنین اکوسیستم عظیمی کار آسانی نیست. هر سایت ترکیبی از افزونه های متنوع است که برخی از آن‌ها سال‌هاست بدون پشتیبانی باقی مانده‌اند. این تنوع زیاد باعث می‌شود هر تغییر هسته، زنجیره‌ای از مشکلات احتمالی به‌دنبال داشته باشد. بنابراین، مسئولیت اصلی سازگاری افزونه ها بر دوش توسعه دهندگان شخص ثالث است و مدیران سایت نیز باید با انتخاب هوشمندانه‌ی افزونه های فعال، ریسک را به حداقل برسانند.
جمع‌بندی
وردپرس ۵.۵ به خودی خود یک شکست نبود، بلکه نمایانگر یک نقطه‌ی عطف در تاریخ توسعه‌ی وردپرس است؛ جایی که نیاز به حرکت از تکنولوژی‌های قدیمی به ساختارهای مدرن احساس می‌شد. حذف jQuery Migrate و بازتعریف متغیر page تصمیماتی بودند که از دید مهندسی درست و آینده نگرانه بودند، اما در کوتاه مدت باعث بروز مشکلات فراگیر شدند.
مشکلاتی که کاربران تجربه کردند، زنگ هشداری بود برای همه‌ی مدیران وب سایت ها تا بدانند بروزرسانی فقط یک کلیک نیست، بلکه یک فرآیند مهندسی دقیق است. هر آپدیت باید با آزمون، نسخه‌ی پشتیبان و کنترل سازگاری همراه باشد.
اگر مدیران سایت ها افزونه ها و پوسته های خود را به‌صورت منظم بروزرسانی کنند، از منابع معتبر استفاده نمایند و پیش از آپدیت‌های بزرگ محیط تستی داشته باشند، چنین بحران‌هایی دیگر تکرار نخواهد شد.
در نهایت، وردپرس ۵.۵ به ما یاد داد که پایداری یک سیستم، تنها در گرو کدهای خوب نیست، بلکه به هماهنگی کل اکوسیستم، از توسعه دهندگان افزونه گرفته تا مدیران محتوا، بستگی دارد.
پرسش‌های متداول
1- چرا بعد از آپدیت به وردپرس ۵.۵ سایت من خراب شد؟
زیرا بسیاری از افزونه ها و قالب های قدیمی از کدهای وابسته به jQuery Migrate استفاده می‌کردند که در نسخه‌ی ۵.۵ حذف شد.
2- آیا نصب افزونه Enable jQuery Migrate Helper برای همیشه لازم است؟
خیر، این افزونه یک راه‌حل موقت است تا فرصت داشته باشید افزونه ها و قالب های قدیمی را جایگزین کنید.
3- خطای صفحه بندی (Pagination) در وردپرس ۵.۵ چگونه برطرف می‌شود؟
با تغییر نام متغیر page در Query ها یا کنترل تابع redirect_canonical() می‌توان این مشکل را حل کرد.
4- آیا بروزرسانی نکردن وردپرس بهتر است؟
خیر، بروزرسانی همیشه ضروری است زیرا شامل اصلاحات امنیتی و بهبود عملکرد است، اما باید ابتدا در محیط تستی بررسی شود.
5- آیا وردپرس ۵.۵ ناامن است؟
خیر، بلکه از نسخه‌های قبل امن‌تر است. مشکلات فعلی ناشی از ناسازگاری افزونه های قدیمی است، نه ضعف در هسته‌ی وردپرس.
از صفحه تماس ابر آراد، مسیر ارتباط با تیم را انتخاب کنید.
دیدگاه‌ها و پرسش‌های شما
تجربه یا پرسش خود را درباره موضوع مقاله با ما در میان بگذارید.
هنوز دیدگاهی ثبت نشده است؛ شما گفت‌وگو را شروع کنید.