Moodle 5.3 به نسخهٔ LTS رسید؛ ارتقا بدون PHP 8.3 متوقف می‌شود

بر پایهٔ گزارش Synex از انتشار Moodle، Moodle LMS 5.3 در ۵ اکتبر ۲۰۲۶ به‌عنوان نسخهٔ پشتیبانی بلندمدت یا LTS منتشر شد؛ پایان پشتیبانی عمومی آن برای ۴ اکتبر ۲۰۲۷ و پایان پشتیبانی امنیتی برای ۱ اکتبر ۲۰۲۹ برنامه‌ریزی شده است. این بازه به دانشگاه‌ها و آموزشگاه‌ها برای زمان‌بندی مهاجرت فرصت می‌دهد، اما آماده‌بودن سرور شرط آغاز ارتقاست.

برای همین نسخهٔ LTS، یادداشت رسمی انتشار Moodle 5.3 حداقل PHP 8.3.0، پایگاه‌دادهٔ سازگار و نصب فعلی Moodle 4.4 یا جدیدتر را لازم می‌داند. بنابراین سایتی که هنوز PHP قدیمی‌تری اجرا می‌کند، با جایگزین‌کردن فایل‌های Moodle به نسخهٔ تازه نمی‌رسد؛ محیط سرور نیز باید برای مقصد ارتقا آماده شود.

ماتریس سازگاری سرور چه می‌گوید؟

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

• PHP: نسخهٔ 8.3.0 یا جدیدتر؛ شاخهٔ 8.4 نیز پشتیبانی می‌شود. اجرای ۶۴ بیتی، افزونهٔ sodium و مقدار دست‌کم ۵۰۰۰ برای max_input_vars لازم است.
• PostgreSQL: نسخهٔ 17 یا جدیدتر.
• MySQL: نسخهٔ 8.4 یا جدیدتر.
• MariaDB: نسخهٔ 11.4.0 یا جدیدتر.

این مقادیر کف پشتیبانی‌اند، نه پیشنهاد استفاده از نخستین انتشار هر شاخه. افزایش حداقل نسخه برای PostgreSQL و MariaDB در همین انتشار می‌تواند ارتقای پایگاه‌داده را به بخشی مستقل از برنامهٔ مهاجرت تبدیل کند. در مقابل، صرف نصب PHP مناسب، کمبود نسخهٔ پایگاه‌داده یا نبود افزونهٔ ضروری PHP را جبران نمی‌کند.

اگر پایگاه‌داده زیر حداقل لازم است، باید زمان و روش ارتقای آن در کنار سازگاری نسخهٔ فعلی Moodle بررسی شود. تغییر هم‌زمان چند جزء سرور، تشخیص علت خطا را دشوار می‌کند؛ ثبت نسخه‌های مبدأ و مقصد و تمرین همان ترتیب تغییرات در محیط آزمایشی، مبنای قابل اتکاتری برای تصمیم دربارهٔ سامانهٔ اصلی می‌سازد. نصب‌های متکی به Oracle نیز به مسیر دیگری برای پایگاه‌داده نیاز دارند، زیرا این موتور در نسخه‌های جدید Moodle پشتیبانی نمی‌شود.

مسیر ارتقا از نصب فعلی کجاست؟

راهنمای ارتقای Moodle انتقال مستقیم به 5.3 را برای نصب‌های 4.4 و جدیدتر مجاز می‌داند؛ نصب قدیمی‌تر باید ابتدا به نسخهٔ میانیِ مجاز برسد. این تفاوت پیش از تعیین پنجرهٔ توقف سرویس مهم است: مرحلهٔ میانی به آزمون، پشتیبان و زمان بازیابی جداگانه نیاز پیدا می‌کند.

برای سایتی که از شاخه‌های پیش از 5.1 می‌آید، مسیر فایل‌های برنامه نیز عوض شده است. فایل‌های قابل دسترسی از وب در پوشهٔ public قرار می‌گیرند و وب‌سرور باید به ساختار تازه اشاره کند؛ افزونه‌های نصب‌شده هم باید در جای درستِ درخت کد جدید قرار بگیرند. جابه‌جایی فایل‌ها بدون بازبینی تنظیم وب‌سرور ممکن است سایتی با کد ارتقایافته اما مسیر دسترسی نادرست برجا بگذارد.

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

تغییرات نسخه در کلاس چه اثری دارند؟

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

حذف قالب Classic از هسته برای سایت‌هایی که از آن یا از سفارشی‌سازی‌های وابسته به آن استفاده می‌کنند، موضوعی جداگانه است. نمایش بلوک‌ها، صفحهٔ درس و انتخاب قالب می‌تواند پس از مهاجرت متفاوت باشد. مؤسسه‌ای که قالب سفارشی دارد باید نتیجه را در چند درس واقعیِ کپی‌شده ببیند، زیرا نصب تمیزِ نسخهٔ تازه رفتار قالب و محتوای موجود آن مؤسسه را نشان نمی‌دهد.

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

محیط آزمایشی چه چیزی را باید ثابت کند؟

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

1. نسخهٔ فعلی Moodle و اجزای سرور، همراه با فهرست قالب‌ها و افزونه‌ها ثبت و بررسی محیط برای مقصد اجرا شود.
2. کپی تازه‌ای از داده‌ها در محیط جداگانه بازیابی شود و تغییر PHP، پایگاه‌داده و کد Moodle با ترتیب برنامه‌ریزی‌شده تمرین شود.
3. ورود کاربر، ثبت‌نام در درس، تحویل و تصحیح تکلیف، شرکت در آزمون و خروجی نمرات با حساب‌های آزمایشی بررسی شود.
4. اتصال‌هایی مانند ورود یکپارچه، کلاس ویدئویی یا سامانهٔ دانشجویی، اگر در نصب اصلی وجود دارند، با نسخهٔ مقصد آزموده شوند.
5. مدت اجرا، خطاها و تغییرات دستی ثبت شود تا پنجرهٔ ارتقای سامانهٔ اصلی بر پایهٔ نتیجهٔ تمرین تعیین شود.

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

پشتیبان و بازگشت چگونه در برنامه جا می‌گیرند؟

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

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

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

بیشتر بخوانید:

• Bun یا Node.js؛ سرعت بیشتر با حفره‌های سازگاری معاوضه می‌شود
• عامل تازهٔ AWS هر هفته معماری را می‌سنجد؛ دسترسی از Business+ شروع می‌شود
• حفرهٔ SharePoint فعالانه سوءاستفاده می‌شود؛ نصب وصله پایان بررسی نیست