Привет! Меня зовут Андрей, я работаю в iSpring более четырёх лет — развиваю десктопные продукты. Более двух лет пишу на PHP. Летом 2023 года мы решили интегрировать Moodle с нашим конструктором курсов iSpring Suite, чтобы пользователи могли загружать курсы в систему всего за пару кликов. После двух недель изучения гайдлайнов по разработке плагина и написания прототипа мы приняли решение создать собственный плагин для Moodle.
В статье расскажу, с какими проблемами и трудностями я столкнулся при написании плагина, а также дам советы и решения, которые трудно найти на форумах или в официальной документации.
Статья будет полезна PHP-разработчикам, кто только начал писать плагин для Moodle или подумывает его написать.
Почему решили написать свой плагин для Moodle
Moodle — одна из крупнейших и бесплатных систем дистанционного обучения, созданная в 2001 году. Платформу активно используют в более чем 240 странах, а её сообщество насчитывает свыше 300 миллионов зарегистрированных пользователей. Moodle ценят за открытый исходный код, гибкую настройку курсов и интеграции с другими платформами для онлайн-обучения.
Кроме того, Moodle поддерживает курсы в формате SCORM, которые широко используют в онлайн-обучении. Наш конструктор iSpring Suite позволяет создавать курсы в этом формате, включая тесты и тренажёры
Многие наши клиенты, работающие в Moodle, используют iSpring Suite для создания контента. Однако они сталкиваются с рядом неудобств при работе с этой связкой:
-
Отчёт отображается в нечитаемом виде. Для его анализа приходится тратить много времени и сил.
Пример отчета SCORM в СДО Moodle Удаляется статистика при изменении материала в Activity Module (например, статистика по пройденному курсу пропадала при замене курса преподавателем).
Функционал Moodle можно расширить с помощью плагинов.
Плагин — компонент, который зависит только от ядра Moodle и предоставляет новый функционал. В моём случае нужно было создать плагин типа Activity Module. Это контейнер для поставки учебных материалов в Moodle. С помощью него можно загрузить материал, включить оценивание, назначить прохождение на пользователя и т. д.
Чтобы решить проблемы, с которыми сталкивались наши пользователи, мы решили разработать плагин iSpring Module для Moodle. Этот плагин упрощает интеграцию курсов, созданных в iSpring Suite, в Moodle, предоставляет удобные детальный и сводный отчёты, а также сохраняет статистику при перезагрузке материала в Moodle.
Для чего нужен плагин iSpring Module для Moodle
Цель плагина iSpring Module — загружать опубликованный в формате HTML5 курс и предоставлять возможности:
Просматривать опубликованный курс.
Собирать данные о прохождении курса.
Показывать сводный отчёт по всем попыткам и всем пользователям.
Предоставлять детальную статистику по прохождению курса пользователем.
Выставлять оценки.
Задавать параметры прохождения: время начала и конца, тип оценивания и многое другое.
Сохранять статистику при изменении материала. Например, при добавлении новых вопросов в тест статистика уже пройденного материала должна сохраняться.
Сам плагин iSpring Module можете посмотреть на официальной странице плагина на сайте Moodle.
5 советов при написании плагина
1. Выделите время на изучение архитектуры
Ранее я разрабатывал продукты, у которых нет ярко выраженного ядра, а вся архитектура представлялась набором модулей (или библиотек) с определёнными слоями (иногда их не было вовсе, но не будем вспоминать о тёплом, сердце греющем легаси).
А здесь у Moodle есть и ядро, и плагины, которые интегрируются в систему через БД и директорию с исходниками в определённом месте.
Не разобравшись в архитектурных подходах, которые заложены в Moodle, я начал создавать свои страницы для отображения. Мне нужно было отобразить стандартный для Moodle header, стандартный footer. Поначалу я пытался примерно подогнать стили и отображение под Moodle. Спустя несколько часов я нашёл стандартный Output API. Этот API отвечает за визуальные аспекты контента Moodle, содержит в себе средства и объекты визуализации, темы и шаблоны и многое другое.
В ядре Moodle явно выделены основные API: Database API, String API и другие. Это хорошо проработанные API, которые очень просто использовать, они хорошо задокументированы и выполняют то, что от них ожидаешь. Использование стандартных API существенно упростит жизнь разработчикам, ускорит разработку и сделает код более идиоматичным.
2. Не бойтесь изучать чужой код
Иногда нужно реализовать более сложный функционал, например добавить возможность записать оценку в систему GradeBook (система оценок в Moodle) или создать событие, чтобы оно отобразилось на дашборде у студента. С такой непростой задачей столкнулся и я.
Функционал по созданию событий, как и по работе с GradeBook, не выделен в отдельный API, не задокументирован, имеет побочные эффекты и специальные условия по вызову, которые также не описаны.
Справиться с такой задачей мне помогли другие плагины. Я скачивал плагины, которые уже прошли ревью, и смотрел, как в них реализован функционал. Это помогло мне найти ответы на интересующие вопросы, а также протестить, как это работает у себя локально.
3. Документируйте свой код
В гайде по разработке плагинов написано, что функционал плагина должен быть покрыт документацией. Неважно, насколько красиво названа функция или написан алгоритм, — всегда должен быть поясняющий комментарий.
Поначалу я не документировал сложные места в коде (например, работа с событиями или с GradeBook). Так получилось, что мне пришлось вернуться в такой код через три месяца и заново изучать, как работают механизмы. Документация кода с самого начала существенно бы упростила изучение кода и его доработку. К тому же будет меньше вопросов у ревьюера.
4. Запаситесь терпением на ревью плагина и будьте на связи с ревьюерами
Возможно, мне просто не повезло, но первого ответа по ревью ждал более трёх месяцев. За это время я успел забыть проект, поделать сторонние проекты, снова вернуться к плагину, допилить часть функционала и выложить новую версию. После первой публикации первое ревью было через четыре месяца, а окончательно выложили плагин через девять месяцев.
В Moodle есть такая замечательная вещь, как очередь на ревью плагина. Каждый новый плагин в Moodle попадает в очередь на просмотр. Должно это работать так:
Добавляем новый плагин Moodle.
Попадаем в очередь. Скажем, на 45 место.
Через 44 плагина обязательно посмотрят добавленный плагин.
Это идеальный сценарий, который не сработал на практике. Плагин попал на 150+ место, четыре месяца ожиданий, плагин не поднимался в очереди выше 60 места.
После повторной публикации плагина место в очереди начало увеличиваться: сначала было 42, потом 50, потом и вовсе перешло на 60.
Здесь поможет связаться с ревьюерами напрямую и договориться о том, когда пройдёт ревью плагин, получить представление о времени прохождения ревью в рамках очереди.
5. И запаситесь ещё терпением на ревью переводов
Особенность Moodle: чтобы сделать плагин доступным на нескольких языках, нужно сначала задать английские сообщения, а затем перевести их через систему переводов Amos.
С одной стороны, очень удобно менять переводы без обновления плагина и не ждать прохождения ревью ещё раз. С другой — нужно пройти ревью в Amos. Нельзя просто взять и добавить переводы без ревью. Переводы должен одобрить ответственный за локализацию на добавленном языке. Будьте готовы к неопределённостям, так как сроков ревью и очереди нет.
Здесь также рекомендую связываться с ответственными за локализацию на определённый язык. Лучше попросить их напрямую, чем ждать, когда они сами назначат ревью переводов и посмотрят. Так будут известны хотя бы сроки ревью.
Резюме
Написать плагин iSpring Module было непросто, но вот какие три вещи мне помогли:
Хорошо проработанные и задокументированные базовые API: Database API, String API.
Чёткая структура и правила разработки плагинов: все правила оформлены в виде документации и расположены на официальном сайте, поэтому есть куда подсматривать.
Большое сообщество разработчиков Moodle, готовое помочь и поделиться опытом. Большую часть ответов на свои вопросы я находил именно там.
Создание плагина с открытым исходным кодом для одной из крупнейших СДО оказалось увлекательным занятием. Несмотря на сложности, я с интересом изучал документацию и исходный код Moodle, открывая для себя множество нюансов.
На разработку ушло около 400 часов, ревью длилось 9 месяцев, и сейчас плагин переведён на 10 языков.
Пишите в комментариях о своих сложностях при создании плагинов для Moodle — с удовольствием прочту и отвечу на вопросы. Если хотите узнать больше о внутреннем устройстве iSpring Module, дайте знать, и я подготовлю следующую статью.