For developers just getting started in Moodle development, testing and fixing 3rd party Moodle plugins which are not currently supported the latest version of Moodle is a great way to get started on your way to learning how Moodle works. These plugins often just need simple fixes, updates to deprecated API calls and stuff like that.

Start by browsing through the list of 3rd party plugins and choose a plugin that is of interest to you. If you think it would be useful for you, chances are there are others who would think so too. Next 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).

A few other things you could check as long as you are testing the plugins:

  1. Test and fix any errors. Just turn on Developer debugging mode, check the box to display error and then see if there are any error messages that show up. They 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 things like un-initialized variables.
  2. Test and fix any HTML issues from HTML generated by the plugin. You can just view the HTML source code and paste it into the W3C Validation. Just be sure to test yourFront Page before you get started to make sure it's not a problem with the theme you are using.
  3. 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.
  4. 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() functionaround 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.
  5. 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 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.

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. For example, I recently uncovered an issue with the "Browse Users" page where the table is wrapped in a "no-overflow" class. Unfortunately, the edit/delete links are at the end of the rows which means that they were being cut off and not-accessible on smaller screens. This wasn't a problem in Moodle 2.5 but 2 extra columns were added in Moodle 2.6. I guess nobody ever tried this page on a narrow screen.

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.

Don't forget to submit your changes back to the authors. Most authors prefer to get submissions through GitHub but, for small changes or if you are not familiar with Git, you could even just post an issue with a fix on GitHub or Moodle Tracker. Check the plugin's page to see the authors "Bug Tracker" link. If you post in the wrong place, the author may never receive your change request.

In some cases, especially with older plugins that were last released for Moodle 2.2, 2.3, 2.4 or 2.5, you may discover that the author is no longer be interested in maintaining the plugin. You may request to become responsible for the future maintenance of the plugin even if it is just to bring it up to date this one time.

Tip: I've noticed is that Moodle Activity Modules (mod) tend to need more changes for each new version 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, start with some of the other types of plugins.

Related Posts: