Системні вимоги Moodle 5.2: PHP 8.3, PostgreSQL, MySQL

Вступ

Застосовність: Moodle 5.2.x.

Перехід на нову версію Moodle починається не з самого оновлення, а з перевірки інфраструктури. Якщо серверне середовище не відповідає вимогам цільової версії, міграція може потребувати додаткових робіт: оновлення PHP, СУБД, зміни параметрів хостингу або перенесення системи на іншу інфраструктуру.

Для Moodle 5.2 одним із ключових порогів є PHP 8.3 або новіший. Також підвищилися мінімальні вимоги до частини підтримуваних СУБД. Це означає, що сервер, який стабільно працює з Moodle 5.1, не обов’язково готовий до 5.2 без додаткової перевірки.

Головне завдання перед міграцією — не самостійно змінити якомога більше налаштувань, а зрозуміти поточний стан системи, порівняти його з вимогами Moodle 5.2, визначити блокери й скласти безпечний план переходу.

Зміст

• Таблиця вимог Moodle 5.2
• Як перевірити свій сервер
• Якщо PHP застарілий
• Вибір СУБД
• Апаратні рекомендації
• FAQ

Таблиця вимог Moodle 5.2

Moodle визначає мінімальні версії основних серверних компонентів для кожної гілки. Для Moodle 5.2 базові вимоги такі:

PostgreSQL 16 не є обов’язковою СУБД для Moodle 5.2. Це лише мінімальна версія для тих систем, які вже працюють на PostgreSQL. Moodle також підтримує інші СУБД із таблиці вище.

Окремо потрібно враховувати шлях оновлення. Moodle 5.2 підтримує прямий перехід із Moodle 4.4 або новішої версії. Якщо інсталяція старіша, проєкт міграції потрібно планувати в кілька етапів.

Порівняно з Moodle 5.1 вимоги стали вищими. Зокрема, Moodle 5.1 ще підтримувала PHP 8.2 і PostgreSQL 15. Тому факт, що поточна платформа працює стабільно, сам по собі не підтверджує готовність до 5.2.

Актуальні мінімальні вимоги варто звіряти з офіційною інформацією про релізи Moodle.

Як перевірити свій сервер

Перевірка перед оновленням має бути окремим етапом проєкту. Її результатом повинен стати не набір технічних показників, а зрозуміла відповідь на три питання: чи можна оновлюватися, що блокує перехід і які роботи потрібно виконати до міграції.

Крок 1. Зафіксувати поточне середовище

Спочатку потрібно скласти короткий технічний паспорт платформи. У ньому достатньо зафіксувати:

• поточну версію Moodle;
• версію PHP;
• тип і версію СУБД;
• тип хостингу або серверної інфраструктури;
• приблизний обсяг даних;
• сторонні та кастомні плагіни;
• наявність резервного копіювання;
• наявність тестового середовища.

На цьому етапі важливо не змінювати конфігурацію, а отримати достовірну картину того, з чим працює заклад зараз.

Крок 2. Порівняти середовище з вимогами Moodle 5.2

Далі кожен критичний компонент порівнюють із вимогами цільової версії. Результати зручно розділити на три групи:

• відповідає вимогам — змін не потрібно;
• потребує оновлення — компонент можна модернізувати до переходу;
• блокує міграцію — поточна інфраструктура або хостинг не дозволяють виконати необхідні зміни без окремого проєкту.

Такий підхід важливіший за перелік окремих параметрів: він показує реальний обсяг робіт і допомагає оцінити, чи є сенс оновлювати Moodle на поточному сервері.

Крок 3. Перевірити можливості хостингу

Навіть якщо програмні вимоги зрозумілі, потрібно переконатися, що хостинг дозволяє їх виконати. Для закладу принципово важливо знати:

• чи доступна потрібна версія PHP;
• чи можна використовувати підтримувану версію СУБД;
• чи є достатній контроль над середовищем для оновлення Moodle;
• чи підтримуються регулярні фонові завдання й резервне копіювання;
• чи є можливість створити тестову копію системи;
• чи вистачає ресурсів у періоди пікового навантаження.

Якщо на кілька з цих питань відповідь негативна, варто розглядати не окреме налаштування, а модернізацію або зміну інфраструктури.

Крок 4. Оцінити залежності

Серверні вимоги не можна розглядати окремо від плагінів і кастомних рішень. Наприклад, оновлення PHP може бути допустимим для Moodle 5.2, але проблемним для старого стороннього плагіна.

Тому зміни потрібно оцінювати як ланцюг залежностей:

серверне середовище → Moodle → плагіни → тема → інтеграції → навчальні сценарії.

Якщо критичний компонент не перевірений, готовність до міграції ще не підтверджена.

Крок 5. Скласти план переходу

За результатами аудиту формують послідовність робіт. У найпростішому випадку сервер уже відповідає вимогам і достатньо перевірити плагіни та виконати тестове оновлення. У складнішому — спочатку модернізують інфраструктуру, потім перевіряють систему на тестовій копії й лише після цього планують production-міграцію.

Корисно також визначити відповідальних за кожен етап: хто підтверджує серверні вимоги, хто перевіряє плагіни та інтеграції, хто погоджує вікно робіт і хто приймає рішення про запуск або відкладення міграції. Для закладу це перетворює технічну перевірку на керований проєкт із чіткими точками контролю. Якщо один із критичних блоків не підтверджений, краще вважати готовність неповною, а не переносити невизначеність безпосередньо у production-вікно.

Перед будь-якими змінами має бути перевірений бекап і зрозумілий план відновлення. Детальніше про загальну підготовку — у чеклісті перед оновленням Moodle.

Якщо PHP застарілий

Якщо поточний сервер не підтримує PHP 8.3 або новішу версію, це не означає, що потрібно одразу міняти всю платформу. Спочатку варто визначити, де саме виникає обмеження.

Є три базові сценарії.

1. Поточний хостинг може підтримувати потрібну версію. Тоді оновлення інфраструктури можна включити до підготовчого етапу міграції. Важливо перевірити не лише Moodle, а й сторонні плагіни та інтеграції.

2. Поточний хостинг технічно обмежений. Якщо провайдер не підтримує потрібне середовище або не дає необхідного рівня керування, варто порівняти вартість подальших обмежень із перенесенням Moodle на іншу інфраструктуру.

3. Перехід на 5.2 поки недоцільний. Якщо модернізація сервера припадає на критичний період навчального року або вимагає значних супутніх робіт, можна окремо оцінити перебування на іншій підтримуваній гілці Moodle. Але це має бути свідоме тимчасове рішення з урахуванням строків підтримки.

Ключовий принцип — не поєднувати без потреби кілька великих змін в одному production-вікні. Чим більше одночасно змінюється інфраструктура, ядро Moodle та сторонні компоненти, тим складніше локалізувати проблему у випадку збою.

Вибір СУБД

Moodle 5.2 не вимагає переходу всіх інсталяцій на PostgreSQL. Якщо заклад уже використовує підтримувану версію MySQL, MariaDB або PostgreSQL і система працює стабільно, сама по собі нова версія Moodle не є причиною змінювати СУБД.

Для діючої платформи вибір варто оцінювати за операційними критеріями:

Немає достатніх підстав називати PostgreSQL, MySQL або MariaDB універсально найкращим варіантом для всіх закладів освіти. Так само немає надійної відкритої статистики, яка дозволяла б коректно визначити одну СУБД як найпоширенішу саме в українських ЗВО.

Для нової інсталяції вибір можна робити ширше. Для чинної — безпечніше спочатку відповісти на питання, чи є реальна потреба щось змінювати.

Апаратні рекомендації

Підбір ресурсів для Moodle не варто прив’язувати лише до загальної кількості зареєстрованих користувачів. Значно важливіше, скільки людей працює одночасно і які дії вони виконують.

Наприклад, платформа з кількома тисячами студентів може працювати стабільно більшу частину семестру, але отримувати різкий пік навантаження під час одночасного старту тестування. Тому оцінювати сервер потрібно за реальними сценаріями роботи.

Перед оновленням корисно проаналізувати:

• пікову кількість одночасних користувачів;
• періоди масових тестів та іспитів;
• обсяг і темп зростання навчальних матеріалів;
• розмір бази даних;
• кількість сторонніх плагінів та інтеграцій;
• фактичне завантаження сервера у звичайні та пікові періоди;
• запас ресурсів на найближчий навчальний цикл;
• вимоги до резервного копіювання та відновлення.

Офіційні мінімальні характеристики Moodle корисні для розуміння нижньої межі, але не повинні сприйматися як готова конфігурація production-сервера для ЗВО. Для реальної системи потрібне sizing-рішення на основі навантаження, а не лише кількості користувачів.

Якщо платформа вже працює повільно на поточній версії, перехід на 5.2 не варто використовувати як заміну діагностиці. Спочатку потрібно зрозуміти причину: ресурси, база даних, плагіни, фонові процеси, архітектура або навантаження.

FAQ

Чи піде Moodle 5.2 на shared-хостингу?

Може, якщо конкретний тариф дає середовище, яке відповідає вимогам Moodle 5.2, і достатній рівень керування для оновлення, резервного копіювання та стабільної роботи. Тому важливий не сам тип «shared-хостинг», а реальні можливості провайдера.

Чи обов’язковий PostgreSQL 16?

Ні. PostgreSQL 16 — мінімальна версія лише для інсталяцій на PostgreSQL. Moodle 5.2 також підтримує інші СУБД у визначених мінімальних версіях.

Чи можна залишитися на PHP 8.2?

Для Moodle 5.2 — ні. Мінімальна підтримувана версія PHP — 8.3. Якщо поточне середовище працює на PHP 8.2, це потрібно врахувати в плані міграції.

Скільки місця на диску потрібно?

Універсальної цифри для закладу освіти немає. Потрібно врахувати не лише саму Moodle, а й навчальні файли, базу даних, резервні копії, темп приросту контенту та необхідний запас. Для production-системи розрахунок варто робити за фактичним використанням і прогнозом зростання.

Як зрозуміти, чи сервер готовий до оновлення?

Готовність підтверджується не однією версією PHP чи СУБД, а результатом комплексної перевірки. Потрібно знати поточну конфігурацію, порівняти її з вимогами Moodle 5.2, перевірити плагіни й інтеграції, оцінити можливості хостингу, протестувати оновлення на копії системи та мати перевірений план відновлення.

Якщо аудит виявив кілька блокерів одночасно, краще спочатку сформувати окремий план модернізації, а вже потім визначати дату оновлення Moodle.

Потрібно оцінити готовність сервера до Moodle 5.2? Аудит інфраструктури дає відповідь не лише на питання «чи відповідає сервер мінімальним вимогам», а й показує послідовність робіт, залежності, ризики та реалістичний сценарій переходу без експериментів на робочій платформі.

© BI-Systems. Передрук і поширення матеріалу дозволено за умови збереження авторства та активного посилання на оригінальну публікацію.