Чекліст перевірки Moodle перед оновленням версії

Вступ

Застосовність: підготовка до оновлення підтримуваних версій Moodle. Конкретні системні вимоги завжди потрібно звіряти з release notes цільової версії. Для Moodle 5.2 мінімальна версія PHP — 8.3.

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

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

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

Зміст

• Блок 1. Інвентаризація
• Блок 2. Сервер і сумісність
• Блок 3. Плагіни й теми
• Блок 4. Видалений функціонал
• Блок 5. Бекап, який справді відновлюється
• Блок 6. Тестове середовище
• Блок 7. Організаційне
• FAQ

Блок 1. Інвентаризація

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

Зафіксуйте точну версію Moodle, включно з мінорним релізом і номером збірки. Формулювання «у нас Moodle 4» недостатньо: допустимий прямий шлях оновлення залежить від конкретної гілки. Наприклад, офіційна документація для Moodle 5.2 дозволяє прямий апгрейд лише з Moodle 4.4 або новішої версії. Якщо сайт старіший, потрібен проміжний етап.

Далі зберіть характеристики середовища:

• версію PHP та спосіб його запуску;
• СУБД і точну версію сервера бази даних;
• операційну систему;
• вебсервер — Apache, nginx, IIS або інший;
• розмір бази даних;
• обсяг каталогу moodledata;
• кількість активних курсів і користувачів;
• перелік інтеграцій: LDAP, OAuth 2, SSO, SMTP, відеосервіси, антиплагіат, зовнішні репозиторії тощо;
• спосіб розгортання коду — Git, Composer, архіви, панель хостингу або власний CI/CD.

Окремо зафіксуйте всі зміни ядра, якщо вони є. Модифікація core-файлів ускладнює апгрейд: стандартний код можна отримати заново, а локальні зміни потрібно або відтворювати, або переносити в підтримуваний механізм розширення.

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

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

Блок 2. Сервер і сумісність

Наступний крок — порівняти поточне середовище з вимогами цільової версії, а не з вимогами тієї Moodle, яка працює зараз.

У самій Moodle для цього є сторінка Site administration → Server → Environment. Офіційна документація прямо вказує, що через неї адміністратор може перевірити відповідність системним вимогам поточної та майбутніх версій.

Для Moodle 5.2 один із головних стоп-факторів — PHP нижче 8.3. Також Moodle 5.2 має мінімальні вимоги до СУБД: PostgreSQL 16, MySQL 8.4, MariaDB 10.11, Microsoft SQL Server 2019; Oracle Database більше не підтримується з Moodle 5.0. Окремо потрібні 64-бітний PHP, розширення sodium і max_input_vars не менше 5000.

Точні значення краще не тримати в локальному чеклісті роками: вони змінюються між релізами. Перед кожним апгрейдом звіряйте їх із офіційними release notes. Для переходу на 5.2 детальніше дивіться матеріал «Системні вимоги Moodle 5.2».

Є ще одна перевірка, яку легко пропустити під час переходу зі старіших гілок на 5.2. Починаючи з Moodle 5.1 змінилася структура каталогів: вебдоступні файли розміщуються в новому каталозі public, а чутливі файли винесено за його межі. Тому при переході на 5.2 з Moodle 5.0 або старішої версії потрібно заздалегідь перевірити конфігурацію вебсервера. Це не проблема, яку варто вперше виявляти під час виробничого вікна.

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

Для кластерної або контейнерної інфраструктури перевірка має охоплювати всі вузли, а не лише сервер, на якому відкрилася сторінка Environment. Окремо звірте версію PHP CLI з версією PHP вебпроцесу: cron та admin/cli/upgrade.php виконуються через CLI, і різні версії PHP для вебу та командного рядка можуть дати різну поведінку. Перевірте також вільне місце на диску: під час копіювання moodledata, дампів бази й розпакування нового коду тимчасова потреба в дисковому просторі може бути значно більшою за розмір фінальної інсталяції.

Блок 3. Плагіни й теми

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

Відкрийте Site administration → Plugins → Plugins overview. Ця сторінка показує встановлені плагіни, їхні версії, релізи, стан увімкнення та доступність налаштувань. Зафіксуйте цей список окремо — він стане реєстром залежностей.

Для кожного стороннього компонента варто мати щонайменше п’ять полів:

1. назва й тип плагіна;
2. поточна версія;
3. розробник або відповідальна команда;
4. заявлена сумісність із цільовою Moodle;
5. критичність для навчального процесу.

До плагінів потрібно віднести й тему оформлення. Кастомна тема може використовувати API, шаблони або JavaScript, які змінилися між версіями, тому візуально «невелика» модифікація іноді створює великий обсяг перевірки.

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

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

Детальний порядок аудиту винесено в окремий матеріал: «Сумісність плагінів Moodle перед оновленням версії».

Блок 4. Видалений функціонал

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

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

Наприклад, офіційна інструкція оновлення Moodle 5.2 окремо попереджає, що блок Activities видалено: сторінки курсів або Dashboard, де він використовувався, втратять цей блок після апгрейду. Це не обов’язково зупинить оновлення технічно, але змінить інтерфейс для користувачів.

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

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

Для переходів між 5.0–5.2 перелік таких змін варто звіряти окремо: «Що видалено з Moodle у версіях 5.0–5.2».

Блок 5. Бекап, який справді відновлюється

Перед апгрейдом Moodle потрібно резервувати не один файл і не лише базу даних. Офіційна документація виділяє три складові повного сайту:

• код Moodle;
• каталог завантажених файлів moodledata;
• базу даних.

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

Тому критерій готовності має звучати не «резервна копія створюється», а «ми знаємо, як із цієї копії відновити сайт і перевіряли цей процес».

Moodle має окрему процедуру Site restore для повернення коду, файлів і бази. Практично це означає, що до виробничого апгрейду варто хоча б один раз розгорнути копію в ізольованому середовищі й перевірити: сайт запускається, користувачі входять, курси відкриваються, файли доступні, а ключові дані на місці.

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

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

Докладніше — у матеріалі «Резервне копіювання Moodle: як перевірити, що відновлення спрацює».

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

Блок 6. Тестове середовище

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

Саме такий підхід рекомендує офіційна інструкція Moodle: спочатку протестувати оновлення на копії робочого сайту.

Що перевіряти після тестового апгрейду:

• вхід адміністратора, викладача й студента;
• основні методи автентифікації;
• відкриття типових і найскладніших курсів;
• журнал оцінок;
• здачу й перевірку завдань;
• тести й банк питань;
• завантаження та відкриття файлів;
• поштові сповіщення;
• cron і scheduled tasks;
• критичні сторонні плагіни;
• кастомну тему;
• мобільний застосунок, якщо він використовується;
• зовнішні інтеграції;
• журнали помилок і продуктивність.

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

Для критичних функцій краще мати короткі сценарії приймального тестування: «студент входить → відкриває курс → здає файл», «викладач відкриває роботу → виставляє оцінку → студент бачить результат», «cron запускається → scheduled tasks завершуються без помилок». Такий формат значно надійніший за загальний перегляд кількох сторінок після апгрейду.

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

Блок 7. Організаційне

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

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

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

До вікна робіт підготуйте:

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

Безпосередньо перед апгрейдом сайт переводять у режим обслуговування. Офіційна інструкція Moodle також радить дочекатися завершення активних cron-процесів. CLI-скрипт оновлення сам по собі не вмикає maintenance mode і не створює резервної копії — ці дії потрібно виконати окремо.

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

Після проходження цього чекліста наступним кроком уже є сама процедура оновлення: «Оновлення Moodle 4.5 до 5.2: покрокова інструкція».

 

FAQ

Скільки часу займає підготовка до оновлення Moodle?

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

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

Чи потрібне тестове середовище для малого ЗВО?

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

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

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

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