Getting started in Moodle development

Moodle is a great, mature open source LMS. But how does a person get started on the road to becoming a credible and experienced Moodle developer?

Here are three steps developers can follow to get started in Moodle development:

Step 1: Have the required programming skills

Moodle is a modular application which brings together code from many open source projects. To get involved in Moodle development, you will need to have some experience programming using:

PHP
MySQL database
HTML5
CSS
JavaScript
jQuery (you also still find a lot of older YUI code around)
Bootstrap version 2 and 4 (as of Moodle 3.2)
Git and GitHub

Step 2: Test and fix 3rd party Moodle plugins

Almost everything created for Moodle is a plugin of one type or another. As a Moodle developer, most of your work will involve creating Moodle plugins. Even themes are a type of plugin.

Look through the list of 3rd party Moodle plugins available for adoption by a new maintainer and choose one that sounds interesting to you. This is the easiest path. Note: Moodle Activity Modules (mod) tend to be more elaborate and require more frequent changes to keep them compatible with each new release of Moodle than most other types of plugins. You will see this because the author tends to have different downloads for different versions of Moodle. If you want to get through more plugins with easier issues, I recommend that you start with one of the other types of plugins.

Some authors forget to make put up their plugin for adoption when they loose interest in it so the second best place to look is in the list of 3rd party Moodle plugins. Look for one that does not currently support the last couple of releases of Moodle. In this case, always contact the author before you start just to make sure he/she isn't in the middle of a major re-write (that happened to me once). If you don't hear back from them within a week or so, chances are pretty good that they aren't doing anything with the code. You can also check plugin's GitHub repository which is usually linked from the plugin's page on Moodle.org. If there hasn't been any new development or releases in the past year, you may discover that the author is simply no longer interested in maintaining the plugin. At that point you may request to become responsible for the maintenance of the plugin - even if it is just to bring it up to date this one time. If you think an old plugin is interesting and might be useful for you, chances are there are others who would think so too and there are plenty of useful abandoned plugins just waiting to be updated.

This is a great way to get started on your way to learning how Moodle works. Older plugins often just need simple fixes, updates to deprecated API calls to get them up and running. You'll usually find a list of changes to the Moodle API in a file called upgrade.txt located in many of the directories off the Moodle root directory.

The process of fixing up these plugins will also help you become familiar with basic Moodle code templates for plugins and standard Moodle coding styles. The coding style is strictly enforced. If you don't take the time to learn it, you won't be able to publish any code on Moodle.org.

Here are a few things you can do to bring a plugin up to current Moodle standards:

Test and fix any errors. Turn on Developer debugging mode, check the box to display error and then see if there are any error messages that show up. Start by installing the plugin and then try out the plugin - all with debugging mode turned. Errors will often, but not always appear at the top of the HTML source code. I am always amazed at how many developers don't do this resulting in simple things like un-initialized variables. This is often such an easy fix.
Test and fix any HTML issues from HTML generated by the plugin. You can just view the HTML and CSS source code and paste it into the W3C Validation tool for HTML and for CSS. Always be sure to test your Front Page, dashboard and an empty course page before you get started to make sure the problem isn't with the theme you are using.
Test and fix multilingual support issues. This is pretty easy to do, even if you don't personally don't speak other languages. Just install a language pack other than English and then switch between English and that other language. I recommend choosing one of the more common languages because a lot of plugins haven't been translated so it might be a good idea to check the files in moodledata/lang/xx/ to make sure that a translation is available before you assume it's not working. These will obviously not end up in the right language even if there is a language pack available. Another way to do it is to just read through the source code and move hard coded text into the language file and use the get_string() function to retrieve it. To share a new language translation for a plugin, you will need to submit translations using the online Moodle AMOS Translation toolkit.
Test and fix the plugins to enable Moodle filter support. I like using the Moodle filter_multilangsecond's non-html {mlang} markup syntax for this it is very easy to implement. Be sure to enable it for both headers and content - the default is just content. Usually the issue can be corrected by wrapping a format_string() or format_text() function around the string being sent to the browser Just be sure that you only apply the these when necessary. I've run into situations where the developer saved the filtered string into the database making it useless if the user ended up changing language.
Test and fix accessibility issues. If you have any experience with WCAG 2.0, you could also test the plugins to make sure that they meet these accessibility guidelines, preferably at Level AA, from a students perspective. Not all plugins can easily be made accessible. For example, I've seen some plugins that require you to drag and drop objects. This kind of task would be very difficult to accomplish using a keyboard and would require more extensive modifications to the way the plugin works. Part of accessibility standards also involves ensuring that web pages are responsive so that they display properly regardless of the device. This may not have been a consideration when the old plugin was originally created and would need to be fixed.

In my experience, these tend to make up 90% of the issues I come across when implementing a 3rd party plugin. The rest are functionality bugs and display issues on mobile devices.

A lot of developers never even consider multiple language and accessibility issues however, these are some of the unique strengths that Moodle has over other LMS'. Tackle what you feel you can. If all you feel you can do is the HTML validation or uncovering bugs in Developer DEBUG mode right now, then just do that. Don't be afraid to ask questions. The only bad questions are those that are never asked in my opinion.

Before you submit your code, be sure to fully test the code and validate it using HTML and CSS W3C validation tools as well as the Moodle Code checker and the Moodle PHPdoc checker. These tools are not included with standard Moodle installations so you will need to install them.

In order to submit your new plugin on Moodle.org, you will need to register your plugin.

If you are submitting code changes for someone else's plugin, note that most authors prefer to receive code submissions through pull requests on GitHub. However, for small changes or if you are not familiar with Git, you could just post an issue and include the fix on GitHub or Moodle Tracker. To determine the right place, look for the "Bug Tracker" link on the plugin's page on Moodle.org. If you post your fix in the wrong place, the author may never receive notification of your change request.

All that said, if you want to be a Moodle developer, take the time to learn how to use Git and GitHub to maintain both your own projects and to submit pull requests for other people's code.

Tip: A lot of Moodle's development documentation is embedded within the source code. You'll find that a good search tool such as Agent Ransack for Windows to be extremely useful. Grep is often a favourite with command-line gurus on OS X and Linux.

Did you know? If you release an updated version of a plugin that has been tested and supports an upcoming version of Moodle, your plugin may be awarded a Moodle "Early Bird" badge.

Step 3: The General Moodle Developer forum

The General Moodle Developers Forum is is a great resource where you will find an active community made up of new and experienced users. If you have a question, there are probably many others who have a similar question but don't have the courage to speak up. As questions, read other peoples posts.

As you gain experience, contribute answers to questions asked by others. Just like in the physical world, communities only work well when everyone gets involved.

Did you know? If you contribute to the forums regularly and post information others find helpful, you can even be awarded the "Particularly helpful Moodler" badge.

For more information on Moodle development, see the Moodle developer documentation.