Яку версію Moodle обрати у 2026: 4.5 LTS, 5.2 чи 5.3

Оновлено: 12 серпня 2026 року.

Актуально для: закладів, які працюють на Moodle 4.5–5.1 або планують нове розгортання. Moodle 5.3 LTS на дату оновлення ще не випущено; реліз заплановано на 5 жовтня 2026 року.

Якщо ви зараз обираєте між Moodle 5.0 і 5.2, варто змінити саму постановку питання. Moodle 5.0 уже не отримує загальних виправлень, а його безпекова підтримка завершиться 5 жовтня 2026 року. Тому 5.0 — не довгострокова ціль для нового проєкту або планового оновлення.

Практично вибір у 2026 році зводиться до трьох стратегій: залишитися на 4.5 LTS, перейти на актуальну 5.2 або підготуватися до 5.3 LTS. Moodle 5.1 формально підтримується, але її security support завершується 19 квітня 2027 року, тому зазвичай це радше проміжний варіант, а не цільова версія на кілька років.

Нижче — не рейтинг версій, а спосіб вибрати варіант під конкретну інфраструктуру, плагіни й навчальний календар.

Актуальні версії та терміни підтримки

За офіційним календарем релізів Moodle, станом на 12 серпня 2026 року ситуація така:

Найновіший випущений реліз гілки 5.2 на дату оновлення статті — Moodle 5.2.2 від 10 серпня 2026 року. Для 5.3 офіційна документація вказує запланований реліз 5 жовтня 2026 року та початок code freeze 24 серпня. Оскільки 5.3 ще не випущено, її дату та фінальні вимоги варто повторно звірити безпосередньо перед міграцією.

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

Що таке LTS і кому він потрібен

LTS — long-term support, тобто гілка з подовженою безпековою підтримкою. Для Moodle це не означає, що LTS отримує всі типи виправлень однаково довго. Наприклад, загальні bug fixes для Moodle 4.5 завершилися ще 6 жовтня 2025 року, тоді як security fixes надходитимуть до 4 жовтня 2027 року.

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

LTS зазвичай логічний вибір, якщо платформа сильно кастомізована, має багато сторонніх інтеграцій, складну автентифікацію або якщо кожне велике оновлення потребує тривалого погодження. Натомість організації, яким потрібні нові можливості Moodle швидше, можуть свідомо обирати поточний stable-реліз і частіше проходити цикл тестування.

Важливо також дивитися не лише на кінцеву дату security support, а й на момент, коли закінчується general support. Після цієї дати гілка не перестає працювати, але звичайні помилки ядра вже не виправляються в рамках стандартного циклу. Для платформи, де критичні нові інтеграції або функції, це може бути суттєвим аргументом не затримуватися на старшій LTS-гілці до останнього дня її безпекової підтримки.

Тому LTS — не синонім «найкраща версія для всіх». Це радше модель супроводу. Якщо заклад має окреме тестове середовище, регламент оновлень і ресурси на перевірку плагінів двічі на рік, non-LTS може бути цілком раціональним. Якщо ж кожен великий апгрейд потребує закупівлі, тендерної процедури, роботи зовнішнього підрядника або тривалого погодження простою, довший LTS-цикл може зменшити організаційне навантаження.

Варіант 1. Залишитись на 4.5 LTS

Залишатися на 4.5 LTS у серпні 2026 року — допустима стратегія, якщо ви вже на цій гілці, платформа стабільна, а перехід зараз створює більше операційного ризику, ніж користі. Офіційна security support триває до 4 жовтня 2027 року.

Водночас важливо не плутати «підтримується з погляду безпеки» з «отримує всі звичайні виправлення». General support 4.5 завершилася у жовтні 2025 року. Тому залишатися на 4.5 варто як на свідомо обраній стабільній базі, а не як на версії, яку можна більше не планувати оновлювати.

Цей сценарій особливо доречний для закладів із великою кількістю кастомних плагінів або тем. За рік до завершення security support уже варто мати план наступного переходу, а не починати аудит у жовтні 2027-го.

Варіант 2. Перейти на 5.2

Moodle 5.2 — актуальна стабільна гілка, випущена 20 квітня 2026 року. Загальна підтримка триватиме до 19 квітня 2027 року, безпекова — до 4 жовтня 2027 року. Якщо потрібен актуальний функціонал і немає причини чекати LTS, це найбільш прямий вибір зараз.

Але 5.2 має суттєві серверні вимоги. За офіційними release notes Moodle 5.2, потрібен PHP 8.3 або новіший; для PostgreSQL мінімум — 16, для MySQL — 8.4, для MariaDB — 10.11.0. Окремо Moodle 5.1 змінила структуру коду, ввівши каталог /public, тому при переході з 4.5 на 5.2 треба врахувати й конфігурацію вебсервера.

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

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

Варіант 3. Дочекатися 5.3 LTS

Moodle 5.3 має стати наступним LTS-релізом. За офіційною документацією Moodle 5.3, реліз запланований на 5 жовтня 2026 року, general support — до 4 жовтня 2027 року, security support — до 1 жовтня 2029 року.

Для закладу, який хоче перейти на новішу платформу й потім довше не робити великих апгрейдів, це сильний аргумент на користь 5.3. Поточні prerelease-вимоги також показують PHP 8.3+, PostgreSQL 16, MySQL 8.4 і MariaDB 10.11.0, тобто підготовка сервера до 5.2 значною мірою готує його і до 5.3.

Але «дочекатися» не означає нічого не робити до жовтня. На 12 серпня 5.3 ще не є production-релізом. До її виходу можна й варто інвентаризувати плагіни, підняти тестове середовище, оновити PHP і СУБД, перевірити резервні копії та прибрати технічний борг. Тоді після релізу рішення буде ґрунтуватися на результатах тестів, а не на календарній даті.

Матриця рішень

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

Окремий випадок — Moodle 5.1. Це підтримувана гілка з PHP 8.2+, тому технічно вона може бути коротким мостом для інфраструктури, яка ще не готова до 5.2. Але її security support завершується 19 квітня 2027 року, тому такий перехід слід оцінювати разом із вартістю ще одного наступного апгрейду.

Прихована вартість кожного варіанту

Вартість оновлення Moodle — це не лише години адміністратора в день міграції. Часто найдорожчі роботи відбуваються до натискання кнопки upgrade.

1. Серверне середовище. Перехід із 4.5 на 5.2 означає підвищення мінімальної версії PHP з 8.1 до 8.3. Для PostgreSQL мінімум змінюється з 13 до 16, для MySQL — з 8.0 до 8.4, для MariaDB — з 10.6.7 до 10.11.0. Якщо хостинг не дозволяє такі версії, у бюджет потрапляє оновлення сервера або міграція на іншу інфраструктуру.

2. Вебсервер. Починаючи з Moodle 5.1, змінилася структура каталогів: вебдоступні файли винесено в /public. Для переходу з 4.5 це означає перевірку document root і конфігурації вебсервера.

3. Плагіни й тема. Moodle рекомендує перед апгрейдом перевірити наявність сумісних версій сторонніх плагінів у Plugins overview та каталозі плагінів. Для кастомного коду автоматичної гарантії сумісності немає. Саме тут часто з'являються витрати на доопрацювання, заміну або відмову від компонента.

4. Тестове середовище й бекап. Офіційна інструкція з оновлення рекомендує спочатку відпрацювати перехід на копії production-сайту та мати повний резервний комплект. Це окремий ресурс: сервер, час адміністратора, місце для копій і час на тестування.

5. Навчання й підтримка користувачів. Чим більший функціональний стрибок, тим більше часу потрібно на короткі інструкції для викладачів, перевірку типових сценаріїв і підтримку в перші дні після запуску.

6. Простій. Навіть якщо саме оновлення ядра займає небагато часу, вікно має включати бекап, перевірку, можливий відкат і функціональне тестування. Планувати лише «час виконання upgrade.php» — занадто оптимістично.

7. Повторна міграція. Це особливо важливо, якщо 5.1 розглядається як тимчасовий міст. Такий варіант може зняти негайну вимогу переходу на PHP 8.3, але створює другий цикл робіт: ще один тестовий апгрейд, перевірку плагінів, вікно простою та контроль після запуску. Тому економію на інфраструктурі сьогодні потрібно порівнювати з повною вартістю двох переходів.

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

Тому найдешевший на вигляд варіант не завжди найдешевший у сумі. Залишитися на 4.5 може бути раціонально, якщо це дає час спокійно підготувати 5.3. Перехід на 5.2 може бути вигіднішим, якщо сервер і плагіни вже готові, а нові можливості потрібні зараз. Очікування 5.3 має сенс, якщо ви використовуєте час до релізу для підготовки, а не відкладаєте аудит на жовтень.

Чого не робити

Не оновлюйте production без тестової копії. Навіть якщо Moodle офіційно дозволяє прямий шлях із вашої версії, сторонні плагіни та локальні інтеграції можуть мати власні обмеження.

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

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

Не обирайте 5.3 лише через позначку LTS до фактичного релізу. Станом на 12 серпня 2026 року це майбутня версія. Планувати її можна вже зараз, але фінальне рішення слід підтвердити після виходу релізу та перевірки ваших плагінів.

Не зводьте вибір до номера версії. Якщо сервер не відповідає вимогам або критичний плагін не має сумісного релізу, теоретично «краща» версія може бути практично гіршим вибором.

FAQ

Чи обов'язково використовувати LTS?

Ні. Moodle 5.2 — поточна стабільна версія й отримуватиме security fixes до 4 жовтня 2027 року. LTS доцільний тоді, коли для закладу важливіший довший горизонт безпекової підтримки та рідші великі переходи, ніж максимально швидке отримання нових функцій.

Чи можна з Moodle 4.5 одразу перейти на 5.3?

За поточними офіційними prerelease-вимогами Moodle 5.3 мінімальна версія для апгрейду — Moodle 4.5, тобто прямий шлях передбачено. Але 5.3 ще не випущено. Перед production-міграцією потрібно повторно звірити фінальні release notes і протестувати перехід на копії вашої системи.

Як часто потрібно оновлювати Moodle?

Є два різні цикли. Мінорні релізи вашої гілки варто встановлювати в межах регламенту супроводу, особливо коли вони містять безпекові виправлення. Великі переходи між 4.5, 5.2, 5.3 тощо планують за життєвим циклом гілки, сумісністю плагінів і навчальним календарем. Універсального правила «раз на рік» немає.

Чи є сенс переходити з 5.0 на 5.1 замість 5.2?

Іноді — як тимчасовий технічний компроміс. Moodle 5.1 підтримує PHP 8.2, тоді як 5.2 вимагає PHP 8.3. Але security support 5.1 завершується 19 квітня 2027 року, тому потрібно заздалегідь рахувати вартість наступного оновлення. Якщо інфраструктура й плагіни готові до 5.2, довгостроково цей варіант зазвичай простіший.

---

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

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