5 practical tips for creating a plugin for Moodle LMS

Hello! My name is Andrey, I have been working at iSpring for more than four years, developing desktop products. I've been writing PHP for more than two years. In the summer of 2023, we decided to integrate Moodle with our course builder iSpring Suiteso that users can upload courses to the system in just a couple of clicks. After two weeks of studying plugin development guidelines and writing a prototype, we decided to create our own plugin for Moodle.

In this article I will tell you what problems and difficulties I encountered when writing a plugin, and also give tips and solutions that are difficult to find on forums or in official documentation.

The article will be useful to PHP developers who have just started writing a plugin for Moodle or are thinking about writing one.

Why did you decide to write your own plugin for Moodle?

Moodle is one of the largest and free distance learning systems, created in 2001. The platform is actively used in more than 240 countries, and its community has over 300 million registered users. Moodle is valued for its open source code, flexible course customization, and integration with other online learning platforms.

In addition, Moodle supports SCORM courses, which are widely used in online learning. Our iSpring Suite designer allows you to create courses in this format, including tests and simulators

Many of our Moodle clients use iSpring Suite for content creation. However, they encounter a number of inconveniences when working with this bundle:

1. The report is displayed in an unreadable form. To analyze it you have to spend a lot of time and effort.

   

2. Statistics are deleted when the material in the Activity Module is changed (for example, statistics on a completed course disappeared when the teacher replaced the course).

Moodle functionality can be expanded using plugins.

A plugin is a component that depends only on the Moodle core and provides new functionality. In my case, I needed to create a plugin like Activity Module. This is a container for delivering learning materials to Moodle. Using it, you can download material, enable assessment, assign a passage to a user, etc.

To solve the problems that our users were facing, we decided to develop a plugin iSpring Module for Moodle. This plugin simplifies the integration of courses created in iSpring Suite into Moodle, provides convenient detailed and summary reports, and also saves statistics when reloading material into Moodle.

What is the iSpring Module plugin for Moodle used for?

The purpose of the iSpring Module plugin is to load a course published in HTML5 format and provide the ability to:

1. View a published course.

2. Collect course completion data.

3. Show a summary report for all attempts and all users.

4. Provide detailed statistics on the user's completion of the course.

5. Give ratings.

6. Set passing parameters: start and end time, type of assessment, and much more.

7. Save statistics when changing material. For example, when adding new questions to a test, the statistics of the material already covered should be preserved.

The iSpring Module plugin itself can be viewed on the official plugin page on the Moodle website.

5 tips for writing a plugin

1. Take time to study architecture

Previously, I developed products that did not have a clearly defined core, and the entire architecture was represented as a set of modules (or libraries) with certain layers (sometimes there were none at all, but let’s not remember the warm, heart-warming legacy).

And here Moodle has both a core and plugins that are integrated into the system through a database and a directory with sources in a certain place.

Without understanding the architectural approaches that are inherent in Moodle, I began to create my own pages for display. I needed to display the standard Moodle header, standard footer. At first I tried to roughly match the styles and display to Moodle. A few hours later I found the standard Output API. This API is responsible for the visual aspects of Moodle content, containing visualization tools and objects, themes and templates, and much more.

The Moodle core clearly identifies the main APIs: Database API, String API and others. These are well-designed APIs that are very easy to use, well documented, and do what you expect them to do. Using standard APIs will significantly simplify the life of developers, speed up development and make the code more idiomatic.

2. Don't be afraid to study other people's code

Sometimes you need to implement more complex functionality, for example, add the ability to record a rating in the system GradeBook (grading system in Moodle) or create an event so that it appears on the student’s dashboard. I also faced such a difficult task.

Functionality for creating events, as well as for working with GradeBookis not separated into a separate API, is not documented, has side effects and special conditions for calling, which are also not described.

Other plugins helped me cope with this task. I downloaded plugins that had already been reviewed and looked at how the functionality was implemented in them. This helped me find answers to my questions, as well as test how it works locally.

3. Document your code

The plugin development guide states that the functionality of the plugin must be covered by documentation. It doesn’t matter how beautifully the function is named or the algorithm is written, there should always be an explanatory comment.

At first, I didn't document difficult parts of the code (for example, working with events or with GradeBook). It so happened that I had to return to such code after three months and re-learn how the mechanisms worked. Documentation of the code from the very beginning would greatly simplify the study of the code and its modification. In addition, the reviewer will have fewer questions.

4. Be patient during plugin reviews and stay in touch with reviewers

Perhaps I was just unlucky, but I waited more than three months for the first response to the review. During this time, I managed to forget the project, do third-party projects, return to the plugin again, finish part of the functionality and publish a new version. After the first publication, the first review was four months later, and the plugin was finally released nine months later.

Moodle has such a wonderful thing as a plugin review queue. Every new plugin in Moodle gets queued for review. It should work like this:

1. Adding a new Moodle plugin.

2. We get in line. Let's say 45th place.

3. After 44 plugins, they will definitely look at the added plugin.

This is an ideal scenario that did not work out in practice. The plugin was ranked 150+, four months of waiting, the plugin did not rise above 60th place in the queue.

After re-publishing the plugin, the place in the queue began to increase: first it was 42, then 50, then it completely moved to 60.

Here it will help to contact the reviewers directly and agree on when the plugin will be reviewed, and get an idea of ​​the review time within the queue.

5. And be patient while reviewing translations

Moodle feature: to make the plugin available in multiple languages, you must first specify English messages and then translate them through the translation system Amos.

On the one hand, it is very convenient to change translations without updating the plugin and without having to wait for the review to go through again. On the other hand, you need to go through a review in Amos. You can’t just add translations without review. Translations must be approved by the person responsible for localization in the added language. Be prepared for uncertainties, as there are no review deadlines or waiting lists.

Here I also recommend contacting those responsible for localization into a specific language. It’s better to ask them directly than to wait for them to schedule a translation review and look at it themselves. This way, at least the timing of the review will be known.

Resume

Writing the iSpring Module plugin was not easy, but here are three things that helped me:

1. Well-developed and documented core APIs: Database API, String API.

2. A clear structure and rules for developing plugins: all the rules are presented in the form of documentation and are located on the official website, so there is something to look at.

3. A large community of Moodle developers, ready to help and share experiences. I found most of the answers to my questions there.

Creating an open source plugin for one of the largest LMSs was exciting. Despite the difficulties, I studied the documentation and source code of Moodle with interest, discovering many nuances.

The development took about 400 hours, the review lasted 9 months, and now the plugin has been translated into 10 languages.

Write in the comments about your difficulties when creating plugins for Moodle – I’ll be happy to read and answer your questions. If you want to know more about the internals of the iSpring Module, let me know and I'll prepare the next article.