Plugins traffic

Occasional news and blog-like posts from the Moodle plugins development airspace. Visit our Plugins directory and follow @moodleplugins.

Picture of David Mudrák
Last week plugins arrivals - 2015.06.01
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

There were 6 plugins reviewed last week, 4 of them were approved and published in the Plugins directory:

Picture of David Mudrák
Moodle Plugins directory update
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

I’m pleased to announce a number of new features, improvements and bug fixes in the Moodle Plugins directory:

  • Statistics on the number of sites using a plugin are now available, both the number of sites currently using the plugin and as a chart of usage over time. Usage data is aggregated from available update checks (MDLSITE-4015).
  • Downloads, usage and favourite stats are now displayed in lots of places, such as on the search results page, category pages and other listings pages (MDLSITE-3682).
  • Category and other listings pages are now sorted with the most popular plugins at the top, as determined by users when they mark plugins as their favourites. Recently updated plugins are also prioritised in listings. Thus, to have your plugin at the top of the list, make it awesome so that users love it and keep it up-to-date!
  • Screenshots of plugins are now displayed on listings pages. We've always recommended for plugin maintainers to provide illustrative screenshots of their plugin's user interface. If you have multiple screenshots uploaded (as you should!) you can mark one as the "main file" in the screenshots file manager, for use on the listings page. If there is no main file set, the first screenshot is used.
  • Small improvements in the navigation block aim to make it clearer whether a stats page applies to the whole directory or just the category page or a particular plugin.
  • The chart showing total downloads by month within a single category now correctly shows data for the selected category only, rather than for the whole directory.
  • A security bug allowing unauthorized access to the list of other user's sites has been fixed (MDLSITE-4056).

Many thanks to everybody who helped with the implementation of these features in the tracker, forums or chats.

Picture of David Mudrák
Last week plugins arrivals - 2015.05.25
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Total of 16 submitted plugins were reviewed and 11 of them were cleared to land to the Plugins directory.

  • Download certificates block provides easy access to all certificates issued to the user across all courses on the site.
  • Two new Atto plugins - Font family and Styles allows to add new buttons to the editor toolbar to change the text's font or the text's CSS class, respectively.
  • Flowchart filter lets you render various flowcharts defined in the text with a syntax similar to LaTeX without the need to embed them as images.
  • Course description module can display the course name and the course description on the course page as a resource.
  • Poster module allows creating a page in the course, contents of which is composed of existing Moodle blocks (such as HTML block, Calendar block, Latest news block etc.).
  • Fullscreen toggle button is just that - it adds a button to the page that expands the content area by hiding all side blocks.
  • Question filters extends the search options in large question banks.
  • Auto group assigns users in a course into groups based on the value of their user profile field (such as preferred language or department).
  • User suspension admin tool allows to easily suspend or even remove site users, e.g. after a defined period of inactivity. It comes with a helpful counterpart User restore that allows the admin to undelete previously removed user accounts.
Picture of David Mudrák
Featured plugin: Bootstrap theme
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

There are many awesome contributed themes available for Moodle. Featuring some of them is tricky as when it comes to a site theme, the aesthetical aspects are usually more important than the technical (coding related) ones. Still, there is a theme that definitely deserves the Featured plugin award. Not only for being visually appealing and having a clear code without major issues. But mainly for being a solid foundation for further tweaking and development of other child themes. It is the Bootstrap theme developed and maintained by Bas Brands.

The theme integrates the well known Bootstrap framework with Moodle. Earlier version of the theme, built on top of the version 2.3 of the framework, has been merged into the Moodle 2.5 core and is now known to themers as Bootstrap Base. Bas continued with the development and the theme available in the Plugins directory is now using recent versions of the Bootstrap framework, whereas the merged theme_bootstrapbase has been maintained as a stable solution to keep backwards compatibility with existing child themes (such as the default Clean theme).

I asked Bas, the current maintainer of the Bootstrap theme, for an interview. Read on and see how the development of the theme has started at one of our MoodleMoots, what skills are needed to build a succesful Moodle theme and how contributing to an open-source project can help you to find a paid job position.

Hi Bas. Can you tell us something about yourself and your background?

Photo of Bas Brands and his dog

Bas having a break from coding

I grew up in a small village called Vaassen in the Netherlands and studied at the International Agricultural College in Arnhem. I have always been interested in learning how things work. During my education it was ecology, chemistry and biology. Then I got my first computer and I wanted to learn how it worked and how to tweak it.

While learning about (re)creating new wilderness areas at college, I spent a lot of time building my own Linux kernels and experimenting with code. As soon as I finished college I started working for Sun Microsystems at the Educational center. I helped set up classroom environments and got the chance to work with some very cool and big machines. Since then, I have been active in Open Source communities and worked in various companies ranging from medical to multimedia.

Since 2012 I have been working as a Moodle freelancer. Thanks to videoconferencing it’s easy to work for projects all over the world, as long as you don’t mind being flexible on the time you schedule them. I don’t have to travel much and my dog forces me to take regular breaks. I like going camping with my partner and dog.

How did you get into Moodle and Moodle development?

I applied for a job as a Linux sysadmin for a Dutch Moodle Partner company. They told me the job was already taken but they did have another position that might interest me: doing Moodle systems management and some coding. Since then, I have not stopped working with Moodle and learning more about it.

What features of your Bootstrap theme would you highlight? What makes it unique when compared with standard themes shipped with Moodle?

The Bootstrap theme has had quite a history. It is based on the work done for the Twitter Bootstrap project by Mark Otto and Jacob Thornton. They created the Bootstrap framework which has been adopted in many systems.

The idea for the Bootstrap Moodle theme started when Stuart Lamour (working at Sussex University at the time) told me he could create a very cool theme with little effort using Bootstrap. It wasn’t there yet but in a few days it could be done.

It turned out to take a lot more time, but we started a Github project and did some coding. Soon after, we discovered David Scotson was working on a Bootstrap theme too. We contacted him and arranged a conference call. David is a talented front-end developer and is open (source) minded. We started working together and soon more developers started to contribute.

At the Dublin MoodleMoot in 2013 the roadmap for getting the Bootstrap theme into core started. It has now been included in the core Moodle for over a year; you can find it in your install in theme/bootstrapbase.

The development of the (contrib) Bootstrap theme has continued and the Bootstrap theme that is in core is a version on its own. The contrib theme is now based on version 3 of the Bootstrap framework and uses jquery libraries.

Both the Bootstrapbase theme and the Bootstrap theme in the plugins directory are parent themes. They provide a stable and multi-device friendly base to use when creating a custom designed theme.

Where do you get inspiration for designing Moodle Themes?

Listening to web designers talk on TEDx / Youtube can really help you to learn what’s important in design. I think design is an art and it takes time to develop your art skills. Looking at other design disciplines will improve your web design skills and talking with designers and developers motivates you to try your own designs. The people I have met in the Moodle community and open source design community have been my greatest inspiration.

What software and IDE do you use when developing for Moodle and how does your typical screen look like?

I use simple tools - Sublime text for coding, Firefox for front-end development and the rest using my terminal. My screen is as empty as possible.

Bas' desktop

Many Moodle plugin developers are looking for a business model that would, at least partially, cover the time spent on their plugin development and support. Can you give some recommendations based on personal experience?

When you write a plugin that improves Moodle for many users, you should release it early, ask for feedback and when you receive it, act on it. Don’t be afraid to share your code and don’t worry if others are working on similar projects. Your skillset is your most important asset when finding paid-for projects and your Github repositories are part of your resume.

What advice do you have for designers/developers who are new in the Moodle community?

Invite yourself to the party; the Moodle community is one of the best open source communities you will find. Identify some measurable problem and do some work on it to show your potential. Be bold, honest and humble. Relax your ego, give recognition and invite others to your quest. Don’t be afraid to ask the community if you get stuck.

Get to know the other developers: visit a Moodle conference and attend the scheduled Moodle developer meetings.

But most of all remember you are developing / designing for users. Always ask for feedback!

Thanks Bas. And good luck with all your contributions!

Picture of David Mudrák
Moodle version 2.9 added into the Plugins directory
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Now that Moodle 2.9 beta is available, it is time to start looking at your plugins to make sure they work well with this upcoming version. I just added 2.9 as a supportable Moodle version into the Plugins directory.

The plugins maintainers are now supposed to make a version of their plugin available for Moodle 2.9.

  • Test your plugin functionality with Moodle 2.9. Make sure you have developer debugging enabled to catch all the warnings and notices.
  • Test new installation of your plugin as well as upgrading from a previous version.
  • If you find your current version of the plugin still working well in 2.9, you may want to just edit the version details (your plugin page > download versions > edit details) and add Moodle 2.9 into the list of supported versions.
  • If you are going to release a new plugin version for Moodle 2.9, make sure it has it selected in the list of supported Moodle versions.

As always, please pay attention to valid plugin versioning scheme as described at version.php documentation page.

Please note that updating the list of supported Moodle versions is essential to make the whole machinery around available updates notifications and on-click plugin installation working correctly. It is also a good sign of an active and responsible maintenance.

Thanks for keeping your plugins up-to-date with Moodle core development!

Picture of David Mudrák
Featured plugin: moosh
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Today's featured plugin is moosh. The name stands for MOOdle SHell. It is a command-line tool that will allow you to perform most common Moodle tasks. It has been inspired by Drush - a similar tool for Drupal.

Strictly speaking, the moosh is not a Moodle plugin. It is a standalone utility and can not be installed by plugin installer built into the Moodle administration interface. Still it is registered with the Plugins directory and actively maintained by Tomasz Muras.

Hi Tomek. Can you shortly tell us something about yourself and your background?

Photo of Tomasz Muras

Software engineer and a big fan of Open Source.

Heh, that was short indeed smile Can you describe the moosh and its main features? Who is it primarily intended for?

It’s a commandline tool that exposes some Moodle functionality. Making it CLI means that using moosh for some things is super quick and convenient - it basically brings the power of Linux commandline into Moodle.

You install it only once on your machine/server and use against all Moodle instances on that host. moosh will figure out current version of Moodle and will use/run appropriate version of a command (e.g. course-backup for 1.9 is totally different than course-backup for 2.X).

It’s intended for:

  1. Developers. Within seconds you can do things like:
  • create 100 test users, e.g. moosh user-create user_{1..5}, create a course with course-create and enrol your users into the course with course-enrol.
  • have moosh generate some code for you with generate-* and form-add commands, update version.php with current timestamp
  • clear caches
  • turn debug on/off
  • dump sql or login into mysql console without the need to look for your DB password
  • run ad-hoc SQL query or Moodle PHP code against current Moodle
  • download Moodle module or Moodle itself
  • run code checker
  • reinstall your module
  1. Moodle admins and power users:
  • backup 1000 of courses, scp them to another machine and restore in one super-combo
  • manage users/courses/categories/plugins/files
  • monitor & check your Moodle installation

How did you get into Moodle and Moodle development?

Years ago, in the dark ages when some people were comparing Open Source to cancer and Linux was just my hobby, I found a job offer from a company that was using Linux, MySQL, PHP and Open Source software. For me it basically meant doing things I now do in my free time (because I enjoy them) but also getting paid for it… impossible! Turned out it actually was possible and since then I have the best job in the world.

You recently joined the Plugins guardians team. What was your motivation to do so?

To support Moodle as a project and enjoy doing it at the same time (I like to read the code). I’m quite surprised by the number of new plugins being submitted to Moodle each week - well done Moodle community!

What software and IDE do you use when developing for Moodle and how does your typical screen look like?

Nothing very fancy really - Linux box (Ubuntu) with PhpStorm plus Firefox and terminal (terminator and zsh as shell). I also use zim for nearly everything else.

Tomek's desktop

What is your common plugin development workflow and how do you organise the code in terms of branching, tags etc?

With moosh it’s very simple - git, master branch for development, with tagged releases and debian branch for creating Debian/Ubuntu package.

Many Moodle plugin developers are looking for a business model that would, at least partially, cover the time spent on their plugin development and support. Can you give some recommendations based on personal experience?

I think this is a big issue in Open Source world and nobody has a perfect solution for it.

First, there is discussion wherever open source developers should be paid for their work at all (google for “Debian Dunc-Tank” disaster) or should that depend on volunteers. I strongly believe that yes, they should be paid. It would be beneficial for all us if we have motivated developers being able to work on useful plugin full or part time continuously. It’s always sad to see unmaintained plugins.

How to get there is a big question. As far as I know (second-hand) those ideas don’t usually work:

  • Selling gadgets (t-shirts, cups) - nobody is buying them.
  • Donations. If it doesn’t work for the projects that half of the Internet depends on, there is no way it will work for Moodle plugin, to quote arstechnica: OpenSSL typically receives about $2,000 in donations a year and has just one employee who works full time on the open source code.
  • Offering paid services related to the plugin. As far as I know this is not sustainable (so you still need full time job, so you don’t have free time for development…) What may work:
  • An interesting idea that may work is snowdrift - read more about the problem and possible solution on .
  • Crowdfunding done with support from Moodle - e.g. the one at but maybe Moodle HQ could facilitate it? Help with promotion and actually collect and distribute funds?
  • Finding a sponsor (or sponsors) that would provide X each month for just being listed as a sponsor of a plugin. I also like the way you can sponsor vim - check this out:

Do you have some particular plans for further development of the moosh?

Just had a look at my zim page - I have 85 open moosh todo items, 6 new commands in the queue and 23 open issues on github. Unfortunately I have very little free time, so I’m not expecting any major development there any time soon. The next thing I should really sort out are functional tests - many commands are already covered (see but there is much more work there. Since the tool is used on production systems, I’d like to make it as stable and reliable as possible.

Thanks a lot Tomek. And good luck with all your contributions!

Picture of David Mudrák
Last week plugins arrivals - 2015.04.07
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Total of 13 plugins were reviewed by the plugins approvals team, 4 of them were approved and published in the plugins directory.

Picture of David Mudrák
Last week plugins arrivals - 2015.03.30
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

There were 11 plugins reviewed, 6 new plugins landed at the Plugins directory runways.

  • VideoEasy by Justin Hunt is a text filter implementing an alternative way to embed HTML5 players into the Moodle courses. Instead of relying on particularly hard-coded way to embed the player, the filter is based on user-defined templates. The filter comes with pre-defined templates for multiple players.
  • Pass grade quiz access rule by Matt Clarkson is a quiz access rule subplugin. The implemented rule prevents students who have achieved a specified grade from re-attempting the quiz again.
  • Analytics graphs by Marcelo Schmitt is a block aiming to provide range of graphs and charts useful for the reporting and analysis of the students' activity in the course. The initial version comes with first three graphs implemented.
  • JW Player multimedia filter by Ruslan Kabalin and Tony Butler is yet another filter for embedding media, this time via the JW Player.
  • SMB Streamline: Tabbed Navigation by Nicolas Connault is a block usable in courses with the weeks or topics format, on sites with Bootstrap based theme. It adds a real tabbed navigation to the course - only one course section is displayed at a time without the need to reload whole page.
  • ipal by Bill Junkin is an activity module that allows to use in-class polling clickers with Moodle. Students can respond using any device with web browser and/or the free app available for Android and iOS mobile devices.

There are currently 16 more plugins in the approval queue. Thanks to all the maintainers for the patience with the review and approval process.

Picture of David Mudrák
Is your plugin vulnerable to CSRF?
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Cross-site request forgery (wikipedia, moodle docs) is one of the basic exploits of web applications, including Moodle. If you are not protecting your plugin code against it, you put all users of your plugin into a risk with potentially serious consequences.

Moodle has an in-built feature called session key (sesskey) designed to protect your code from this kind of attack. Read more about the sesskey in our security guidelines.

There is quite a simple way to see if your plugin checks for the valid sesskey. Put the following lines into your main config.php file (e.g. at the very top of it, right after the opening PHP tag):

if (true) {
    // Special debugging mode enabled - no DB change should be allowed now.

Now go and try to use your plugin. Does not matter if you are logged in as a student, or a teacher, or the admin. You should still be able to browse your plugin's UI. But you must not be able to do any modification - create, update or delete anything in the database or elsewhere. Attempting to do so must lead to error (exception) missingparam: "A required parameter (sesskey) was missing". If you are able to perform a change, then you are missing require_sesskey() or eventually (rarely) confirm_sesskey() function call in an appropriate place of your code.

There are bad guys out there, using this and much more sophisticated techniques to discover security holes in web applications, and abuse them. Don't be like them. If you find related bug in a plugin, it helps neither the world nor your reputation in the open source community if you publish it immediately. Please contact the maintainer of the plugin first, preferably via a private e-mail, let them know your findings and give them reasonable time to take action to patch and distribute update of their plugin.

Picture of David Mudrák
Last week plugins arrivals - 2015.03.16
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Plugins team reviewed 16 submitted plugins last week, 8 of them were approved and published in the plugins directory.

  • CopyCheck plagiarism plugin implements integration with a commercial service provided by Deiputs. For now, the Assignment module is supported, both for file submissions and online text.
  • Joomdle Bootstrap is a responsive theme designed to make us of the Joomdle framework.
  • Elightenment is an enrolment plugin that lets you create e-shop like experience of the course enrolment. Students simply purchase the courses right inside your Moodle side. Relies on subscription based service.
  • Socialwall course format together with three additional support plugins is built on the students' experience with popular social network portals. It nicely integrates common posts timeline and comments with Moodle activity modules. It extends the concept of the standard Social course format and brings significant amount of new features and UI elements. And yes, it has the "I like it" button smile
  • Mathslate for Atto is an alternative equation editor for Atto. It uses MathJax to actually render the mathematical expressions. If Mathslate was the only reason why you did not switch from the TinyMCE yet, you should try it.

Big thanks to the maintainers for sharing all these nice plugins with the community. Also big thanks to all Plugins guardians who helped with the approval reviews of them.

Picture of David Mudrák
Tag at Github and release new plugin versions easily
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

As was initially announced at the October 2014 developer meeting, we were working on the Plugins directory improvements that would allow plugin maintainers to easily release new plugin versions based on Git tags. I am happy to announce some progress on this feature.

The Plugins directory now integrates with Github, the most popular hosting site for Moodle plugins code. When adding a new version of a plugin, the list of available tags are fetched from the Github and presented in a drop-down menu.

Screenshot of the new widget to upload tagged version of the plugin

Selecting the tag and pressing the "Release" button does two things:

  • The ZIP of the tagged version is loaded into the filepicker so that you do not need to upload it manually.
  • The fields VCS tag, Changelog URL and Alternate download URL are automatically pre-populated with a reasonable value.

To be able to use this new feature, you just have to make sure that the Source control URL field of your plugin record points to the Github repository of the plugin. And of course, you have to tag your code in advance. You can read more on Git tags in their documentation.

Together with this improvement, we also slightly changed another feature. As you probably know, the contents of the README file is used as the default value of the Release notes for the new version. From now on, if there is a file called CHANGES in the root of your repository, it will be used instead of the README file as the source for the release notes. Extensions .md, .txt, .htm and .html are supported, too (with Markdown being recommended as it proved to lead to well formatted text in both web and text terminal interface).

I hope you will enjoy these small yet nice improvements.

Picture of David Mudrák
Who are Moodle plugins developers?
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

In February this year, we ran a survey among Moodle developers who had submitted into the Plugins directory in 2014. The survey primarily focused on the initial review and approval process, but we also wanted to learn more about our community of plugins developers. Particularly, we asked them

  • what is their primary profession / occupation;
  • whether the plugin was developed in their free time or as a part of their job; and
  • whether they received some financial reward for developing the plugin.

Answers were received from 50 respondents out of 165 users asked to fill it. The results of these three questions are displayed in following charts.

Chart: What is your major profession / occupation?

Chart: Was the plugin development part of your work duties?

Chart: Did you receive financial reward for developing the plugin?

  • Most respondents (roughly 75 %) are professional software developers who write plugins as a part of their job.
  • Almost half of the respondents made the plugin for free without receiving financial reward. More than a half were paid or at least partially compensated for developing the plugin.

The second part of the survey provided very useful and positive feedback on the review and approval process for us. I will publish some results from it after the collected data are analysed.

Picture of David Mudrák
Last week plugins arrivals - 2015.03.02
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Plugins team reviewed 12 submitted plugins last week, 9 of them were approved and published in the plugins directory.

  • My Feedback is a report that allows students to see an overview of all their grades and feedback for assessment activities such as Assignments, Turnitin Assignments (v1 & v2), Workshops and Quizzes.
  • UNI Login allows users to log in to Moodle using the Danish UNI•Login service.
  • Etherpad Lite is yet another activity module that integrates Etherpad with Moodle.
  • Three new repository plugins - Flickr public (Xpert), Upload and attribute a file (Xpert) and URL downloader (Xpert) - implement a nice addition to their standard counterparts when embedding an image into Moodle. They automatically attach the license information and attribute the image to the copyright holder. Very useful!
  • Webcam Snapshot allows users to easily make a picture of themselves via the device's camera and use it as their profile picture. Requires Flash. Say selfie!
  • Toggle preview is another very useful Atto plugin that does what its name says. It lets you preview the edited text to see how it will look like after all filters and other formatting is applied. Nice!
  • Heartbeat is an admin tool designed to help with your site monitoring, especially in the ELB cluster environment. Also provides a configurable Nagios compliant health checker of scheduled tasks execution.

I am proud to say the initial review times are getting better and better, with the current median 3 days.

Big thanks to Dan Marsden (Catalyst IT), one of our plugin guardians for the help with peer-reviews last week.

Picture of David Mudrák
Featured plugin: PoodLL Anywhere (Atto)
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Do one thing and do it well is a software design principle I particularly like. It makes me happy to see a robust functionality split into separate modules that can interact and be used creatively in many ways. Today's featured plugin PoodLL Anywhere by Justin Hunt is an example of such software....

Read the rest of this topic
(1770 words)
Picture of David Mudrák
RFC: Should we stop supporting old Moodle versions in the Plugins directory at some point?
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators
I would like to ask the community of Moodle plugin developers to provide their opinion on the issue MDL-47579. In order to keep all comments in one place, please reply in the tracker and not in this forum. Thanks.
Picture of David Mudrák
Plugins directory code update
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Last week, the Plugins directory site was updated with some minor improvements. Here comes a short overview of changes.

  • When registering a new plugin, or uploading a new version of an existing plugin, users are now asked to explicitly declare they have checked the plugin contribution checklist. We believe this won't be simply ignored as "yet another must-agree-or-nothing" widget. In the checklist, we try to summarize common issues often seen in new plugins. Some of these issues are harder to get right once the plugin is published and we may send the plugin back to the maintainer because of them. By checking your code before submitting it, you help the plugin reviewers to not waste their time by repeating same comments over and over again. Thanks for understanding.

  • Validation rule for the $plugin->requires declaration was fixed (see MDLSITE-3753 for details).

  • The Supported Moodle versions is now required field. This field is essential to make the available updates notification, automatic updates deployment and on-click plugin installation work. Shortly, it plays important role when determining the most recent plugin version that should be used at the given Moodle version site. The importance of the field was not obvious in the previous UI.

  • Plugin and plugin version pages and editing forms were slightly reorganised to provide a bit more friendly and intuitive interface (among others, the plugin description and the version release notes are now displayed at more prominent place).

  • Plugin main pages now have nicer URL.

  • The option 'Rename root directory' is now enabled by default when uploading a new ZIP.

  • The validator makes use of $plugin->component declaration in the version.php file when auto-detecting the type of the uploaded plugin. Warning is displayed when this declaration is not present as it will be required for Moodle 3.0 (MDL-48494).

  • We are trying to re-organise the current "Other plugins" category to reflect various reasons the plugin may end up there.

As usually, the backlog of things to fix and improve is much longer than the one above. Particularly, I would like to get to overall review and clean-up of the plugins related Moodle documentation soon, to make it up-to-date and easier to navigate.

Finally, thanks all the contributors for your awesome work on various Moodle plugins. It's always pleasure to see innovative, useful and well written plugins that extend the Moodle standard functionality. Also, big thanks to our Plugin guardians for providing peer-reviews on submitted plugins on community self-help basis.

Picture of David Mudrák
What 2014 gave us in Moodle plugins world
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

The 2014 was a good year in Moodle plugins world. Let me pick some milestones that were reached in the last year.

  • 239 Moodle plugins Total of 239 new plugins were approved and added to the Plugins directory. Big thanks to all the developers for continuous maintenance of their plugins. Please feel encouraged to join the community and contribute too! See the plugins documentation and register your new plugin or help by taking on any of these plugins seeking new maintainer.

  • Moodle plugins - Peer reviewed The fellowship of Moodle plugin peer-reviewers was formed. These "Plugin guardians" help a lot with providing initial feedback on submitted plugins during the approval process. Many thanks to Tomasz Muras, Rex Lorenzo, Carl LeBlond and Luke Carrier for the peer-reviews and feedback provided last year. Really appreciated. Please do not hesitate to do a good thing in the next year - offer your time and join these merry men group!

  • We started to highlight interesting plugins and blog about them and their authors. Please check the Featured plugins list for those that received the award in the last year.

  • Old version of Plugins directory look Together with other community portals maintained by Moodle HQ, the Plugins directory site got a new look. I am aware of several areas in the UI and the functionality that I hope will be yet fixed and improved in the next year. All suggestions and bug reports welcome (as usually).

Have a good year everyone. I am looking forward to all your plugins, bug reports, useful forum posts, translation contributions and other forms of participation on this Moodle open source project.

Picture of David Mudrák
Featured plugin: Dataform
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

I personally like certain kind of Moodle plugins. Those with a simple idea behind yet with wide range of usage scenarios and pedagogical situations they effectively support. Such plugins typically do not enforce the teacher to use them in "the only right" way. Instead, they give the teacher ...

Read the rest of this topic
(1958 words)
Picture of David Mudrák
Marking favourite plugins in the plugins directory
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Feedback from the users community is very important for open-source developers. And positive feedback is a great motivation for further work. In the Moodle Plugins directory, we want to provide multiple channels how users can "pay back" to maintainers for their work.

Today, a new simple feature was added to the plugins directory. It allows users to mark plugins as their favourite ones. By clicking the "Add to my favourites" link at the plugin's main page, the plugin is put into the user's personal list of favourite plugins. The total number of users who have marked that plugin as favourite is displayed.

In the future, the full list of users can be displayed, too. Together with the information on what other plugins those fans like. It could even evolve into automatically generated suggestions based on the following idea: "If Alice and Bob both like and use plugins X, Y and Z, and Alice also likes and uses the plugin W, then Bob might be interested in the plugin W too."

You are welcome to help us to support the Moodle plugin authors. Let them know you appreciate their work. Mark the plugins you like and/or use as your favourite now.

Picture of David Mudrák
Featured plugin October 2014: Realtime Quiz
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

There is one thing I love on Moodle. It is the bottom-up way it was designed and implemented to meet teachers' needs. For teachers, by teachers. There are many systems in educational technology sphere that simply take existing functionality and push it (with more or less force) into the school ...

Read the rest of this topic
(1687 words)
Picture of David Mudrák
Featured plugin September 2014: Merge user accounts
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Duplicate user accounts is a nightmare for every good sysadmin. Especially if each of the accounts has been actually used for a while and is associated with recorded traces here and there (such as submitted assignments, attempted quizzes, published forum posts etc). This month, we are ...

Read the rest of this topic
(3187 words)
Picture of David Mudrák
Featured plugin August 2014: Archaius
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

This month, we are aiming our torch on a theme. It's not the most popular one. It's not based on bootstrap framework. It has some known bugs and limitations to be fixed yet. And maybe it will not make you say wow first time you install it. Yet it has some unique features that are worth of ...

Read the rest of this topic
(3772 words)
Picture of David Mudrák
Featured plugin July 2014: HotPot
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Starting from this month, Moodle HQ plugins team is going to select one plugin from the Plugins directory every month to present it to the community. Today, we put the spotlight on the HotPot activity module. This post contains an interview with the maintainer and then short reviews of the plugin...

Read the rest of this topic
(2849 words)
Picture of David Mudrák
Some common issues in submitted plugins
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

In this post I would like to highlight some common issues I recently spotted while providing the initial acceptance review of plugins submitted into the Plugins directory.

Database access and MySQLisms

It seems that quite a lot of authors of contributed plugins use MySQL database only when they are developing and testing their plugin. Moodle provides solid data manipulation API to deal with tiny differences in the syntax of SQL queries for all supported database engines (MySQL, PostgreSQL, MS SQL and Oracle). To make the plugin cross-db compatible, it is necessary to avoid DB engine specific syntax.

  • Always use the $DB to access the database, avoid functions like mysql_query() to execute your query.
  • Aim to use the most specific $DB method to do the job. That is, use $DB->get_records() if you can instead of $DB->get_records_sql() if you don't really need to.
  • Do not use MySQL specific backtick quotes in the queries. It makes the query fail badly on other databases.
  • Keep in mind that when using aggregations via GROUP BY, the SELECT part of the statement must explicitly contain all the fields your are grouping by. MySQL allows you to avoid them, which I personally really hate as it goes against some fundamental aspects of RDBMS - such as being deterministic.
  • Do not use LIMIT in your queries. The $DB methods have explicit parameters for them.
  • Neither use $CFG->prefix in your queries nor use hard-coded prefix like mdl_user. Use the {tablename} syntax and let the $DB driver to replace it with the actual table name.
  • In order to prevent SQL injection, always use data placeholders in your queries (? or :named) to pass data from users into the queries.
  • Always use the XMLDB editor to perform the schema changes via db/upgrade.php.

Our experience says that having the code tested against MySQL and PostgreSQL is usually enough to make sure it's cross-db compatible.

Prevent the cross-site request forgery

I was quite surprised how often this happens. Using the sesskey() feature to prevent CSRF attacks is a basic security protection you should include in your code whenever you are performing an action. When using the forms API, session key is checked implicitly. In all other cases it's your duty to perform the check. See this page for more details.

Check capabilities

It is important to highlight that permission checks must be done at both places. Not only there where your code is deciding whether or not a certain action link should be displayed (has_capability() is typically used there). It is essential to also check it just before you actually perform the action (that's where you want to call require_capability()). Remember, your code is open source. If require_capability() is missing, users can easily bypass your "protection" by submitting the data directly.

Sanitize user's input

You should never need to access superglobals $_GET, $_POST and $_COOKIE directly. Moodle provides wrappers for getting HTTP parameters - such as optional_param() and required_param(). Make sure you pick the most specific PARAM type for each of the parameters.

Picture of David Mudrák
Course notifications
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Notifications has been quite a hot topic in Moodle development for some time now. It has its first class seat in the development roadmap and is repeatedly mentioned in various presentations on Moodle. Instead of a particular feature, I see it rather as a bigger concept behind the development of many other areas. We can find its evident traces in recent core work on new events API, for example.

The pedagogical ideas behind notifications are pretty obvious. It is believed that the learning process is more effective if there is short loop feedback provided. Simply said, it's generally better for the student to get feedback on submitted work as soon as possible, while their brain is still focused on the subject. Providing instant feedback on small steps facilitates learning. And it is something the technology can help with (especially with mobile internet today).

On this note, two plugins dealing with similar feature landed successfully in the plugins directory last week - the Resource notification by Guillaume Allègre and the Course module modification notification by Luke Carrier. They both are trying to help teachers with keeping the students informed about recent changes in the course.

Guillaume's plugin adds a new item to the drop-down action menu displayed next to course module in editing mode. Clicking the new "Notifications" link allows the teacher to send an e-mail to all students in the course. In the optional complementary message, the teacher can provide more details (such as why the activity/resource is highlighted). So it's fully up to the teacher to decide what modules should students be informed about, and when. As Moodle core does not yet allow plugins to insert their own items into the drop-down action menu, a small patch has to be applied to core course/lib.php file to make this plugin work. The current version supports sending the notification via e-mail only. It also has some aspects that were raised during the initial acceptance review - such as the way it obtains recipients of the message etc. Once those are fixed, this plugin might be an interesting alternative to the course News forum (with forced subscription) that many teachers use for this purpose now.

Luke's plugin approached in another way. It informs all enrolled users about every course module update automatically. The plugin uses the new events API and registers itself as an observer of the course_module_created and course_module_updated events (fired by the core). In order to prevent spamming students too often, notifications are not sent immediately. Instead, they are scheduled and sent in daily digest message via messaging API. So recipients have more control on how they want to receive the message (e.g. via e-mail, jabber or mobile). That makes it a good alternative to the Recent changes block available in Moodle. This plugin is a nice example of how standard Moodle APIs should be used in a clean way to implement the desired functionality.

While reviewing these two plugins, I realized they both would profit from hooks support if it was implemented. If plugins had a standard way to inject their own fields into the course module settings form, they could easily add, say, a checkbox indicating whether students should be notified about the current change in the settings (with an optional message a la Git commit message).

I found both these plugins pretty promising and having potential to evolve to really nifty utils. If you have a chance, give them a try - and let their authors know what you think.

Picture of David Mudrák
Formal plugin check results now reported to maintainers
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

It's not only the plugin code itself being checked during the plugin acceptance review. Before the plugin is approved to land in the Plugins directory, some boring formal aspects of its registration are checked as well. This includes things like meaningful description being provided, checking for source code repository URL or whether illustrative screenshots were attached to the plugin record. None of these aspects are really blocking the eventual plugin approval. If the maintainer explains clearly they can't provide such information, it's generally accepted. However, as pretty high standards have evolved for the items in our directory, having all the useful information filled in place can be considered as a sign of responsible attitude toward the ownership of the plugin.

To make these aspects of the review process more transparent and evident, a new feature has been implemented in the Plugins directory. New report called "Plugin check results" is now displayed to plugin maintainers together with the indication of the importance level and additional help on the issue. This new report can be seen as a complementary one to the existing Code validation report, that reports on issues checked and detected in the uploaded ZIP plugin package.

More information about the plugin initial review process can be found at

Picture of David Mudrák
Plugins adoption programme
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Let's admit it - having an additional plugin installed into your Moodle site is always a risk. One of the essential aspects (apart from the code quality itself) that potential plugin users have to consider is how well the plugin is being maintained. Does the maintainer release regular updates and bug fixes? Is the plugin updated every six months for the new Moodle major release? Is there a place to report bugs and feature requests? And when reported, are they reflected?

It's not that difficult to write a new Moodle plugin these days. Many students do that as a part of their school or thesis projects, for example. But can one rely on the author of plugin to provide sufficient (or at least some) support for it? To be a responsible maintainer of a plugin is much harder than to be an author of it. Many maintainers work on their plugins in their free time. And even if they are lucky enough to be paid for doing that, it's just time consuming (as everything). Unfortunately, I know this dark side of the truth personally. I am aware of all these feature requests for the Workshop, AMOS and other plugins I have written. And I know I will never be able to implement them all.

No matter how hard one tries to be a good maintainer of their code, the life seems to be driven by unpredictable algorithms. At certain moment, maintainers can realise they are not able to give enough love to their plugins any more. In the essay The Cathedral and the Bazaar, Eric Steven Raymond says "When you lose interest in a program, your last duty to it is to hand it off to a competent successor." And that is what Moodle plugins adoption programme is about. And by the way, Eric's essay is really excellent and if you mean it seriously with the open source development, you should read it.

So, the rules of the programme I am suggesting here are roughly like this:

  • It's not a shame to give up of your plugin maintenance. You know that unmaintained plugin is worse than no plugin. You don't want to harm Moodle reputation just because your old code broke someone's site.
  • If you decide to offer your plugin for adoption, let us know via a reply in this thread (preferred over a personal message or e-mail to make it all transparent). We will put your plugin into a special set in the Plugins directory so it is known and public that it happened.
  • Once there is a volunteer who would like to take over the maintenance, please again reply to this thread. Note that it will help if the candidate proves their skills (via a reference or a patch for existing issue etc). So we all know the plugin is passed over to good hands.
  • Finally, the successor is given the main maintainer role for the plugin with all the permissions (edit the plugin record, release new versions etc). The previous maintainer will be still listed as the original author in the directory. Note that the @author tag in the phpDocs block of a file should never be changed even after the whole file is rewritten eventually. It's GPL legal statement, not a credits line.

I believe this mechanism will allow to keep more plugins up-to-date and also give new developers a chance to join our growing community.

Picture of David Mudrák
Approaching improvements in the plugins directory
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Couple of improvements in the Plugins directory and associated procedures are just being planned and it's the right time to discuss them now.

It's evident we need to improve the approval procedures for the new plugins. The queue of submitted plugins awaiting for the initial review became pretty long (45 plugins right now) and it's current top priority for the plugins facilitators team to deal with it. We believe it would help if more validation checks are executed automatically. Reported issues can then be fixed by the plugins authors promptly. It's not rare that the acceptance review takes longer just because the newly registered plugin does not have the basic meta-information filled (description, documentation links, source code management URL etc). We currently work on some UI improvements so that maintainers are warned and asked to fix these formal aspects of the registration prior to actual human review of the plugin code.

There is a plan to implement these validators (that include checks for the coding style, strings files syntax required by AMOS, code plagiarism etc) so that they can be executed separately from the plugin registration. In other words, the plugin author should have a chance to execute all these checks even before they actually submit their plugin to the directory.

We would also like to give the developers community a chance to participate on plugins reviews and testing. In some sort of peer-assessment spirit. Peer-reviews are generally very good for learning and reflection (developers seem to spot mistakes in other's work more easily than in their own work). We all learn well by looking at other's work and comparing it with our own. And it would provide the authors with richer feedback if their plugin was checked by multiple peers.

Some sort of integration with crowd-funding and Moodle jobs offering databases would be nice to have. It might help the plugins authors to collect funding for their work.

We also plan improvements in the UI for maintainers of existing plugins. One of the first things I would like to see soon is a mechanism that allows to easily release a new version of the plugin after it has been tagged in the external source code management system like Github. The directory already supports it partially, thanks to the cool repository plugin by Dan Poltawski (in the file picker, you can fetch the ZIP directly from Github without the need to download and upload it). We plan to extend this further so that releasing a new version in our directory is just a matter of a button click (or two).

Picture of David Mudrák
New "plugins liaison" position in Moodle HQ team established
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

After couple of weeks of planning and discussions, last week saw a new position in Moodle HQ team. The new "plugins liaison" role is supposed to link Moodle HQ with the world-wide community of plugins developers. The communication channel the position represents is bi-directional. In one way, the liaison keeps the dev community well supported and informed. In the other way, the liaison gathers feedback from the dev community and acts as an ombudsman advocating for the needs of the plugins developers community within Moodle HQ.

Main responsibilities of this job include:

  • Managing the plugins directory content (categories, configuration, permissions and plugins review and approval).
  • Plugins directory maintenance and further development.
  • Feeding and moderating a blog like forum at with interesting news on new plugins or updates, reviews, things of note, API changes, good development practises etc.
  • Gathering and acting on feedback on the overall plugins development procedure and the actual plugins directory UI and features.

I must admit I did not hesitate long and proudly accepted the challenge of holding this new position. Additional plugins are essential part of the whole ecosystem where Moodle as a software itself is (just) a platform - like a mobile OS is a platform for apps. Moodle as a project rely on top-quality, trustworthy and continuously maintained community plugins. And I'm happy to be now part of the plugins facilitators team who do their best to keep this ecosystem live.