Plugins traffic

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

Picture of Howard Miller
Finding orphaned plugins
Core developersDocumentation writersParticularly helpful MoodlersPlugin developers

Is there some way in the plugins database to quickly discover which plugins do not currently have a maintainer?

Picture of Anderson Hsu
moodle network bandwidth check

Dear all,

Would it be possible to install plugin which to check how many resource / connections / bandwidth does moodle server used as shown as below? Thanks a lot.

Picture of Juan Leyva
New way for supporting plugins in the Mobile app (draft spec)
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Since Moodle 3.1 is possible to support different types of Moodle plugins in the Mobile app via the Remote add-ons functionality.

Remote add-ons allow a developer to add complete support to their plugins in the Mobile app, but they have some disadvantages:

  • Remote add-ons are not easy to develop and test since they require to develop an AngularJS/Ionic module.

  • A zip file containing the plugin must be downloaded from the server.

  • Is not easy to maintain or upgrade them.

In order to allow plugin developers to make their plugins compatible with the app, the Mobile team has been thinking in a new way to extend the mobile app features following these premises:

  • It has to be easy to develop

  • It should work without developing Angular/Ionic code

  • It has to be easy to maintain

  • It has to be supported since Moodle 3.1 at least

  • Should support different types of Moodle plugins (modules, blocks, reports)

  • Should work in any type of device

  • Should not require client javascript to work

Here you have the complete specification:

Please, feel free to comment.

Note that this is a draft spec of a functionality we plan to implement in following months. It won't be fully documented until March 2018 and finally, it will be supported only in the new version of the app released in May 2018.

Developers will be able to start working on supporting their plugins in March 2018 (when everything is documented and supported in the alpha/development version of the app).

Picture of David Mudrák
Early bird 3.4
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

Good news! Moodle 3.4 just reached the beta maturity level. The core APIs can be seen as stable now, no new features will be added and only bugs will be fixed on the branch. The 3.4 release is scheduled to happen on Monday 13 November.

Same as before, Moodle plugins have now the opportunity to get a special award in the Plugins directory - Moodle 3.4 Early bird. This award will be given to plugins having a tested working 3.4 compatible version available on the release day.

This special medal was first awarded with Moodle 3.0 release and we are seeing increasing interest in it since then.

Please note it is not enough to simply you current versions as 3.4 compatible. Plugin maintainers are supposed to:

  • Test your plugins intensively against Moodle 3.4 beta (Behat and PHPUnit tests help a lot).
  • Fix all eventually raised warnings, notices, regressions and problems.
  • Release a new compatible version in the plugins directory, or mark the existing one as compatible.

We reserve the right to not grant (or even revoke) the award from a plugin if there is a suspicion that it was not tested well. There will be no exceptions for late submissions.

Once again, thanks to all the plugins maintainers for keeping their plugins up-to-date with latest Moodle versions!

Picture of Frédéric Massart
Consider sharing raw plugin usage data
Core developersParticularly helpful MoodlersPlugin developersTesters
I would like to bring to your attention an MDLSITE issue I just created.

Its purpose is to consider being more open about the data collected regarding our plugins' usage. Such data is invaluable to developers, it would definitely benefit them if more was available. I am not suggesting to add more widgets to the plugin's page at this stage, I know how hard it can be to display simple yet comprehensive information. Rather I am suggesting to give access to the raw data to the plugin's maintainers, or better, to everyone.

More on the tracker issue:
Picture of David Mudrák
Plugins stats improved and extended
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

I am happy to announce that there was a new updated version of the Plugins directory deployed last week. It brings improvements in displaying the stats related to published plugins.

  • The charts rendering has switched from the legacy YUI libraries to the new chart API based on the nice chart.js framework. This makes charts to look and behave better, especially on mobile devices and on screen resizing.
  • MDLSITE-4399 has been implemented - the plugin's stats page now shows not only the number of sites having the plugin installed, but also provides detailed data on those sites Moodle versions. This is expected to help the plugin maintainers to estimate the demand for supporting older Moodle version.
  • The plugin downloads charts now display data for longer period. The "Version downloads by month" shows data from the last 12 months. This chart has also been improved for plugins with many released versions. In the past, the chart become easily unusable due to too many data series to display. The new version either
    • displays data for all available versions if there are no more than 10 of them
    • or it displays data for all current versions only (that is the latest version for each supported moodle branch)

It is a good opportunity to remind that these stats are based on anonymous requests for available updates. We do not track the site identity, geo-location, IP or other sensitive data. Additionally, there are likely to be more sites with the plugin installed not counted in these stats.

Hope this helps.

Example of the new chart

Picture of Tia J
Orphaned plugin


Is it possible to adopt an orphaned plugin so as to bring it up to date with Moodle if the maintainer is no longer available? I have no way to reach the developer through Moodle, and the person whom he originally wrote the plugin for is unable to contact him. I reviewed the documentation at, but he's no longer even logging into Moodle. I'm just bringing it up to Moodle 3 coding guidelines and PHP 7 standards, there are very few people who use it according to the stats, but I'd like to help anyone else who does. What's my next step?

Thank you

Picture of martin anglada rossi
Making plugin in Node Js


I wonder if can i build a plugin with node Js for moodle?. 

We saw all plugins made for moodle were created with php. why did  they do that? what is the purpose?

Picture of David Mudrák
Preventing warning about expected login check
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

Some time ago, as a part of MDLSITE-3688, Dan Poltawski implemented a new sniff into the Moodle code checker tool. It helps to prevent some security problems by checking that scripts trigger appropriate authentication mechanisms. In other words, most scripts should call something like require_login() or require_course_login() or admin_externalpage_setup() right after including the main config.php file (which boots up the whole Moodle framework). Note that here, the authentication also includes authenticating as a guest user, if the given context allows access for them.

If the script does not require user/guest authentication, there is a chance for a security bug in the code. So a warning like this is triggered:

(#xyz) Expected login check (require_login, require_course_login, admin_externalpage_setup) following config inclusion. None found.

Where the xyz shows the line number in the script where config.php is included and no login check follows.

As you can imagine, there are valid cases when the page should not require any authentication at all (although they are pretty rare). A typical example may be the login or signup page. To declare that the lack of the authentication is intended, you can ask the prechecker to ignore the line where the warning would otherwise be reported:

// No login check is expected here bacause ... (explain here why anonymous
// internet users should have access to this script).
// @codingStandardsIgnoreLine

// Do what you need to do.

Unfortunately, the PHP CodeSniffer does not yet provide a way to ignore just individual rules. So any other coding style violation on the given line would be ignored, too.

More details can be found at Ignoring Parts of a File section of the CodeSniffer wiki.

Let me remind that these statements should not be abused. In most cases, the checks are valid. Turning off the checker is not a way to deal with raised warnings and errors. In this particular case, automatic login of the guest user is probably what you want when you think of anonymous access to a page. And that is what require_login() does by default.

Picture of Tony Butler
Aspire resource list plugin up for adoption
Core developersPlugin developers

Hi David,

I would like to submit the Aspire resource list plugin for adoption, as my institution is currently in the process of migrating away from the Talis Aspire reading lists product that it provides an integration for, which could make testing future updates somewhat tricky.

I've verified that the latest release works fine in Moodle 3.3 and updated its plugins directory entry accordingly, but that will probably be my last update.


Picture of Sandeep Gill
Adoption of the Melbourne theme
Plugin developers

Hi David,

I would like to take over the maintenance of Melbourne theme that is "seeking new maintainer".

Please let me know whats involved and/or further steps.



Picture of David Mudrák
Early bird 3.3
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

This is a gently reminder that it is still not late to test and update your plugins against upcoming Moodle 3.3. As a reward, plugins having a 3.3 compatible version available on the release day, will receive the special "Early bird 3.3" award in the plugins directory.

This special medal was first awarded in 3.0. It is nice to see the increasing numbers of plugins that have been getting it since then.

The release of Moodle 3.3 was postponed for a week and is scheduled to happen on Monday 15 May 2017. Still enough time to

  • Test your plugins intensively against Moodle 3.3 beta (Behat and PHPUnit tests help a lot).
  • Fix all eventually raised warnings, notices, regressions and problems.
  • Release a new compatible version in the plugins directory, or mark the existing one as compatible.

As always, we reserve the right to not grant (or even revoke) the award from a plugin if there is a suspicion that it was not tested well. There will be no exceptions for late submissions.

Big thanks to all the plugins maintainers for keeping their plugins up-to-date with new Moodle versions.

Picture of Martin Rossi
Create plugin with C sharp and integrate it into moodle

Good afternoon!

 I am working on a project and the purpose of this is to create an external plugin that allows to transmit classes by audio and image. 

 My idea is to do with C # but I'm not sure and then when you want to add to the platform there is some drawback to doing so. 

 Do you know what you know of someone who has done this ever advised me if it is viable or not?

Thank you!

Picture of Henning Bostelmann
Prechecker and PHPDoc
Core developersPlugin developers


Since the prechecker results for plugins are now public, and they show hundreds of errors for one of my plugins, I thought I'd look into these for the next release. (Hardly any of these errors would ever affect the user, so you might say the whole point is rather moot, but I thought I might want to do some cleanup nevertheless.)

About 70% of these errors relate to PHPDoc. Some of them are legitimate, but one main point seems to be that the checker complains about absent PHPDoc comments for overridden methods (when the intention is to retain the comment from the parent method).

Now I'm certainly not going to copy the PHPDoc from the superclass down to a dozen of subclasses just to please the automated checker - that would be possible but outright stupid. 

The developer docs say on this issue:

An exception is made for overridden methods which make no change to the meaning of the parent method and maintain the same arguments/return values. In this case you should omit the comment completely. Use of the @inheritdoc or @see tags is explicitly forbidden as a replacement for any complete docblock.

How do I make the the prechecker recognize this?

Picture of David Mudrák
Automatic code prechecks temporarily disabled
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

Please note that due to discovered issues with supporting the freshly released Moodle 3.3, we had to temporarily disable the automatic code prechecks for uploaded plugins. Once MDLSITE-5017 is fixed, the system will catch up and all plugin versions meanwhile submitted will be prechecked correctly. Thank you for understanding.

Me at the Moodle Moot NZ11
Turn around time for approving plugin reviews

Not totally sure this is the best place to post - but it's probably useful for others here too ... Question: how long does it take for plugin reviews to be 'approved' ?

I added a couple around 3 weeks ago, and they have "Waiting for publishing" next to them.

(I should probably know this, because I'm supposed to be a 'plugin guardian' - although 'lapsed' (embarrassed face!) ... I'm making an effort to review some of the newer plugins smile


Gareth J Barnard
Plugins, smurfs, style linting and checking.
Core developersParticularly helpful MoodlersPlugin developers

I like the new plugin checks that are performed as a part of the update / upload a plugin process on the plugins db as it drives quality.  However I have generated 'minimal' CSS files and would like a means of excluding them from the checks, i.e: with the CSS files of 'line 4'.  Is there a way please?  As it makes Essential look far worse than it actually is! smile

Picture of Jérôme Mouneyrac
Oauth2 authentication plugin seeking new maintainer
Core developersDocumentation writersPlugin developers

Hi David,

after five and half years since I created the plugin in 2011, I would like to hand over the Oauth2 authentication plugin maintenance to someone else.

This plugin comes with quite some responsibilities as it is installed on more than 2000 sites. When it breaks then the impacts are big for its users as it is an authentication plugin. It is also a plugin that depend a lot of third party APIs likely to change time to time. On the positive side it will give the maintainer a good exposure in the Moodle world.



C'est moi :-)
PHP version supported by a plugin
Documentation writersParticularly helpful MoodlersTestersTranslators


I've seen there's a place where a plugin can specify Moodle's compatible versions, and also PHP's supported versions. That's something useful smile

What would be more useful would be if more (most) plugins could specify which PHP versions are supported, because i think it's something important.

I'm planning to use PHP 7.0.x soon, and would like to know if plugins i use are compatible (or not).

Hope plugin developpers will take care of that in the (near) future.


Picture of Eoin Campbell
Information on total sites polled for monthly statistics?
Core developersParticularly helpful MoodlersPlugin developers

I noticed that there are some general patterns for the number of sites that a plugin is installed on. In most months, the number of sites installed increases for most plugins. In some months however, there is a drop of a few percent for a lot of plugins. This happened in February 2017, April 2016 and December 2014 for example.

The mostly likely explanation for this is that the total number of sites successfully polled dropped  in those months, which could be for any number of reasons. 

It would be nice to know the total site count each month, to get a better idea both of the sample size, and perhaps an idea of relative penetration rather than absolute numbers of particular plugins. The lists current Moodle sites, but this seems from the documentation to be updated weekly rather than monthly, so isn't the exact same sample set as the plugin statistics. It also doesn't show historical data any more (I think it used to).

Picture of Eoin Campbell
How to create a 'set' in Moodle Plugins directory?
Core developersParticularly helpful MoodlersPlugin developers

I've just noticed that some plugins belong to a set, e.g. Open University.

Is this something that plugin developers can create ourselves, and if so, how?

Picture of Jérôme Mouneyrac
More information about the plugin developer
Core developersDocumentation writersPlugin developers


when browsing for Moodle plugins on, sometimes there are information I would like to know. On the other side, as a plugin developer they're also information I would like to emphasis to plugin users. I thought I would mention these information here in case it gives some ideas for improving the repository (which has been well improved these last years).

* who is the main maintainer (at the moment, I am marked as "Lead maintainer" as soon as I create a plugin. It makes people think I am the main maintainer. Sometimes there are just no real maintainer available, or sometimes it is an organisation/company behind the plugin and so no physical person is currently allocated to maintain it.)

* who is the current main maintainer (original author, been maintaining the plugin for 3 years...) 

* was the author commissioned for the plugin

* is the main maintainer paid to fix the plugin (employee from university? employee from moodle partner?)

* is the plugin created by a freelancer

* is the plugin created by a university/school/teachers

* is the plugin created by a Moodle Partner

* is the plugin created by another company/organisation

* is the plugin own by a person (author, main maintainer) or by a company/orgnisation (and in this case, the main maintainer is just a person who, possibly, has less freedom on decision make about the plugin)

* what is the Moodle experience of the creator 

* what is the Moodle experience of the main maintainer

* does the main maintainer use the plugin in an important business product? (i.e. I would like to know how important is the plugin for the maintainer - the risk of issues is a lot lower if the main maintainer is using the plugin in prod, and even less likely if it is a critical business plugin)

* what Moodle version is using the maintainer (i.e. if I don't use the same version, the risk of not getting fixes is higher)

* does the maintainer engage himself to quickly fix bugs as they arise (I don't know who would say yes or no, but at least it would make the maintainer maintenance plan a bit more transparent. There is nothing wrong, in my opinion, for people saying they are not willing to, or just can not promise to fix bug as quickly as they would like. From Moodle partners who need to run business to the teacher developing the plugin on his own time, they are all right for different reasons to not be willing to fix issues on demand. The same if they do want to let people know they plan to be reactive and highly consider their plugin, they should be able to let people know that they engage themself personally even thought, should still mention that legally they should still be free to fix or not. It is just to understand the maintainer mindset toward his maintenance. I think it should be a mandatory field if it existed.)

* does the maintainer engage himself to really quickly fix security and blocker bugs

* is the maintainer (freelancer, teachers, company) accepting contract offer. If yes where does he/it lives so I can know what kind of rate to expect (I understand it can be find somewhere, but it is actually a info that should be brought to the plugin user attention, so with other data, the plugin user has a better picture of the plugin health and he can do a better risk analysis).

* how dangerous is a low score plugin health (for example an auth plugin which is critical and need to be seriously considered by the plugin user, versus something less critical)

* stats like how often the plugin is updated on github/bitbucket, or the frequency of version. 

I understand some of them can already be found (after clicking and comparing data around, Github and other pages) but it would be great if such info were clearly display into a "plugin health table" and also searchable.



Picture of Justin Hunt
The "Commercial Plugin" badge
Particularly helpful MoodlersPlugin developers

I would like to propose that we add some sort of icon or badge to be displayed in the plugin listing, that indicates it is not free. Or that it represents a paid service.  

Right now the overwhelming majority of plugins on the plugins database are utterly free. But there are others that represent paid services or require a subscription or license of some sort. My own Poodll plugins fall into the non free category. It would be up to the plugin developer/publisher to decide if their plugin is "commercial" or not.

The justification for this badge as I see it is:

i) it alerts the user that the plugin they are considering installing is not free or has paid components.

ii) it encourages the distribution of commercial plugins on the plugins database.

iii) it provides a possible revenue source for Moodle

To expand a little, its been mentioned previously that Moodle prefers to have a single plugins database (ie an official one and no unofficial ones). It makes sense then to cater to plugin vendors, to avoid alternate plugin marketplaces arising. My own experience has been that organisations want their key 3rd party plugins to be professionally supported and maintained.  And I think a healthy commercial plugin ecosystem will be good for Moodle and for its users, and should be encouraged. 

I also think that those making money from Moodle, or using as a distribution network for their product, should be contributing back to Moodle. So I think its reasonable to charge for the use of the "commercial" badge, or to require users of such to be Moodle Partners, and possibly to specify guidelines for which a plugin might be deemed "commercial."

(Just because its relevant, let me say that I think that the collection of money from users is not a role that should be carried out on That could skew things and would probably cause more overheads and hassles than revenue would compensate.)

Picture of Alexander Bias
Plugins adoption - filter_tabs is seeking a new maintainer
Core developersParticularly helpful MoodlersPlugin developers

Hi all,

I'd like to announce here that I am seeking a new maintainer for

Feel free to drop me a line if you want to continue the work.


Picture of Carlo Ditan
What type of plugin to be used for Gooru search
At first, I think integrating Gooru search with Moodle is a type of repository plugin. However, not all resources in Gooru are file types (e.g. image, doc files) since some of those are direct link to certain webpages. So instead of a file, a URL will be used.

Should I still make this plugin as a repository type? 

Picture of David Mudrák
Approval queue status displayed at the developer zone
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

Slowly recovering from all the rush around the Moodle 3.2 release, the plugins approval team has more resources now to start looking at submitted plugins again. If you have a plugin waiting in the approval queue, you might like the new feature added to the recently introduced "developer zone" page.

Screenshot of the developer zone

There is now a new block that displays:

  • Scheduled review type -- either "Initial" or "Re-approval". Initial means that we are going to look at your plugin for the first time. Re-approval means that the plugin had already been seen and marked as needing more work, and now is submitted for another round of review.
  • Waiting in the queue for -- shows the time your plugin has spent in the approval queue (in this review round)

To give you an information on what you can expect, the block also displays:

  • Total number of plugins waiting in the approval queue -- your plugin is one of them.
  • First one queuing for -- shows the time that has been spent in the approval queue by one of the currently queuing plugins, the one that has been waiting for longest time. This is a rough indicator of our current reviewing performance.

We generally review plugins in the first-in-first-out order. But we also prioritise initial reviews over re-approvals. And finally, reviewers have right to pick a plugin of their choice. So please don't be surprised if another plugin is reviewed sooner than your one, even if it was submitted after it.

Big thanks for all your contributions and mainly for your patience. Have a good weekend!

Picture of joseph malmsten
Another plugin with the same frankenstyle component name already exists
Core developersPlugin developers


Trying to publish a block for my company, Panopto, however it looks like a "block_panopto" already exists in the plugins database. 

When I try to search for block_panopto nothing comes up and no one in my company knows if we attempted to publish an earlier version of our block before. 

Is there any way to check if an unpublished block_panopto got submitted to moodle by my company, and if so to update it to this new version and resubmit for review?

I also have an Atto and TinyMCE set of plugins to add buttons to this, however I will worry about that after this is cleared up.

Joe Malmsten

Picture of David Mudrák
Plugins directory UI updates
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

Several improvements in the Plugins directory UI landed today, mostly affecting the plugins maintainers.

Screenshot of the new UI

  • The plugin fields Full description, Bug tracker URL, Source control URL and Screenshots are now finally marked and validated as required when editing the plugin record. These fields have been de facto required for some time now as we have insisted on them before approving the plugin (MDLSITE-4203).
  • We are introducing a new "Developer zone" page available for the plugin maintainers and the directory curators. This page will serve as a main dashboard providing access to various plugin maintenance related tasks - such as releasing a new version. For the start, the plugin editing and version releasing buttons were moved from the plugin header into it. In the future, more functionality will be added into this page.

Additionally, some little bugs were fixed too.

  • When displaying plugins matching the given keyword, the front page now orders results by sites as a secondary criterion.
  • Fixed incorrect categorisation of certain plugins as "other".
  • Some small improvements in overall layout and design of the UI (font-awesome icons and others).
Picture of David Mudrák
Try out the new Moodle plugins directory interface
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

We are pleased to reveal the first stage of Moodle’s longer term plugins directory project - a fresh new and user-friendly front page.

Screenshot of the new interface

With more and more plugins being submitted on a regular basis, Moodle community members and users have asked for particular features that would allow them to find and easily access the plugins that they really need.

And so here at Moodle HQ, we’ve listened and started on a project that aims to achieve two important outcomes:

  • improve the overall user interface and experience of the plugins directory
  • using more of the latest functionalities and technology of Moodle core versions to power the plugins directory

Moodle HQ worked with community members to do initial research into the look and feel of similar sites globally and analysing recommended patterns of UI development before building and testing a number of prototypes, to come up with this new user friendly interface.

With this new interface, you can expect the following from the Moodle plugins directory:

  • a modernised front page that lets you see the plugins card appear instantly as you change the filter form so there is no need to reload whole page
  • ability to search plugins based on ‘purpose’ and whether they can be used for communication, assessment, collaboration, administration or interface. This tagging will enable Moodle users to look and find the right plugin based on their requirements.
  • more advanced filtering options by using the ‘purpose’ search fields and also ‘plugin type’ drop-down menu to refine your search for the right plugin.
  • more accurate and relevant search results, displayed in a user-friendly way as a result of rewriting the whole plugins search engine.
  • and importantly, have more fun when browsing the plugins directory because it is more user friendly and accurate! A bit like surfing, as these new features in the plugins directory are being powered by the latest Moodle core functionalities.

Try it out today and we look forward to getting your feedback and thoughts in this forum!

Thank you!

Picture of David Monllaó
Plugins adoption
Core developersMoodle Course Creator Certificate holdersMoodle HQParticularly helpful MoodlersPlugin developersTesters


I'd like to find someone to adopt the plugins I currently maintain:

Picture of David Mudrák
Moodle 3.2, one, go!
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

Early bird award icon

It's been started! The tradition of Plugins Triathlons continues. Same as with 3.0 and 3.1, plugin maintainers now again have a chance to win the "Early bird" award for their plugin.

Moodle 3.2beta is available now in the main git repository. We have roughly 3 weeks to the next major version release. It is the best time now to update your plugins and make sure they will work well with the next Moodle version.

The award "Early bird 3.2" will be granted to plugins that have Moodle 3.2 compatible version submitted by the actual 3.2 release date. Please do not underestimate the actual testing and fixing all new bugs, warnings and notices. We reserve the right to not grant (or even revoke) the award from a plugin if there is a suspicion that it has not been tested well. There will be no exceptions for late submissions.

As usually, plugins authors have principally two ways how to achieve this:

  • If the testing reveals that an existing version just works as-is with the new Moodle version (this is not unusual especially with simple plugins and no changes in the underlying APIs), the maintainer can simply mark the current version as supporting Moodle 3.2.
  • If changes are required, or the maintainer just prefers to do so, a new plugin version can be released by uploading the new ZIP package to the plugins directory and marking Moodle 3.2 (and eventually others, too) as supported version.

As always, thanks and respect to you all who continually maintain your plugins and keep them up-to-date with new Moodle versions.

Picture of Valery Fremaux
Automate plugin base feeding
Particularly helpful MoodlersPlugin developers

I posted this tracker entry

to raise the possibility of some of us, big developers, to automate the update of our zips in official repository.

this is f.e my status :

Plugins : > 130 (

Having an upstream automated git process now to sync the github from the dev plant and get five clean branches for each, so having 650 branches to check.

Published in : around 30

Up to date in moodle : a little more than the half are in acceptable state, but less then 10 are up to date.

the reason : too many operations to do manually additionnaly to get all upstream development paths clean and checked

So the request is somewhat how could Moodle HQ give us a simple and nice API to push our zip releases into the plugin base from our gits or local repositories.... and then get plugin base more actual....

cheers !!

Picture of David Mudrák
Plugins contributions now part of user profiles at
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

Just to let you know, the user profile pages here at now display all approved plugins the user is maintainer of, or has contributed to. Such a feature was mentioned couple of times and was also reported as MDLSITE-4714 by Brendan Heywood (hey, you can now check his profile to see the plugins he maintains! smile).

This has been implemented using standard Moodle core features without the need to hack into the profile page. Check for the My profile API to see how any Moodle plugin can easily inject its content into the user profile page.

As always, big thanks to you all who keep contributing and maintaining plugins for Moodle.

Picture of Nicolas Dunand
Plugins adoption - regular expression questions
Core developersPlugin developers

Hi David,

I just noticed that the qtype_regexp (together with qbehaviour_regexpadaptivewithhelpnopenalty and qbehaviour_regexpadaptivewithhelp) plugin has been put up for adoption. In fact, development for this plugin has stopped for at least a couple years.

As we've been offering this for years to our teachers, we'll have to make sur it's fully Moodle 3.1-compliant by the end of July. I won't be able to do much more though. So I could temporarily adopt this plugin (is there even such a thing?), at least to provide a version officially supporting Moodle 3.1.

Is that envisageable?

(Edited by David Mudrák - original submission Thursday, 16 June 2016, 4:30 PM)

Picture of David Mudrák
Moodle 3.1 Plugins Triathlon
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

Moodle 3.1 beta has been released and I am happy to start another round of the popular Moodle Plugins Triathlon!

The basic rules are same as the last time - see the original post. To receive the Early bird award

  • your plugin must be tested for 3.1 compatibility,
  • all eventual regressions (including PHP notices) must be fixed,
  • the compatible version must be released in time of actual Moodle 3.1 release (expected to happen on May 23rd).

As a new rule (to make it even more funny and challenging!), your plugin must come with a valid PHPUnit and/or Behat test. The test coverage does not need to be 100% but dummy tests will not qualify.

Ready, steady, go!

Picture of AL Rachels
Plugins adoption - MooTyper, Hot Question and Skype modules
Core developersParticularly helpful MoodlersPlugin developersTesters

Hi David,

The maintainer for MooTYper , Jaka L., has offered it up for adoption in it's Description area, I've tried emailing him with an offer to start maintaining it but haven't heard anything back from him yet. I am currently working on a 2.8 version for it.

I have also tried to contact the maintainers of Skype and Hot Question, but with no luck. Tied email and messaging again today. I've be keeping current versions for Skype available for Moodlers on github for the past year or so. This week I have also gotten Hot Question updated to work with Moodle 2.7, 2.8, and 2.9, on github.

I would like to know if there is any way for me to proceed with these three plugins?

Picture of Gavin Henrick
2015 - favourite plugins
Moodle Course Creator Certificate holdersMoodle HQPlugin developersTesters

Favourite plugins and some more from 2015

2015 was a busy year, with many projects and much change. In the Moodle plugin ecosystem there has also been a lot of change with both new plugins and updated plugins.

But looking back across the available statistics, what are the favourite plugins for ...

Read the rest of this topic
(3484 words)
Picture of Andrew Kama
Plugins adoption - Autoenrol and UBEditor

Hello, I'm placing my plugins up for adoption:

Picture of David Mudrák
Plugins downloads stats updated
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

This is just to let you know that we have reviewed our plugins downloads tracking code and data. It was confirmed that there were some little bugs well hidden in the corner that caused suspiciously high and false downloads figures being reported for our plugins. These bugs were fixed at the end of September. Unfortunately we were not able to propagate the fix on existing aggregated data so we had to effectively reset the download counters. Starting from October 1st, 2015, the downloads figures should be significantly more reliable.

As a consequence, we have slightly modified the plugins directory UI. Where "total downloads" were reported previously, we now display sum of "recent downloads" from the last 90 days. So these stats now represent the current trends rather that overall downloads activity.

It turned out this can be seen as actual improvement as it allows new popular plugins to stay side by side with old and well established ones on the stats charts.

Additionally, the chart of plugin version downloads by month was improved to better visualise the history and trends of interest for particular plugin version. And, that chart's legend should now be a bit more compact for plugins with many versions available.

Hope you enjoy these news stats and thanks for understanding.

Picture of David Mudrák
Adding Travis CI support into your plugin
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators
Build passing icon generated by travis

If you have seen our latest community development meeting you may remember Andrew Nicols talking about Travis CI integration with Moodle. I really liked the idea as I saw its great potential for Moodle plugins development.

Let us say you are maintaining a plugin, ideally with some unit tests and behat tests attached. Apart from those, there are other things that can be automatically checked too - such as following the Moodle coding style. Travis allows you to continuously run all tests and checks in sandbox environments, with various PHP versions, Moodle versions, databases etc. For open source projects, using Travis is free. For projects hosted on Github, the overall setup is incredibly simple. So it seems to be a perfect option for most Moodle plugins. Finally, using Travis CI for Moodle plugins development is not a new kid on the block - there are traces back to discussions from 2012.

Technically, adding Travis support to your Moodle plugin is as simple as adding a configuration file .travis.yml into the root directory of your plugin and allowing Travis builds to be triggered on certain events, such as pushing commits to the plugin's repository at Github. This configuration file contains all the information needed to set up and execute all wanted tests and checks. Somehow, you must describe what PHP version, what database type (such as MySQL or PostgreSQL) and what Moodle version (branch) you want to use as the testing environment and what tests should be executed. There are good tutorials on all these steps.

Luckily, no need to re-invent the wheel. There is a great tool developed by Mark Nielsen called moodle-plugin-ci that does all the magic for you. The tool provides a template of the travis configuration file - perfectly documented - as well as excellent usage information.

I successfully used Mark's tool to add Travis CI support into my Poster module easily. In fact, I was able to do that just in couple of minutes while my kids were cleaning their teeth before going to bed! I just made a trivial modification of the default template so that my plugin was tested against all 8 combinations of MySQL / PostgreSQL and Moodle 2.7 / 2.8 / 2.9 / 3.0. I am sure there is more elegant way to define such matrix in the YML file - but hey, how long do you brush your teeth for?

When I came back to the home office after having read the next chapter of The Magic Faraway Tree, I was just thrilled. It did not take long to travis to run all the builds and I could just enjoy browsing the detailed build logs.

Overview of build jobs at travis

I'll be honest with you. This is awesome. I am big fan of test driven development and I've been dreaming about this "build passing" icon for my Moodle plugins for ages. And I am really happy that I can now start adding Travis CI support for my other software projects. Big thanks to Mark for his great contribution!

Continuous integration is a vital practice in Moodle development. Having it adopted for plugins development is a good sign of the developers' responsibility and their focus on the code quality. Indeed, all these automated builds are only as good as the actual tests executed behind the scene. But still. This is just awesome smile

Mary Cooch
Featured plugin: Collapsed Topics format
Documentation writersMoodle Course Creator Certificate holdersMoodle HQParticularly helpful MoodlersTestersTranslators
We are happy to present another featured plugin, the Collapsed Topics format, maintained by Gareth Barnard. This plugin is a 'must-have' for many Moodlers because it solves the 'Scroll of death' issue when courses have large numbers of sections and activities. 

Collapsed topics was in the Top Ten Downloads last year. At the time of this post, it is being used on over 3370 sites. I asked Gareth in an interview about his background, his plans for the plugin and any recommendations he could give to other plugin developers. Here’s what he had to say:

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

I am a software engineer and educator, with a Masters in Computing, a teaching qualification in Secondary Education (ICT) and am a member of the British Computer Society. I started my career as a software engineer, went into education and have now returned to software engineering.

I write software because I get great satisfaction from doing so. Before PHP and modern web technologies, I have coded in C++, Java, ADA, C, Modula-2, Pascal, COBOL and Basic.

I enjoy walking, cycling, archery, landscape photography and filming steam engines/railways.

Gareth Bardard Plugin developer

Can you briefly describe the Collapsed Topics plugin and its main features? Who is it primarily intended for?

Collapsed Topics has the ability to:

  • 'Toggle' sections open and closed. 
  • Remember the state of each toggle on a per course per user basis.
  •  Display the sections as weeks, topics, days, current week first or current topic first. 
  • Organise the sections into columns.

It is aimed at educators who have medium to large courses where the content can be broken down into self-contained sections.

How did you get into Moodle and Moodle development?

Whilst teaching ICT, the UK government brought in a requirement that all secondary schools should have an 'eLearning Co-ordinator' to manage online learning within their institution. I was appointed, and instructed to look at various LMS solutions by my boss. I looked at one solution and then Moodle. I discovered that I could do with Moodle in five minutes something that took thirty minutes with the other solution. We were already running our own servers so went for Moodle.

My development work started with Collapsed Topics. I was teaching an ICT examination course that had many modules. At any one time a student would only be working on one module and thus did not need to know about the others. I read an article in .Net Magazine Issue 186, entitled Collapsed Tables by Craig Grannell; this seemed to be a good way of hiding the topics. So I contacted him and received permission to use the work and started to create Collapsed Topics.

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

I do most of my Moodle development using browser development tools, Notepad++, MySQL administrator, Node.js command prompt, TortoiseGit and the Git bash, although very recently I have been looking at the Netbeans IDE (as I have used it in the past for Java development). I use both a WAMP and a LAMP stack with the latter being a virtual Ubuntu machine. I also have a Raspberry Pi operating as a Git server as well as publishing on GitHub.

I hate doing anything twice, so regularly backup all my code to GitHub, the Pi and four other hard drives and a memory stick. This does not include when the zip files are published in the plugins database. Ok, not quite software, but I consider that backup and configuration management are essential things for any developer.

Another 'DE' I use is pen and paper; this helps me to sketch out ideas and keep track of things.

Gareth Barnard's desktop

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

I stick to having a 'Git' branch for each version of Moodle that the plugin supports (even if there are no code changes between the versions) which keeps things contained and clear. The current one supported is the 'master' branch. Previously this was not the case with 'master' only being used for the next version of Moodle; however over time, this proved to be more administration, thus evolving to better practices as new information comes to light.

As there is only me for the most part working on the code, I develop within the branches. Occasionally if I want to try out an idea I create a separate development branch. All releases are tagged and marked as 'beta' / 'pre-release' or 'stable'. Anything in between is considered development and subject to change.

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

Very good question!

With Collapsed Topics I developed it because I wanted to. It solved a problem for me at the time in a work situation and even more gave me satisfaction that it benefited my students. Developing the format has also improved my PHP skills which were none at the start. I continue with the format so that I can maintain my skills and learn new ones. Over time the API for course formats has changed and this has lead me in different directions that I did not expect.

Developing any plugin will give you experience and help to develop your skills. When you publish your work you will then gain further experience technically and by supporting users. This facilitates the building of a reputation. That reputation will help you stand out and attract clients who come to you asking for bespoke modifications and new work based upon what you have done.

Do you have any particular plans for further development of the Collapsed Topics plugin?

I have a firm belief at the moment that Collapsed Topics has all the functionality it needs to do the job wanted of it. How long is a piece of string? As long as it needs to be to do the job. Collapsed Topics is the correct length.

The user interface is just right in terms of complexity. Any more complexity would lead to confusion. I do not want this to happen, a tool should be almost self explanatory and intuitive in its day to day use. However, I will continue to improve the underlying functional code in order to keep up with technical developments. Following recent feedback from Michael de Raadt, there might be some minor cosmetic changes to improve the overall look and feel.  The main plan is ensuring it works on each upcoming version.

Thanks Gareth, and thanks again for all your contributions.

Picture of David Mudrák
Moodle Plugins Triathlon
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

Now with Moodle 3.0 beta available it is perfect time to start updating your plugins for this new major version. Moodle 3.0 is scheduled to be released on November 9, 2015 so this gives us roughly two weeks of time to make necessary updates.

To make the updating process more entertaining and agile for you and to promote your plugin, please accept this challenge and join the Moodle Plugins Triathlon! No worries if you are not into swimming, cycling or running. This is more about testing, fixing and releasing your plugins code to make it ready for Moodle 3.0 (shortly tripliproof it wink).

The idea is simple. Let us have this mini-competition for you - the maintainers of plugins available in the Moodle plugins directory. To join, you are supposed to:

  • Test your plugin carefully with the latest Moodle 3.0 code, with full developer debugging enabled. If you have unit tests and/or behat tests available in your plugins, they will help you a lot.
  • Fix all the eventual regressions caused by 3.0. If needed, release a new plugin version with the fixes.
  • Mark at least one fully tested version of your plugin as supporting Moodle 3.0 in time before the actual Moodle 3.0 release.

All plugins that will have these checks done, will receive a special award in the plugins directory (something like Early 3.0 bird or so) as a good sign of being actively maintained.

To avoid cheating, we reserve the right for us to not grant (or even to revoke) the award if it is detected that the support for Moodle 3.0 was declared without actual testing/checking and fixing obvious issues.

Let the Plugins Triathlon start. Go go go!

Picture of David Mudrák
Heads up: Suggestions to raise requirements on plugins in the plugins directory
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators
I am suggesting some changes in the validation mechanisms for plugins submitted into the moodle plugins directory. Please pay attention to MDLSITE-4203 and provide your feedback there. Thanks in advance.
Picture of Danny Wahl
Plugins adoption - Melbourne, Zebra, Codepen
Core developersPlugin developers

Hello, I'm placing my plugins up for adoption:

Congratulations and thanks Bas for volunteering to take on Elegance- it couldn't go to a better dev!

Picture of Helen Foster
New plugin developers group on
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersTestersTranslators

Plugins developer group iconThanks to everyone who has shared their code with the Moodle community by adding it to the Moodle plugins directory. In recognition, we have set up a Plugin developers group, with an icon which is displayed on forum posts of group members. smile

Picture of Rogier van Dongen
Plugin adoption - Mass enrol

Hello David,

As a starter, I'll take the mass enrol plugin

Could be a little while before I can seriously release a new version, as I'm stuck with a case of bursitis at the moment.

No idea what any other requirements are, but just take a look on my profile for additions to the Moodle community



C'est moi :-)
Plugins adoption - Mass enrolments
Documentation writersParticularly helpful MoodlersTestersTranslators

Hi David,

I think you can add Mass enrolments plugin for adoption, because Patrick Pollet died in january sad


Picture of Helen Foster
Featured plugin: Attendance module
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersTestersTranslators

This month's featured plugin, the Attendance module, maintained by Dan Marsden, is used in more than 2200 sites around the world, has been localised into 22 languages, and is the 3rd most popular activity module in the Plugins directory.

The Attendance module has had a total of 26 contributors to the code to-date, including original developer Dmitry Pupinin, then Artem Andreev, and more recent contributors Davo Smith and Barry Oosthuizen - illustrating how plugin development and maintenance can be transferred and shared between developers.

I asked Dan, the current maintainer of the Attendance module, for an interview. Read on to find out how he felt about an early commit to Moodle core being destroyed and rewritten by Martin Dougiamas, Dan's advice on setting boundaries on support offered and plans for further development of the Attendance module.

Hi Dan. Can you tell us a little about yourself and your background?

Photo of Dan with his daughter Malea

Dan reads a book to his daughter Malea

I have an amazing wife with five great kids and work for the Moodle Partner Catalyst IT from a home office in Christchurch, New Zealand. I’ve been working as a software developer for around 16 years and on Moodle since 2004.

Recently I’ve been working on a project for a large multi-national on a packaged version of Moodle deployed to windows-based laptops which facilitates offline access to courses. Learners are able to download courses onto their locally installed Moodle and sync completion information to a centralised Moodle when an internet connection is available.

Can you briefly describe the Attendance module and its main features? Who is it primarily intended for?

The Attendance module allows teachers to maintain a record of attendance, replacing or supplementing a paper-based attendance register. It is primarily used in blended-learning environments where students are required to attend classes, lectures and tutorials, and allows the teacher to track and optionally provide a grade for student attendance. Sessions can be configured to allow students to record their own attendance, and a range of different reports are available.

The Attendance module was previously developed and maintained by Artem Andreev. How did it get under your wings?

Artem changed jobs and was unable to continue maintaining the plugin. We had a client using Attendance that was upgrading and provided funding for my time to update the code to work in Moodle 2.4. Artem handed the reins over and I took that opportunity to make a few other changes such as renaming the plugin from “attforblock” to “attendance”. I have continued supporting the plugin as a volunteer ever since.

You are a well-known Moodler, SCORM module maintainer, particularly helpful Moodler in the forums, experienced GSoC mentor and plugins guardian - that’s really impressive! How did this all start? How did you get into Moodle and Moodle development?

I was employed at Lincoln University as the 'Educational Developer' where I inherited responsibility for the in-house-developed Learning Management System based on individual Microsoft FrontPage websites with various add-on tools providing functionality like interactive quizzes and tutorial selection. It was innovative for the time but was quite challenging to support. Languages used within the system included ASP, Visual basic, Perl, Java, ActiveX and Actionscript. I quickly went looking for replacement possibilities and found Moodle. Lincoln University then joined the NZ Open Source VLE project; a collaboration between New Zealand tertiary providers looking at open source learning management systems (from which Moodle was chosen).

After submitting a range of patches that were accepted into Moodle, I was given direct commit access to the source code repository which encouraged me to contribute further. One of my first commits to Moodle core was completely destroyed and rewritten by Martin Dougiamas. This was a new experience for me; it inspired me to improve my skills and helped me recognise the benefits of working in a collaborative open-source environment.

The Moodle community continues to teach and sharpen my skills and I enjoy sharing the knowledge that I have gained to others within the community.

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

I’m a bit of a screen-junkie; my main development machine runs Xubuntu with 4 x 23” screens and PHPStorm is my IDE of choice. I have a couple of other machines that I use for testing, monitoring and playing music. I use Synergy for sharing the keyboard and mouse across the 3 machines which drive the 8 screens.

Dan's workspace

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

I prefer not to have too many branches to maintain; I usually branch when a version contains changes that will break with an older release. This means the master branch will contain the latest code for the current release and possibly earlier releases if they are still supported by this branch.

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?

The company I work for (Catalyst IT) has built a successful business providing open-source services. Our clients recognise the value in using open-source software and many pay for our time to contribute relevant development back to the community. Many of the features, improvements and bug fixes I develop are a result of direct funding from our clients.

It is important to set your boundaries well. I will often respond to private messages asking for support stating that free support is available within the community forums (with no guarantee on the level or time-frame) but direct one-on-one commercial level support and development is available at a cost. These private messages are only quick to answer if you have set expectations from the outset and placed a value on your time.

Do you have any plans for further development of the Attendance module?

I'd like to find time to restructure a lot of the code and improve the overall performance - a lot of data is passed around in-memory and the code hits the database a bit too much in some areas.

We’ve been lucky that several other organisations have made feature improvements to the plugin that I have been able to review and merge into the main code-base. Davo Smith from Synergy Learning just recently added some great features and Barry Oosthuizen from the University of Nottingham has been a great help.

Thanks a lot Dan. Best wishes with all your contributions to Moodle!

Picture of john saylor
Plugin adoption - Web services templates

i'll take the web services templates

i don't know what kind of vetting you may or may not need. i have been the primary developer for the moodle installation at
Picture of David Mudrák
Moodle Plugins directory update
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

This is a notification of some new features, fixes and improvements in the Moodle Plugins directory.

  • We are now using a new lightbox viewer for plugin screenshots. Most notably, the new version better handles big images so they should always fit your display size.Screenshot of the new reports in the administration block
  • The subsystem of community reviews has been cleaned-up, fixed and styled finally.
  • A new public report Reviewed plugins has been added, listing all the plugins with a community review available.
  • For better access to recently published plugins, there is now a new report Recently approved plugins.

Big thanks to all community members for keeping our approval team busy by submitting new plugins continuously. We are sorry for current delays in approval reviews, you shall hear from us soon!

Picture of David Mudrák
Last week plugins arrivals - 2015.06.23
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

Total of 5 plugins were reviewed since the last report (coincidently 3 of them dealing with some kind of online payment gateways integration), 2 new plugins were approved and published in the Plugins directory.

  • Slider block by Kamil Łuczak provides a simple slideshow functionality with fade or slide effect that can be added to the courses.
  • ClassicPay enrolment plugin by Sebsoft integrates with the PayNL payment gateway to provide paid access to the courses with the possibility of discount coupons.

There are 7 plugins waiting for approval right now. Stay tuned!

Picture of David Mudrák
Last week plugins arrivals - 2015.06.16
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

Total of 9 plugins were reviewed since the last report a week ago, 4 plugins were cleared for landing to the plugins directory. There is 1 plugin waiting in the approval queue right now.

  • The combo of Lucimoo EPUB export and import plugins extend the features of the standard Book module, allowing Moodle users to save the contents of the book into the EPUB format, and vice versa.
  • Two new question behaviour plugins, Deferred feedback (all or nothing) and Adaptive mode (all or nothing) are variants of their standard counterparts. They work with a variety of question types that normally produce partial credit for partially correct responses. With these behaviour plugins, the question must be answered fully correct in order to produce the full grade. Otherwise, the student gets zero score for the partially correct answer.
Picture of Germán Valero
Plugin adoption - AttControl
Documentation writersParticularly helpful MoodlersPlugin developersTestersTranslators


It seems the AttControl plugin at IS NO LONGER MAINTAINED BY ITS AUTHOR.

Can it be put in the list of plugins seeking new maintainer at  ?


Picture of David Mudrák
Last week plugins arrivals - 2015.06.09
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

There were total of 9 plugins reviewed last week, 5 of them made it to the approved state. There are 5 plugins waiting in the approval queue right now.

  • Featured courses block allows you keep a list of manually selected courses you want to highlight - typically at the site front page.
  • Course publish block makes it easy to share a link to the course via a particular Facebook page.
  • Reattempt checker is a quiz access rule that prevents students from reattempting the quiz once they receive a certain quiz grade.
  • EPUB book export adds possibility to export the Book module contents into the EPUB format.
  • Moderated RSS block extends the features of the standard RSS feed block so that every RSS item has to be explicitly approved before it is displayed in the block.

Special thanks to Hittesh Ahuja who recently joined the Plugins guardians team for the help with peer-reviews.

Picture of David Mudrák
Last week plugins arrivals - 2015.06.01
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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 Mark Johnson
Plugin adoption - Accessibility block
Core developersParticularly helpful MoodlersPlugin developers

I'd like to put the Accessibility block up for adoption.

For the past 12 months it's been maintained by another developer as I've not had the time nor inclination to do so, but he's no longer able to act as maintainer.  It's the most downloaded of the plugins that I've written, but also the most complex so requires some active effort to keep it updated.

Picture of David Mudrák
Moodle version 2.9 added into the Plugins directory
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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?
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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?
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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)
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
(1769 words)
Picture of David Mudrák
RFC: Should we stop supporting old Moodle versions in the Plugins directory at some point?
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators
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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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 Joseph Conradt
Plugin adoption - Moodlebook theme

Hi David,

Firstly, great idea for keeping plugins up to date! Secondly, can I 'adopt' the Moodlebook theme by Julian?



It's only an avatar...
Plugin adoption - Arialist theme
Core developersDocumentation writersParticularly helpful MoodlersPlugin developersTesters

Hi David,

Could you please enrol me as Maintainer of the Arialist theme? And if possible, all the other Moodle standard themes which were removed from Moodle, as I would like to upgrade them so that they work in RTL languages, and fix other CSS issues that they may still have.

I need to fix Arialist theme as there are two rogue arrows '⟨' and '⟩' being used that are creating havoc in quiz and other parts of Moodle 2.6.

Thanks and Happy New Year!




Picture of David Mudrák
What 2014 gave us in Moodle plugins world
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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 Jérôme Mouneyrac
Plugin adoption - Enrolment invitation
Core developersDocumentation writersPlugin developers


I would like to put the enrolment invitation on the list of "seeking for a new maintainer". It's a plugin for teachers to send manual invitations to enrol into your own course. 

It has been listed as a popular plugin (, so you will code on something that people already like. You will find many fixes and improvements over different places to start working on it: or in the plugin page comments. I think it's a small plugin, perfect to start coding with Moodle smile



Picture of David Mudrák
Featured plugin October 2014: Realtime Quiz
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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 Arindam Ghosh
Plugin adoption - Rocket theme
Plugin developersTesters

Hi All,

Let me introduce myself, I am Arindam from DualCube, a web development firm specializing in Moodle development for the last few years. We are very eager to participate in the Moodle community actively and we would like to start with the adoption of the Rocket theme( by Julian Ridden. Please let me know your thoughts about this.

We do have hands on experience customizing Moodle themes and have also built a few custom ones. I would request you guys to check one of them which we are planning to upload in, here's the link to our staging server:

Git link:

Looking forward to hear from you.

Thanks and Regards,


Team DualCube,

Skype: moodlecafe

Picture of David Mudrák
Featured plugin July 2014: HotPot
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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 Danny Wahl
Plugins adoption - Julian Ridden's contributions
Core developersPlugin developers


will there be a way to flag a plugin as abandoned, provide evidence, and request it to be added to the set?  For example any of Julian Ridden's contrib. plugins as he has stated in the forums that he has ceased working on them.

Picture of David Mudrák
Formal plugin check results now reported to maintainers
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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

Plugins adoption - Elegance and Essential theme

Hi David,

great initiative! If you need anymore help on adopting plugins let me know.

A couple items that spring to mind is all the work that Julian has published before.

Now he has left Moodle for Canvas, I think his work should be adopted, among primarily the Elegance and Essential theme.
If anyone in contact with him could ask if he is willing to do this, we could have his work updated for Moodle 2.7 pretty quickly.


(Edited by David Mudrák - original submission Monday, 19 May 2014, 9:37 AM)

Picture of David Mudrák
Plugins adoption programme
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

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.