Що видалено з Moodle 5.0–5.2: Atto, Chat, MNet, Oracle

Вступ

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

Для Moodle 5.0–5.2 є важливе уточнення: Atto, Chat, Survey, CAS, MNet і підтримку Oracle Database вилучили саме в Moodle 5.0. У release notes Moodle 5.1 і 5.2 ці компоненти не фігурують як нові вилучення. Тому діапазон «5.0–5.2» у цій статті означає версії, на які переходять заклади, а не три окремі хвилі видалення.

Офіційний перелік змін можна звірити в розділі Moodle Releases.

Зведена таблиця

Найважливіше — розрізняти «видалено з ядра» і «функціонал більше не існує взагалі». У частині випадків компонент можна встановити окремо або замінити іншим рішенням. В інших, як із MNet або Oracle, потрібна зміна архітектури.

Компонент	Що сталося	Версія	Практичний напрям заміни	Статус після вилучення з ядра
Atto	Видалено з ядра	5.0	TinyMCE; за потреби — окремий Atto	Atto існує як окремий плагін, але потребує окремої перевірки сумісності
Chat	Видалено з ядра	5.0	Підтримуваний інструмент синхронної комунікації, Matrix або інше рішення	Legacy-репозиторій MoodleHQ архівований і активно не підтримується
Survey	Видалено з ядра	5.0	Feedback або Questionnaire — залежно від сценарію	Legacy-репозиторій MoodleHQ архівований; Questionnaire є окремим підтримуваним плагіном
CAS authentication	`auth_cas` видалено з ядра	5.0	OAuth 2 / OpenID Connect, LDAP або окреме CAS-рішення — залежно від IdP	Потрібна окрема перевірка поточного способу SSO
MNet	MNet-плагіни видалено з ядра	5.0	Перепроєктування SSO та інтеграцій	Ключові legacy MNet-репозиторії MoodleHQ архівовані
Oracle Database	Підтримку припинено	5.0	Міграція на підтримувану СУБД	Oracle не входить до підтримуваних СУБД Moodle 5.0, 5.1 і 5.2

Офіційні release notes Moodle 5.0 також перелічують кілька суто технічних вилучень, зокрема mlbackend_php, DML/DDL-підтримку SQLite та підтримку legacy subplugins.php. Для більшості керівників і викладачів вони непомітні, але їх має врахувати команда, яка підтримує кастомний код.

Редактор Atto

Atto був штатним текстовим редактором Moodle багато років. У Moodle 5.0 його вилучили з ядра, а TinyMCE залишився основним редактором, що постачається разом із платформою. Сам TinyMCE входить до Moodle як стандартний редактор ще з версії 4.1.

Для закладу це не означає, що потрібно вручну переписувати весь текст у курсах. Текстовий редактор — це інтерфейс створення й редагування контенту, а не окреме сховище всього навчального матеріалу. Проте перед переходом варто протестувати курси, у яких використовували складне форматування, вставки HTML, медіа або функції сторонніх Atto-плагінів.

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

Atto не зник повністю: MoodleHQ виніс його в окремий репозиторій і плагін. Але це вже не частина стандартного ядра. Для довгострокового планування безпечніше спочатку з’ясувати, які функції Atto реально потрібні закладу, а вже потім вирішувати, чи встановлювати його окремо, чи переносити робочі сценарії на TinyMCE.

Практичний порядок перевірки:

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

Активність Chat

Активність Chat також вилучили з ядра в Moodle 5.0. Вона призначалася для синхронного текстового спілкування учасників курсу.

Тут важливо не трактувати «винесено з ядра» як автоматичну рекомендацію просто встановити старий компонент назад. Репозиторій MoodleHQ для legacy Chat архівований і позначений як такий, що активно не підтримується. Сам MoodleHQ радить для розширених сценаріїв синхронної комунікації розглядати сучасніші рішення, зокрема інтеграції на базі Matrix.

Тому перед міграцією варто відповісти на два запитання.

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

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

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

Активність Survey

У Moodle 5.0 з ядра вилучили й Survey. Це важливо не плутати з будь-яким опитуванням у широкому сенсі. Старий модуль Survey був орієнтований на готові стандартизовані інструменти, зокрема COLLES та ATTLS, а не на довільне конструювання анкет.

Legacy-репозиторій Survey від MoodleHQ нині архівований і активно не підтримується. Тому для нового робочого процесу доцільніше спочатку визначити, що саме викладачі робили через Survey.

Якщо потрібне власне опитування або збір зворотного зв’язку, у ядрі Moodle є активність Feedback. Вона дозволяє створювати запитання та збирати відповіді. Якщо потрібні ширші можливості анкетування, існує окремий плагін Questionnaire, який на момент перевірки підтримує Moodle до 5.2 і призначений саме для створення власних опитувальників. Каталог актуальних розширень варто перевіряти через Moodle Marketplace.

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

Автентифікація CAS і MNet

Це найкритичніший блок статті, тому що помилка тут може вплинути не на одну активність у курсі, а на вхід користувачів у систему.

CAS

Плагін автентифікації auth_cas вилучили з ядра в Moodle 5.0. Якщо заклад використовує Central Authentication Service як частину єдиного входу, цей факт потрібно перевірити одним із перших під час підготовки до оновлення.

Універсальної заміни «CAS → один конкретний плагін» немає. Вибір залежить від того, який Identity Provider використовується в закладі та які протоколи він підтримує. Moodle має штатні механізми OAuth 2 і LDAP; для OpenID Connect та SAML існують окремі рішення в екосистемі плагінів.

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

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

MNet

Moodle 5.0 видалив із ядра MNet-плагіни. Це суттєвіше, ніж проста заміна одного модуля: MNet використовувався для взаємодії між Moodle-сайтами, автентифікації та віддаленого зарахування.

Офіційні MoodleHQ-репозиторії для ключових MNet-компонентів, зокрема auth_mnet, enrol_mnet і mnetservice_enrol, архівовані та не публікуються як звичайні підтримувані плагіни в каталозі. Тому будувати нову довгострокову архітектуру на поверненні старого MNet ризиковано.

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

Підтримка Oracle

Починаючи з Moodle 5.0, Oracle Database більше не підтримується. Це прямо зазначено в офіційних вимогах Moodle 5.0, 5.1 і 5.2.

Якщо ваша Moodle працює на Oracle, оновлення до гілки 5.x перетворюється на два пов’язані проєкти: міграцію СУБД і оновлення Moodle. Їх не варто сприймати як одну технічну кнопку.

Moodle підтримує інші СУБД, зокрема PostgreSQL, MySQL, MariaDB та Microsoft SQL Server у мінімальних версіях, визначених для конкретного релізу. MoodleDocs також описує інструмент Database transfer, який дозволяє переносити сайт між типами баз даних, наприклад із MySQL на PostgreSQL. Для Oracle-проєкту все одно потрібне окреме тестування сумісності, обсягу даних, часу перенесення та процедури відкату.

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

Як перевірити, чи вас це зачіпає

Перед оновленням не потрібно виходити з припущення «ми цим, здається, не користуємося». Потрібна коротка інвентаризація.

1. Перевірте текстові редактори. У керуванні плагінами та редакторами зафіксуйте, чи використовується Atto, чи є додаткові Atto-плагіни та які з них реально потрібні викладачам.

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

3. Перевірте методи автентифікації. У списку способів входу з’ясуйте, чи використовується CAS або MNet. Якщо так — це окремий блок робіт до оновлення, а не після нього.

4. Перевірте міжсистемні залежності. Якщо є кілька Moodle-сайтів, Mahara або інші системи, з’ясуйте, чи не використовують вони MNet для SSO, переходів або зарахування.

5. Перевірте СУБД. Якщо платформа працює на Oracle, міграцію бази потрібно включити до проєкту переходу ще до вибору виробничого вікна.

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

Для повної підготовки використовуйте також чекліст перевірки Moodle перед оновленням.

FAQ

Чи зникнуть старі чати з курсів після переходу на Moodle 5.x?

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

Що буде з контентом, який створювали в Atto?

Звичайний текст і HTML-контент не є «файлами Atto» — редактор використовується для їх створення та редагування. Основний ризик стосується спеціального форматування й сторонніх Atto-плагінів, які могли додавати власну розмітку або функції. Такі курси потрібно протестувати в TinyMCE до переходу.

Чи можна просто встановити Atto назад?

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

Чи треба терміново відмовлятися від CAS?

Якщо чинна версія Moodle ще підтримує вашу реалізацію, сам факт вилучення auth_cas із ядра Moodle 5.0 не означає негайного вимкнення поточної системи. Але до переходу на 5.x потрібно мати протестований план автентифікації, інакше ризик стосується входу всіх залежних користувачів.

Чи є пряма заміна MNet?

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

Чи можна оновити Moodle 5.x, залишивши Oracle?

Ні, Oracle Database не входить до підтримуваних СУБД Moodle починаючи з 5.0. Перед переходом потрібно спланувати міграцію на підтримувану СУБД і перевірити її на копії системи.

Якщо аудит показує Atto-залежності, старі активності, CAS/MNet або Oracle, це не означає, що оновлення неможливе. Це означає, що міграція потребує окремого плану заміни компонентів до виробничого апгрейду. Такий аудит дозволяє заздалегідь оцінити обсяг робіт, а не виявляти критичні залежності вже у вікні оновлення.