Greetings! My name is Andriy, I have been working at iSpring for over four years – developing desktop products. I have been writing in PHP for over two years. In the summer of 2023, we decided to integrate Moodle with our iSpring Suite course builder so that users can upload courses to the system with just a few clicks. After two weeks of studying the plugin development guidelines and writing a prototype, we decided to create our own plugin for Moodle.

In the article, I will talk about the problems and difficulties I encountered while writing the plugin, as well as give tips and solutions that are difficult to find in the forums or in the official documentation.

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

Why did you decide to write your 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 more than 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 courses in the SCORM format, which is 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 customers use iSpring Suite to create content. However, they face a number of inconveniences when working with this connection:

1. The report is displayed as unread. It takes a lot of time and effort to analyze it.

2. The statistics are deleted when the material is changed in the Activity Module (for example, the statistics of the completed course were lost when the course was replaced by the teacher).

The functionality of Moodle can be extended with the help of plugins.

A plugin is a component that depends only on the Moodle core and provides new functionality. In my case, I need to create an Activity Module type plugin. This is a container for delivering learning materials to Moodle. With its help, you can download material, enable evaluation, assign a user passage, etc.

To solve the problems faced by our users, we decided to develop the iSpring Module plugin 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.

Why do you need the iSpring Module plugin for Moodle?

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

1. View the published course.

2. Collect data on course completion.

3. Show summary report of all attempts and all users.

4. Provide detailed statistics on the user’s course completion.

5. Set grades.

6. Set course parameters: start and end times, grading type, and more.

7. Keep statistics when changing material. For example, when adding new questions to the test, the statistics of the material already passed must be saved.

You can view the iSpring Module plugin itself on the official page of the plugin on the Moodle website.

5 tips for writing a plugin

1. Set aside time to study architecture

I used to develop products that did not have a pronounced core, and the whole architecture was represented by a set of modules (or libraries) with certain layers (sometimes they were not there at all, but let’s not mention the warm heart of legacy that warms).

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

Not having understood the architectural approaches that are embedded in Moodle, I started to create my pages for display. I needed to display standard Moodle header, standard footer. At first, I tried to roughly adapt the styles and display to Moodle. In a few hours I found the standard Output API. This API is responsible for the visual aspects of Moodle content, including visualization tools and objects, themes and templates, and much more.

In the Moodle core, the main APIs are clearly highlighted: 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 learn other people’s code

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

Functionality for creating events, as well as for working with GradeBooknot allocated to a separate API, not documented, has side effects and special calling conditions that are also not described.

Other plugins helped me cope with such a task. I downloaded plugins that had already passed the review and looked at how they implemented functionality. It helped me to find answers to questions of interest and to test how it works locally.

3. Document your code

The plugin development guide says that plugin functionality should be covered by documentation. No matter how beautifully the function is named or the algorithm is written, there should always be a comment.

At first, I didn’t document the difficult places in the code (like working with events or with GradeBook). It so happened that I had to return to such a code after three months and relearn how the mechanisms work. Documentation of the code from the very beginning would greatly simplify the study of the code and its refinement. In addition, the reviewer will have fewer questions.

4. Be patient with the plugin review and stay in touch with the reviewers

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

Moodle has a great thing called queue for plugin roar. Every new plugin in Moodle is queued for review. It should work like this:

1. We are adding a new Moodle plugin.

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

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

This is an ideal scenario that has not worked in practice. The plugin got to 150+ places, four months of waiting, the plugin did not queue up more than 60 places.

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

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

5. And stock up on patience for the roar of translations

A feature of Moodle: to make the plugin available in several 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 not having to wait for the review to go through again. On the other hand, you need to pass the review in Amos. You can’t just take and add translations without a roar. Translations must be approved by the person responsible for localization in the added language. Be prepared for uncertainties, as there are no roaring and queuing deadlines.

Here I also recommend contacting those responsible for localization in a specific language. It is better to ask them directly than to wait for them to schedule a translation review themselves and take a look. So at least the terms of the roar will be known.

Resume

Writing the iSpring Module plugin was not easy, but what three things helped me:

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

2. Clear structure and rules for plugin development: all rules are documented and located on the official website, so there is plenty of room to peek.

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 SDFs turned out to be an exciting endeavor. 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 will be happy to read and answer questions. If you want to know more about the iSpring Module internals, let me know and I will prepare the next article.