Plugins traffic

That’s why we’re delighted that Dan Marsden  (developer at Catalyst IT NZ)  has agreed to share the load in his new role as Plugins curator. A long-time Moodler and active participant of the Plugins guardian program, Dan has been providing helpful feedback to plugins authors for a number of years as well as developing his own plugins. We even highlighted one of them, the Attendance module, in a Featured plugin post , back in 2015. (You’ll appreciate the benefits of the Attendance module if you have a Moodle for School site; it’s one of the MoodleCloud set of plugins.)

We’d like to thank Dan officially for accepting the role, and look forward seeing many more high quality community contributed plugins.

Hi! Just to clarify what has been shared in other places. Yes, we will have a flag (probably implemented as an award) in the plugins directory allowing to highlight that the plugin has the new privacy API implemented, which is relevant for GDPR compliance evaluation of the site.

My dreams did not yet come true so this feature was not implemented by the end of this week. But I am sure it will come soon. Thanks in advance for your patience.

p.s. Many thanks to all the new HQ's Plugins Guardians who started to provide approval reviews for submitted plugins just recently, as well as to those veterans who never stopped doing so. Much appreciated.

Hi,

Moodle HQ is organising a Moodle DevJam in Barcelona (25 and 26 of June).

Please, see the Moodle DevJam in Barcelona discussion for details.

See you in Barcelona, Juan

This is just a reminder that Moodle plugins have again the opportunity to receive a special award in the Plugins directory - Moodle 3.5 Early bird. This award will be given to plugins having a tested working 3.5 compatible version available on the release day. Moodle 3.5 is scheduled to be released on Monday, 14th May 2018.

Same as before, it is not enough to simply mark you current versions as 3.4 compatible. Plugin maintainers are supposed to:

• Test plugins intensively against Moodle 3.5 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.

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

With the forthcoming EU General Data Protection Regulation (GDPR) on the 25th May 2018 this got me thinking about my plugins and how they might be affected.  Especially after reading around the regulation where it indicates that the publisher of the site is responsible for what the code does.  I know that Moodle HQ will be adding plugins for the regulation.  But what about third party plugins?  Are you confident about them?  To this end and to get the ball rolling I've written a post on eLearningWorld about Collapsed Topics (my contributed course format) and GDPR.  So as not to cross post, you can reach the article via https://moodle.org/mod/forum/discuss.php?d=364186 (as I feel the post is both specific course format and general plugin related).

So, after reading it, what do you think?  Are you confident that the data your plugins store complies with the regulation?  Even though the regulation is an EU one, if you have users in the EU then you need to comply (my understanding).

I would like to adopt the Autogroup plugin, which is stuck at support for Moodle 2.8 only. I have tried to contact the original developer but haven't had any response. Is there any procedure in place for when a plugin is left in limbo, neither supported nor put up for adoption?

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

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.

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

https://docs.google.com/document/d/1N4eZlYXnPnEyB0Xf7Of7AF7qty-wXcQg9N1ok9txSEg/edit?usp=sharing

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).

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!

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.

Hi!

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 https://docs.moodle.org/dev/Plugins_adoption_programme, 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

Hi

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?

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
require(__DIR__.'/../../config.php');

// 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.

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.

Thanks,
Tony

Hi David,

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

https://moodle.org/plugins/theme_melbourne

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

Thanks

Sandeep

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.

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!

Hello

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:

How do I make the the prechecker recognize this?

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.

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

Stu

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: https://moodle.org/plugins/pluginversion.php?id=13587&smurf=html#css with the CSS files of 'line 4'.  Is there a way please?  As it makes Essential look far worse than it actually is!

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.

Cheers,

Jerome

Hi,

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

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.

Séverin

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 https://moodle.net/sites 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).

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?

Hi,

when browsing for Moodle plugins on Moodle.org, 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 Moodle.org 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, Moodle.org 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 Moodle.org, Github and other pages) but it would be great if such info were clearly display into a "plugin health table" and also searchable.

Cheers,

Jerome

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 Moodle.org 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 Moodle.org 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 Moodle.org. That could skew things and would probably cause more overheads and hassles than revenue would compensate.)

Hi all,

I'd like to announce here that I am seeking a new maintainer for https://moodle.org/plugins/filter_tabs.

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

Thanks,
Alex

Should I still make this plugin as a repository type? 

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.

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!

Hi,

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.

Thanks
Joe Malmsten

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

• 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).

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

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!

Hi,

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

• Journal module
• Moodle flavours
• Admin presets

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.

I posted this tracker entry

https://tracker.moodle.org/browse/MDLSITE-4781

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

this is f.e my status :

Plugins : > 130 (http://github.com/vfremaux)

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 moodle.org : 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 moodle.org plugin base more actual....

cheers !!

Just to let you know, the user profile pages here at moodle.org 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! ).

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.

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)

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!

Hi David,

The maintainer for MooTYper , Jaka L., has offered it up for adoption in it's Description area, https://moodle.org/plugins/mod_mootyper. 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?

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 each main type of plugins for Moodle in the plugin database?

These are the top level categories for plugins:

• Activities
• Availability conditions
• Blocks
• Themes
• Users
• Course Formats
• Filters
• Reports
• Gradebook
• General plugins (Local)
• Editors
• Cache
• Messaging outputs
• Repositories
• Portfolios
• Plagiarism
• Web service protocols
• Admin tools
• Calendars
• Other

So I am going to briefly look at the top few in most areas!

5 Favourite Activity plugins in Moodle

There are over 286 activity related plugins, so this will cover the top 5.

The top plugin comes out as HotPot - maintained by Gordon Bateson. This is a heavily used activity that provides teachers the option to run Hot Potatoes and TexToys quizzes via Moodle. The question types include simple crosswords, matching exercises, gap-fill and multi choice questions. 

Usage: Assessment, Content / Information transfer

Some activities have always been on the list of plugins that I recommend, and two of those are in the end of year top 4 for activities with 2nd and 3rd place respectively; Certificate and Questionnaire.

Certificate maintained by Mark Nelson, comes number 2 in the top 5. This enables teachers configure and issue a PDF certificate for students based on predefined conditions. This is why it is usually one of the first plugins that I recommend people install. There is another plugin called simple_certificate not to confuse the two, but both are good options!

Usage: Assessment, Content / Information transfer

Questionnaire is a very powerful survey tool, which has been around for ages and is maintained by Mike Churchward. Similar to the core Feedback activity, it enables teachers create a custom survey for students.  This comes in 3rd in the top 5. I have seen this heavily used in some institutions for their centralised student end of module feedback.

Usage: Assessment, Content / Information transfer, Interaction

Another plugin I usually recommend comes in number 4, BigBlueButtonBN maintained by Fred Dixon and Jesus Federico of Blindside Networks. This plugin enables the integration to Moodle of the open source Virtual Classroom BigBlueButton (which is also used in MoodleCloud). The open source BigBlueButton online classroom has a great feature set and can also work through LTI - so without the plugin.

If you are looking for a virtual classroom make sure you check this out ( to test out the you can register a MoodleCloud site which has a BigBlueButton 5 person room built into it as an activity option)

Usage: Assessment, Content / Information transfer, Interaction, Collaboration

Coming in 5th for activities is the Attendance activity - maintained by Dan Marsden, that allows teachers to maintain a record of the attendance of their students. It can be configured so that teachers or students record the attendance. This is one plugin that once you start using you will wonder why it wasn’t installed before.

Usage: Assessment, Interaction

3 favourite Availability conditions plugins in Moodle

There are only 5 plugins for availability conditions, however I’m going to cover the top 3.

The top availability condition is Restriction by course completion - maintained by Renaat Debleu. This makes it easy for the teacher to show or hide modules or sections only when a learner has completed a course. This is very handy if you want to chain courses together.

Usage: Assessment, Content / Information transfer, Interaction

Coming second, is the Level availability condition - maintained by Frédéric Massart. This is used with the Experience points Set for adding more gamification aspects to Moodle. I love this set and the extra zing it can add. Download it now

Usage: Assessment, Content / Information transfer, Interaction

The availability condition Moodle Mobile app - maintained by Juan Leyva, comes third and is a very powerful option. Where so many institutions are moving to a mobile first approach, this condition enables a teacher restrict access to an activity, resource or section depending on if they are accessing via the Moodle Mobile app. This way you can replace any desktop-only resources just for those on mobile.

Usage: Assessment, Content / Information transfer, Interaction, Collaboration

3 favourite Blocks in Moodle

Blocks are used for many different reasons but generally add content, or feature to the course or home page of Moodle. There are 276 block plugins, so this will cover the top 3.

The top favourite block in the Moodle plugins database is the Progress Bar block - maintained by Michael de Raadt. This displays a user-friendly colour-coded progress bar with units which also act as links for each configured resource or activity. It may be deployed within one course or on the dashboard for the students’ combined courses.

Usage: Content / Information transfer, Interaction

The second favourite block is the Configurable Reports block - maintained by Juan Leyva. This allows reports to be easily built for custom data analysis for use by either admins or teachers. Report types generated may include course, category, users, timelines and custom SQL. Reports can also be configured to be accessible by wider sets of users, ie students, if required.

Usage: Content / Information transfer

The third favourite block is the Level Up! block - maintained by Frédéric Massart. This provides a gamification tool for admins and teachers to engage their students or learners. Student actions are configured into points, graduated levels are awarded and notifications are both in the form of a fun (and customisable) displayed level icon and via messages.

Usage: Assessment, Content / Information transfer, Interaction

4 favourite Themes in Moodle

Themes are used to change the look and feel of your Moodle site, or course. Sometimes they also have extra functionality built in too. There are 124 theme plugins, so this will cover the top 4.

Top of the theme list is Essential - maintained by Gareth J Barnard. A good looking theme with a serious amount of options to customise the front page and interface. This has not yet been updated to 3.0 but hopefully will be soon. Good to get ideas from for your own custom theme.

In second place, Aardvark - maintained by Shaun Daubney, has a simple flat look. It provides a modern look for Moodle.  If you prefer simplicity but need more than more - this is a theme to go for!

Bootstrap - maintained by Bas Brands comes in third. This is a minimal style theme based off the Bootstrap CSS framework. It is also a responsive layout theme which caters for both desktop and mobile or tablet device viewing. This is a good theme to base your theme on.

In fourth, BCU theme - maintained by Mike Grant and Jez H, is a theme from the Birmingham City University. It is based on bootstrap and has a lot of options to customise the interface. The feature set is a collection of features seen in other themes with some new ones. This has not yet been updated to 3.0. Great for usage and inspiration.

3 favourite User plugins in Moodle

The user plugins cover tools used to manage users including Authentication, Enrolment and User profile fields.

Unsurprisingly, the Google / Facebook / Github / Linkedin / DropBox / Windows / VK / Battle.net authentication plugin - maintained by Jérôme Mouneyrac, comes out top in this section. When used this enables users to log in and create a Moodle account with their existing service. This uses the Oauth2 protocol. Not sure I would want to log in with my battle net login, but I can see how this can be very useful.

The OpenID Connect maintained by many including James McQuillan, provides the Single Sign On functionality but this time with systems that use OpenID such as Active Directory.  With so many organisations on microsoft systems this is one to evalutate.

Email-based self-registration with admin confirmation - maintained by Felipe Carasso, comes in third. This provides a simple email based registration but requires the admin to authorise the account before it is active. If you want open registration, but need that control too - it’s a good approach to take.

4 favourite Course Formats plugins in Moodle

Course Formats change the structure and layout of course pages. There are 25 of these in the database, so we will look at the top 4.

The top format is Collapsed Topics - maintained by Gareth J Barnard. It is a nice, easy to use format that condenses the sections in the course unless they are clicked to expand. It would be great to see this type of course format available in core or at least some of the aspect of it as settings for normal topics/weeks.

Usage: Content / Information transfer, Interaction

The second format Grid is also maintained by Gareth Barnard. This format provides a visual grid representing each section rather than a list and produces an overlay for the section when clicked. For those who want a more visual navigation, this delivers exactly that.

Usage: Content / Information transfer, Interaction

The Onetopic format - maintained by David Herney Bernal, comes in third. It shows each section one at a time - and maintains the list of sections as tabs above it. It provides a different take on the section by section view that Moodle core provides.

Usage: Assessment, Content / Information transfer, Interaction

The Flexible sections format - maintained by Marina Glancy, is fourth in this category and enables the course designer to nest course sections inside sections. This grouping is a very powerful feature that gives the course a more structured format than the typical linear one. I forsee this being used more and more.

Usage: Assessment, Content / Information transfer, Interaction

3  favourite Filters plugins in Moodle

Filter plugins process and change text before it appears to the user, for example, changing a youtube URL into an embedded youtube video. There are 56 filters, so we look at the top 3 here.

The top filter is PoodLL filter - maintained by Justin Hunt. This is part of the PoodLL set and enables the user to embed stopwatches and flashcards into HTML areas. I don’t use PoodLL myself but have played with it, so can’t give much feedback on this - but it looks good.

Usage: Assessment, Content / Information transfer, Interaction

The Jmol filter - maintained by Geoffrey Rowland, enables teachers embed interactive 3D chemical structures using Jmol/JSmol.  Not my area really, so cant say much on this!

Usage: Content / Information transfer

WIRIS math filter - maintained by WIRIS, comes third in the category. It works with the WIRIS math & science set to provide enhanced maths equations and questions in Moodle. WIRIS maths features are great and easy to use, gotta have a look at least.

Usage: Assessment, Content / Information transfer

4 favourite Report plugins in Moodle

Report plugins are tools for administrators, teachers and general users. There are 26 available, and here we look at the top 4.

A must have for SQL competent administrators is the top report - Ad-hoc database queries which is maintained by Tim Hunt and Mahmoud Kassaei. It allows admins to create arbitrary database queries to use in ad hoc reports.

Usage: Content / Information transfer

The Overview statistics report - maintained by David Mudrák comes second. This produces a number of very useful site and course report charts - including User preferred languages and Number of courses per size. Everyone will always want more reports, but this is a great small package.

Usage: Content / Information transfer

Course size - maintained by Dan Marsden and Peter Bulmer comes third and provides a neat report of approximate disk usage by Moodle courses. Space matters, and this can help identify courses that are ballooning.

Usage: Content / Information transfer

The fourth in the category, Events Graphic Report - maintained by Simey Lameze, enables the user to see what is happening in their Moodle site by using the rich information provided by the new event system and logging. Love this and hope to see more features in it!

Usage: Content / Information transfer

3 favourite Gradebook plugins in Moodle

The gradebook plugins enable the site admin to extend the gradebook by adding new reports, import/export features and new grading methods. There are 13 plugins in this category and we look at the top 3.

XLS with Groups and Dates - maintained by Carina Martinez, is the top downloaded of the category although this has not been updated in 4 versions of Moodle (2 years). A pity as quite useful

Checklist - maintained by Davo Smith, comes in second - and works as part of the Checklist set. It exports out the individual checkmarks from a single checklist activity. Checklist is one of those features that enables teachers and students take ownership of their progress and management.

Usage: Assessment, Content / Information transfer, interaction

At 3rd, the Multi Course Grader report - maintained by Barry Oosthuizen, provides a site-wide grader report pulling any number of grader reports into one page.

3 favourite General (local) plugins in Moodle

These plugins can impact many aspects of Moodle, and don’t fit into any specific category. They are called Local as that is where they get installed. There are 93 of these and we look at the top 3.

The top local plugin is the Moodle Mobile Additional features plugin - maintained by Juan Leyva and Daniel Palou. This plugin works with older version of Moodle to provide the extra features that the newer Moodle core has supporting Moodle Mobile. Each feature of the Moodle Mobile App requires some work on the Moodle site too, and this allows admins keep up to date with the extras without having to upgrade their whole Moodle site.

Usage: Assessment, Content / Information transfer, Interaction

Second on the list is Fullscreen Toggle button - maintained by The University of Nottingham and Barry Oosthuizen. It expands the content area hiding all the side blocks - and works with themes based on the Clean and Bootstrapbase themes. We did this type of feature on the MoodleMoot site nearly two years back as part of the theme, so it is great to see it as a plugin that any can use.

Moodle Welcome - maintained by Bas Brands, comes in third in this category. This sends a welcome message to new users and a notification to the moderator of new users. Very handy for engagement purposes.

Usage: Content / Information transfer

5 favourite Editor plugins in Moodle

These plugins are either alternatives to the existing editors, or enhancements to them. There are 49 such plugins and we look at the top 5 for the Atto editor.

WIRIS plugin for Atto - Maths - maintained by WIRIS, is the top editor addition for Atto. It adds the WIRIS equation editor options into Atto.

Usage: Assessment, Content / Information transfer

The second on the list for Atto is the More font colours - maintained by Nicolas Dunand, and it replaces the core font color plugin allowing the admin define which colours to be available. This is very handy to ensure the colours fit with corporate branding.

Usage: Content / Information transfer

Word import - maintained by Eoin Campbell, comes in third for Atto. It enables the entire MS Word 2010 file to be imported including images, tables and equations. Must test this sometime, sounds cool.

Usage: Content / Information transfer

Fourth, Full screen for Atto - maintained by Daniel Thies, enables the very useful fullscreen editing mode for Atto. Loved this feature on the old editor, so great to see it for Atto now.

And fifth in the category, for Atto is Font size - maintained by Andrew Nicols and Adam Jenkins, which allows the font size be altered as with other editors. I like to control the font sizes so this is a great addition.

Usage: Content / Information transfer

Cache

These are plugins for the Moodle Unified Cache (MUC). There are only five options and they are for old versions of Moodle, as the current core Moodle has included the features required.

Messaging outputs

These plugins redirect messages to users to other places. There are 6 options here and we look at the top one.

Mobile notifications is the messaging output to enable the site push notifications to users of the official Moodle Mobile App. This went into core in Moodle 2.7

4 favourite Repository plugins in Moodle

These plugins allow Moodle to connect to 3rd party repositories of files. There are 34 plugins and we look at the top 4.

PoodLL - maintained by Justin Hunt, comes in as number one in this category. It enables the user to record audio or video directly into the HTML areas among a range of features.

Usage: Assessment, Content / Information transfer

In second place, OneDrive for Business - maintained by James McQuillan and others, provides access to OneDrive for Business for file repositories and can access sharepoint sites for each Moodle course. Very handy if you use Microsoft and OneDrive (I do).

Usage: Assessment, Content / Information transfer

Microsoft OneNote - maintained by James McQuillan and others, comes in third.  It allows the user to browse their OneNote online content. Not used OneNote at all, but i know some people who use it a lot and can see how this can be useful.

Usage: Assessment, Content / Information transfer

Record Audio - maintained by Paul Nicholls, is fourth in the category. It enables users to record audio and upload audio recordings including via the "Moodle Media" button in the HTML editor. This is a great plugin, and would love to see Record Video/Audio in core!

Usage: Assessment, Content / Information transfer

1 favourite Portfolio plugins in Moodle

These plugins allow users to export content to other systems. There are only 2 plugins and only one maintained.

Blog Export Portfolio - maintained by Justin Hunt, enables Moodle users to export certain activities and items content to their own Moodle blog. This turns their Moodle blog into an internal portfolio. For those who don’t want an external portfolio this is a nice middle ground.

Usage: Assessment, Content / Information transfer

3 favourite Plagiarism plugins in Moodle

These plugins connect Moodle to different plagiarism services. There are 13 plugins and we look at the top 3.

Turnitin plagiarism plugin - maintained by John McGettrick and others, connects to the commercial subscription based plagiarism detection system turnitin.com. It integrates with the core Moodle assignment module.

Usage: Assessment

Second on the list comes PlagScan - maintained by Ruben Olmedo and others, it connects with the commercial subscription based system Plagscan.com. Have tried many systems, but not tried this one - must give it a look.

Usage: Assessment

VeriCite - maintained by Bryan Holladay, comes in third. It connects to the commercial subscription based service vericite.com. Also not tried this one before, so now have two to explore!

Usage: Assessment

Web service protocols

These plugins take the web services beyond what currently exist. There are no currently maintained options.

3 favourite Admin tool plugins in Moodle

These plugins provide useful scripts for admins to work on their site.  There are 18 plugins and we look at the top three.

The top plugin in this category is Merge user accounts - maintained by Nicolas Dunand and Jordi Pujol-Ahulló. The plugin assigns all activity and records from one user to another - so in effect it looks like one user did it all. Often you have multiple accounts with people registering on two emails - so this is a great tool to undo that fun!

CourseBank - maintained by Adam Riddell and others, comes second and provides integration with a Moodle Course cloud backup service. Having a good plan for course backups is an essential part of the IT plan for hosting your Moodle site.

In third, Inactive User Cleanup - maintained by Arindam Ghosh and Dualcube Team, this deletes inactive user accounts based on a set of options.

Calendars

These plugins provide different types of calendar systems to the standard. There are three available so I look at the top one.
Persian calendar - maintained by Shamim Rezaie, provides Jalali calendar support in Moodle.

3 favourite Other plugins in Moodle

Plugins in this category, don’t fit anywhere in particular and do not conform to one type. There are 31 in this section, and we look at the top 4.

Top in this category is the WIRIS quizzes - maintained by WIRIS. This provides a set of commercial question types for Moodle related to mathematics and science.

Usage: Assessment

The Kaltura Video Package - maintained by Mike Churchward, is for Moodle 1.9 and is second on the list. Kaltura is a good video platform and have used it with a number of organisations, so this certainly is interesting.

Usage: Content / Information transfer

Third in the list is Navigation buttons - maintained by Davo Smith, which provides customisable navigation buttons under each activity or resource to aid navigation between them) - very scorm like with Previous/Next). This hasn’t been updated to latest versions.

ILP Block - maintained by Richard Havinga and Nigel Daley came in fourth, and is only updated to Moodle 2.6.  It provides Individual Learning Plans with a lot of information integration possible. 

Usage: Assessment, Content / Information transfer

(chopping up post into parts)

• Autoenrol cohort
• UBEditor

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.

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.

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

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.

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.

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.

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 ).

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!

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

• Elegance (already claimed by Bas Brands- please set him up as maintainer.  Hooray!)
• Melbourne
• Zebra
• Codepen Filter
  

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

Thanks 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.

Hello David,

As a starter, I'll take the mass enrol plugin https://moodle.org/plugins/pluginversions.php?plugin=local_mass_enroll

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

Cheers,

Rogier

Hi David,

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

Séverin

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?

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 moodle.org 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.

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!

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.
  
• 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!

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!

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.

Hi,

It seems the AttControl plugin at  https://moodle.org/plugins/view/mod_attcontrol IS NO LONGER MAINTAINED BY ITS AUTHOR.

Can it be put in the list of plugins seeking new maintainer at https://moodle.org/plugins/browse.php?list=set&id=61  ?

Thanks.

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.

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

• Planet eStream Assignment Submission Plugin and iFrame Filter extend the possibilities and features of the existing repository plugin that integrates your Planet eStream server with your Moodle site.
• Allocation form activity module allows teachers to define available slots (such as study groups, project teams or exam terms). Students sign themselves up to them in order they prefer. Students' choices can be downloaded for further processing in a spreadsheet editor.
• Active quiz module is a successor of the known Realtime quiz (that has been featured in this blog last year). It adds some nice new features - especially the question bank integration.

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 moodle.org 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.

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.

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?

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.

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!

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.

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!

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?

Software engineer and a big fan of Open Source.

Heh, that was short indeed 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

2. 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.

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 https://snowdrift.coop .
• Crowdfunding done with support from Moodle - e.g. the one at moodle.org 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: http://www.vim.org/sponsor/

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 moosh-online.com/ci/) 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!

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

• FlexiBase theme by Richard Oelmann is a bootstrap3 based theme, but it uses flexbox to create the layouts, rather than the bootstrap grid.
• Restriction by dataform content by Itamar Tzadok is another Dataform subplugin. It allows to define availability conditions of an activity or section based on a content of a designated Dataform instance in the course.
• Campus theme by David Bogner and Gareth J Barnard is a light, colourful, feature rich and highly configurable theme with some unique features.
• Morecandy theme by Mary Evans is based on the standard More theme with some interesting additions.

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.

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.
    unset($_GET['sesskey']);
    unset($_POST['sesskey']);
}

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.

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
• 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.

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.

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.

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.

• 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.

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.

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. This Atto widget plugin must really be seen as a part of the bigger plugins set that allow users to easily record and store video, audio and drawings almost anywhere in Moodle.

Read on to see how PoodLL started to solve specific pedagogical use-case and teacher's need, why the phase of plugins design and specification should not be underestimated and what is the business model running the recent PoodLL development.

Interview with the maintainer

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

"Looking like Martin Dougiamas"

How did you get into Moodle and Moodle development?

In the high school I mentioned above, I wanted the students to record audio for an activity but found the language lab we used too restrictive for the task I had in mind. I installed Moodle and soon got the Moodle bug, and have been using and writing code for Moodle ever since.

Next to the PoodLL Anywhere, there are also other plugins in the PoodLL set. Can you shortly describe them and explain how they all work together?

PoodLL the set, basically enables the submission of audio/video recordings and whiteboard drawings as content to Moodle. All of that core functionality is in the PoodLL filter. PoodLL Anywhere and the other PoodLL mods use that functionality in their own way. PoodLL Anywhere adds video recording, audio recording, drawing, and webcam snapshot icons to the HTML editor. So students or teachers can easily record their voice or draw a picture into an html area. Other popular PoodLL plugins are the PoodLL Database Activity Field and the Online PoodLL assignment type and the PoodLL repository.

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

A legacy of coding PoodLL at nights, and between classes while teaching in high school was that I became used to coding in short sessions from different computers. So I used a programmers text editor, an FTP client and a remote server. That is still my preferred PHP development environment. On Windows I use Notepad++ and Filezilla. On Mac I use TextWrangler and FileZilla. Using an IDE makes a lot of tasks easier, especially debugging and jumping all over Moodle looking at the code. So I do use an IDE sometimes, and in those cases I use Netbeans,

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

I am a late convert to Git, but have grown quite dependant on it. That said I don't maintain separate branches publically. Each of my repositories on Github just has the master branch. I have written around 30 plugins for Moodle now, only some of them are on Moodle.org. If the project is for someone else (usually) the process of designing the plugin can take quite a while. Usually we pass Balsamiq mockups and tech docs back and forth and have a number of Skype calls. Once I really understand the vision for the plugin, I start coding. Inevitably if this lead phase is not thorough enough it comes back to bite me. So i consider it very important.

I usually start with the closest thing available to the plugin that I am developing, and base my plugin on that. I use my text editor search and replace features to rename all instances of the frankenstyle component name to the new plugin name. I remove all the code I don't need and add in my own. Then its just "code and page reload.” The final programming task is usually implementing backup and restore. The fun part is writing docs and doing screencast walkthroughs at the end. I use BitBucket in place of Github for projects that are not public. By this time next year I hope to be a late convert to behat.

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?

PoodLL is free and always will be. I have been fortunate that some requested PoodLL features and one of the PoodLL plugins were funded. But PoodLL itself has never paid its way. I have tried donation buttons and offering support packages but these come nowhere close to covering my time. My current development income comes from partly from customizations of PoodLL for specific uses, and mostly from custom plugin development.

But PoodLL is now a brand. Everything from the name, to the logo, to my twitter handle @poodllguy, and having its own site led to that. Though at first I did not consciously work towards it, later I realised that the brand had value behind it. So though PoodLL the set of plugins never paid its way, as a brand it has definitely opened doors and given me an advantage over others in getting work and opportunities.

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

I have a big list of plans. PoodLL 3 development gets underway this year, and it is scheduled to arrive in time for Moodle 3.0. It will feature full HTML5 audio and video recording, a common API that other developers can hook into, and a subplugin structure for alternate recorders. There will be also be "storage adaptors” so that PoodLL recordings can be stored off Moodle, eg at Amazon S3 or Dropbox. The current ability to use PoodLL as an alternate to the Multimedia plugins filter will be split into a separate plugin just for that purpose. It will be based on my VideoEasy filter. The current PoodLL widgets (flashcards, stopwatches etc) will be split off into a separate plugin based on my Generico filter.

Thanks a lot Justin. And good luck with all your contributions.

Teacher's perspective

I asked Mary Cooch, the Moodle HQ's Community Educator, for a review of PoodLL plugins from teacher's perspective. Mary says ...

My favourite Moodle plugins tend to be the ones created by practising teachers who actively use the plugin with their own classes. They discover a missing feature, fill that gap and now other educators in similar situations can benefit. Such is the case with PoodLL, versatile and user-friendly, simplifying magnificently the addition of audio and video (and a few other cool things too!) into Moodle activities. Justin's background is in language teaching, like mine, so I'll start there. I always struggled with assessing students' speaking skills individually: light-years ago as a novice teacher, I would take home a box of 32 cassette tapes (later morphing into usb pen drives), onto which each student had recorded the weekly homework, and I would spend whole evenings slotting them into my recorder, listening and commenting back. Now students record themselves speaking directly into Moodle with PoodLL and my colleagues in the Languages department sit comfortably with their iPads moving from one submission to the next and then use PoodLL to record their feedback. (OK grading still takes hours, but we've cut out the tedium and streamlined the process for all concerned!) But what if your language is not spoken? I've seen great examples of PoodLL being used in the teaching of Deaf Sign Language - video instead of audio - and when PoodLL Anywhere is used in a forum, other classmates can watch and respond too.

PoodLL is more than just a tool for language teachers; anywhere that audio and video can be useful, PoodLL fits the bill, from young students with special educational needs who speak their assignment instead of typing it, to adults on a presentational skills course who collaborate in a workshop activity, videoing themselves delivering a speech and getting constructive feedback from their peers. And PoodLL is more than just video and audio: it makes adding handy teaching widgets very straightforward - dice and counters for games and timing activities available to both teacher and students. Combine these with flashcards or video and you quickly generate fun tasks which allow for practice and independent learning. Display a clicker counter with a YouTube video and get them to count how often a certain type of key term for your subject is used - then move on to a flashcard activity with a timer for testing understanding of these key terms.

I particularly value PoodLL for its ease of use on different devices; while we normal mortals may be aware of different file types and of Flash issues on some devices, we don't want to be troubled with figuring out the details. PoodLL does the detective work for us so we can just get on with using it. Many students now will be accessing Moodle either at home from their iPads or smartphones or in class if the BYOD policy allows. How neat to complete a tech project, take a snapshot of it with your iPad and and share it in a forum with PoodLL Anywhere. Or use the whiteboard feature to draw a picture. Or handwrite an assignment response straight from your tablet. Or... well.. I will stop, and let you discover its versatility for yourselves

Thanks a lot Mary

Dances with devs

One of the reasons I started this blog about featured Moodle plugins was that I wanted to present developers as real humans behind the software. With real faces, background, families and hobbies. I am really happy I got permission to share this awesome video of Justin dancing.

If you have not yet tried it yet, check PoodLL. It's a robust, well written and - which is most important - well maintained Moodle plugin doing one thing (well, three things) well.

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.

Hi David,

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

Thanks!

Joseph

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!

Cheers

Mary

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

• 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.

• 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.

• 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.

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 freedom to use the tool in many creative ways to facilitate students' learning. Today's featured plugin - Dataform activity module by Itamar Tzadok - is a perfect example of such activity. Started its life as a fork of the standard Database activity module, it evolved into a rich set of related plugins and subplugins with lot of features.

Interview with the maintainer

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

"That's how much hair I used to have (although it wasn't green)."

Hi! I certainly can. I live in Kingston ON, Canada. I started my professional career as a software developer, then IT manager and consultant. At some point I went back to school to pursue MA in Philosophy and discovered online learning. I stayed in the university for the next 10 years or so, facilitating and/or delivering hybrid courses and online activities, as well as pursuing a PHD in the history and philosophy of early modern (17th Century) science. Throughout I have continued to provide professional services as a consultant mainly for Learning Management Systems and Instructional Design, and that is what I still do today.

How did you get into Moodle and Moodle development?

In 2006 York University (Toronto Canada), where I was working and studying at the time, piloted several Learning Management Systems as possible alternatives to WebCT that was then in use. I was invited to participate and tried out the candidate LMSs in courses. I knew what I was looking for, that is, an open system that would offer high degree of flexibility and allow me to go beyond what it formally offered. I found Moodle to be fairly open ended and particularly easy to enhance on the client side by way of html, css and javascript. I voted for Moodle and with a bit of luck Moodle was chosen. In courses I constructed complex activities mainly with the Quiz module and Database module. In the Quiz, I liked in particular the CLOZE question with which I created rich-content interactive questions. In the Database module I liked the ability to create non-standard activities and resources. Initially I used html, css and javascript for enhancements. Soon enough I reached a point where the client side enhancements would not cut it, and I started working on plugins that would provide the functionality I needed from the server side. And that is how the Dataform project (among others) started.

What did make you to start with it?

The Dataform project started off from the (my) need for a better stronger faster Database module. In particular it was absolutely necessary to have bulk entry actions and multiple views without html/css/javascript tricks. And so I took a copy of Database module 1.9.11+ (20110323), turned it to a new plugin and started implementing the envisioned features. The work in the beginning was fairly hectic and more experimental than anything else. But it slowly began to take shape and form.

Towards the end of 2013 I started a major revision of the Dataform for Moodle 2.6 onward. The main objectives were to improve stability and performance, remove unnecessary components and adjust the code to the latest Moodle infrastructure. A lot of effort was put in adding automated tests, unit and acceptance. The plugin docs also went through substantial revision. This effort continues to date.

Dataform 2.6 was released in April 2014, Dataform 2.7 in July, and with Dataform 2.8 the plugin caught up with Moodle’s release schedule and will continue according to that schedule.

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

For Moodle development I use mainly WAMP on Windows. I also have MAMP on iMac which I use for instructional design projects. I used to have also LAMP on Debian Linux but have no need for it at the moment. For coding I use NPP (Notepad++). It's minimal but so far does the trick. Early in my career, some 20 years ago, I was fortunate to have excellent mentors who encouraged the team to write code with the ridiculously minimal vi editor. The rationale was that a minimal editor would force you to write minimal (not to be confused with simple) and in this respect more efficient code. And we were developing C3I and AI applications. You may or may not agree with this rationale and either way is fine. I can at least say this. If for some reason you can only use a simple tool, it doesn't mean that you cannot do complex things with it. And it definitely shouldn't be an excuse for not trying. What NPP can’t do is generate PHP docs. And so for this purpose I use the somewhat less minimal NetBeans IDE. It’s a strange mix, for sure.

As can be seen in the illustrations, my typical development screen behind the windows is green. Then I typically have 3 command prompt windows in the corners. The bottom-left is for phpunit cli, the bottom-right is for behat cli, and the top right is for the selenium driver. The top-left corner is reserved for the Acceptance Test Site browser window that the behat cli (from the bottom-right corner) opens. These are now the most important tools in my Moodle development. In particular the phpunit tests serve as a compiler and will alert me to coding errors or debugging messages, and so I run the plugin tests every so often during coding. In the middle is the NPP editor to write the code and a browser to check things via the UI, and I switch from one to the other as required. There are also occasional Git Gui and Git Bash windows which I manage from the taskbar. Github, Moodle Tracker and Moodle docs are open on a different computer which also has a fair amount of green on the desktop background.

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

I work on the Dataform whenever I can between projects. The best of all worlds are of course Dataform related projects which allow me to rest a bit between projects.

Since 2.6 Dataform releases follow Moodle releases. I try to release major versions as soon as possible after the respective Moodle version release. Dataform 2.8, for instance, was released the same day as Moodle 2.8. Minor versions are released as needed. There are currently 7 plugins in the Dataform set and I support at least 2 major versions, and so the last release, in early November, was actually 14 releases.

The code is organized in branches similar to Moodle's, that is, MOODLE_26_STABLE, MOODLE_27_STABLE, MOODLE_28_STABLE and so on. The same holds for tags. Minor versions consists of mainly fixes and improvements but may also include new features. The Dataform auxiliary plugins such as the Dataform view block, Dataform view mod, and the rule blocks typically do not require minor versions.

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

More than enough for one lifetime.

The Dataform standard release currently consists of a total of 32 plugins. This includes 25 sub-plugins that are packaged under the main mod_dataform plugin and are seamlessly installed/uninstalled with the main plugin, and 6 auxiliary plugins that are released and installed separately. My development environment contains at least 12 more sub-plugins and auxiliary plugins in different stages of development or experimentation. These include new and to-be-released field types, view types, text filters, rule types. Then there is a wish list of improvements and new features.

Probably the most important item in the list, in my view, is a major conceptual and structural refactoring of the Dataform fields. You see, the initial structure of the Dataform was inherited from the Database module, and while some aspects of the Dataform as well as most of its code are by now considerably different from the Database's, certain others remained the same or similar with the same or similar limitations. The concept of the fields is a case in point. In the Database module the fields have been conceived as place holders and input elements for entry content. But that is already a specialization. Essentially and more generally they are widgets. And we need widgets not only in the entry level but also in the view level. Or even some entry level widgets may have relevant behaviour and presentation in the view level. One simple example is a dropdown quick filter that filters the list of entries by distinct content of a menu field. This can be part of the menu field but should be displayed in the view level rather than the entry level.

Not sure where and how it ends, so just moving forward and taking it 5-6 features at a time.

Thanks a lot Itamar. Good luck with Dataform and all other contributions!

Thanks for having me and for making these contributions possible!

Impressions

I admit I am very impressed by the features the module provides and the way how Itamar makes use of subplugins to implement them. To highlight just some of them:

• The in-built support for entries workflow. This is something I missed in the standard Database module. Each entry in the Dataform can be in a particular state (such as "Draft", "In review" and "Published"). These states are defined by the user to fit the given activity context. Also defined are transition rules, that is who can change the entry from one state to another. So you can, for example, set it that students submit entries for review but it's only teacher who make them public. See the module docs for more details.

• Planned support for advanced grading methods so that entries can be evaluated and graded using rubrics, marking guides and other forms eventually. Currently the module supports automatic grade calculation based on the number of submitted entries - more in docs.

• Ability to display selected view directly at the course page. This little yet very powerful trick allows to integrate the selected dataform contents and UI directly into the course main page. This feature itself has big potential - from displaying list of course references (citations) to turning the course page into an activity stream known from social media portals.

• The presence of unit tests and behat tests.

• The plugin documentation hosted at Moodle docs wiki. If you like and use the module, I am pretty sure Itamar will appreciate your help with finishing and improving the module docs pages.

There are some things that could be improved, naturally. I reported those spotted during the review into the plugin's bugs tracker. Having seen how Itamar is responsive and supportive in forums, the tracker and the plugin page comments, I rest assured they will be addressed soon.

Said that, I am happy to give the Featured Moodle plugin award to the Dataform module and I am looking forward to opportunity to use this plugin in production. Well done!

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 moodle.org 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.

Hello,

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 (https://techsupport.lambdasolutions.net/hc/en-us/articles/200427963-Popular-Moodle-Plugins), 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: https://github.com/ucla/moodle-enrol_invitation, https://github.com/mouneyrac/moodle-enrol_invitation/network or in the plugin page comments. I think it's a small plugin, perfect to start coding with Moodle

Cheers,

Jerome

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 environment. Moodle tries to provide teachers with well aimed tools for particular pedagogical scenarios.

The best plugins I've seen have this in common: they do one thing, they do it well, and the demand for that thing comes from real teachers' daily experience. The plugin I discovered just recently falls into this category. It is the Realtime Quiz activity module.

The following video gives an overview of the plugin's main features. It has been shot with older version but the concept is still the same.

We asked the plugin author, Davo Smith for a short interview. Read on and find out how the Realtime Quiz plugin started, how actual experience with Moodle as a teacher helps the development, or how releasing plugins and providing support for the community for free can eventually change one's career.

Interview with the maintainer

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

I live in Sheffield, with my wife, Sarah, and my two children. I have worked as a Senior Developer at UK Moodle Partner, Synergy Learning for the last 3 years. Before that, I spent 8 years as an IT teacher, and before that I was a developer on Superman: Shadow of Apokolips for PS2/Gamecube.

When I’m not busy developing Moodle plugins, my family are active members of our local church, I’m also involved in the Friends group for our nearest park, an annual Sheffield community arts festival (Peace in the Park) and the Sheffield Green Party.

How did you get into Moodle and Moodle development?

The sixth-form college where I taught for most of my time as a teacher used Moodle for their VLE. I was interested in the interaction you can get from the hand-held quiz clickers, but didn’t want the disruption of handing them out in an IT classroom, so I developed the Realtime Quiz plugin to work in a similar way within Moodle, but without the physical devices. I then developed the PDF annotation plugin, as students struggled to read my handwritten feedback on their assignments and the Checklist plugin, as they kept missing out important parts of those assignments. Drag and drop upload was developed, mostly, just to see if it could be done.

After releasing these plugins for free, I started to pick up a bit of freelance work (initially making additions to my own plugins). This then became a full-time job offer from Synergy Learning, which is where I am working now.

Does your previous teaching experience affect your work as a developer today?

Obviously, my own plugins would never have been developed if I was not using Moodle on a daily basis to support my classroom teaching. Whilst I am no longer a teacher, I hope I still have some good insight into what it is like to use Moodle for course delivery and this should have an impact when I’m thinking about how best to structure screen layouts and forms. It has certainly left me with a good understanding of the features available within Moodle core and the different ways they can be used (even if my teaching experience was with Moodle 1.9 only).

We know you are very active and supportive member of moodle.org community forums. What does providing support on forums give back to you personally?

I get a lot of enjoyment out of being able to help other people on the forums. I also find that reading posts and answering questions on there often leads me to discover new areas of Moodle, whether in the front end or inside the code. This is especially true when other Moodle developers (Tim, Andrew and Petr, to name a few) jump in to point out better solutions than the ones I’ve proposed.

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

My main desktop runs Debian + KDE, with Apache as my local webserver and a MySQL database. I’ve been using PHPStorm as my main IDE for the last couple of years and would now feel very lost without many of its features (before then it was Emacs). Other indispensable tools are Chrome (with the built-in developer tools), git + gitk, meld for comparing changes and Spotify (on my Windows laptop) to keep me sane. On the rare occasions when I need to edit images or icons, GIMP or Inkscape come into play.

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

These days most of my plugin development is done for specific clients - typically there is a git repo with a copy of Moodle in it and any plugins for that client are developed in that repo. Where possible, these plugins are developed on a separate feature branch and then merged into the ‘master’ branch for internal testing, across to an ‘rc’ branch for customer approval then into the ‘release’ branch for deployment. For any that are subsequently released to the public, a separate github repo is created, containing just the latest code for the plugin itself, without the rest of the Moodle code.

For my own plugins, I tend to just work in the master branch, as much as possible. Within reason, I tend to keep the master branch compatible with all Moodle versions supported by that plugin (with a few extra ‘if’ statements to handle differences such logging/events and context objects). Whilst I appreciate the ‘cleanness’ of having stable branches for different Moodle versions of plugins, I find the simplicity of being able to apply a fix to just a single branch makes it easier for me to maintain my plugins in the limited spare time I have available.

I’m getting to love Behat tests more and more and, once I have a chance to write them for all my own plugins, I am sure they will save me a lot of time when checking them against each new Moodle release.

Do you have some particular plans for further development of the Realtime Quiz export plugin? Or do you consider it feature full now?

I’ve recently done a little bit of a tidy up on the plugin, adding some Behat tests and allowing a teacher to reconnect to the quiz if they’ve navigated away from it (which was essential to allow the Behat tests to work). I’ve also just had some fixes through from the developers over at Lancaster University. There have been a number of requests to add features such as updating the gradebook and working with the Moodle question engine; these are things that I would love to see in there at some point in the future.

As with all code that you look back on after a few years, there is always bits you’d love to rip out and rewrite, but overall I’m pretty happy about how it works now. Having Behat tests in place should also make it safer to rewrite some of the backend code, as well as quicker to test the plugin against new Moodle releases.

Thanks a lot Davo. And good luck with all your future contributions.

How it works

Realtime interactivity between two (or more) browser sessions is not natural part of the HTTP world. There are multiple mechanisms of how the feature can be achieved, typically relying on an mediating server and some kind of push technology or a polling technique. As admins of many Moodle sites do not have access to the web server configuration to perform required tuning, certain methods like long-polling do not suit Moodle well.

The Realtime Quiz uses technique called periodic refresh, also known as AJAX polling. The view.php file executes Javascript code that then periodically requests data from the quizdata.php script via XMLHttpRequest. There is an in-built support for prolonging the requests interval automatically in case of issues with the network (and recovering back once the server responses in reasonably short time again).

The module is using plain Javascript to implement this behaviour. Written years ago, it survived the Age of Frameworks until todays when vanilla JS approach becomes popular again. This may make it an interesting contribution to the ongoing discussion on future of Javascript in Moodle (to be precise, there is a small YUI-dependent function used for a visual effect in the question editor but most of the JS code does not rely on a framework).

Conclusion and suggestions

The Realtime Quiz code is well structured and easy to follow and study. It has clear design of database tables and capabilities. Some parts of the activity module interface (such as realtimequiz_user_outline() or realtimequiz_print_recent_activity() callbacks) are not implemented yet with a @todo note left in the code. Backup and restore are supported for both 1.9 and 2.x versions (on-the-fly conversion of 1.9 backups into 2.x during the restore is not implemented). The coding guidelines are generally followed, although internal functions do not have phpDocs documentation. The realtimequiz_pluginfile() function should probably do a bit more access checking, including the capability checks.

The module made very good impression on me, from both user and developer perspective. I am happy to give it our Featured plugin award, and to wish Davo good luck with further development of it.

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 spotlighting a plugin that can help you to deal with these duplicates. It is an admin tool called simply Merge user accounts.

The tool tries to merge two Moodle user accounts into a single one. The solution is based on re-assigning all activity and records referring to the user A so they refer to the user B. This will give the effect of user B seeming to have done everything both users have ever done in Moodle.

Interview with the maintainers

The plugin maintainers, Nicolas Dunand and Jordi Pujol-Ahulló shared their thoughts about the project’s history and development background.

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

Nicolas: Hi! My name is Nicolas, and I work in Lausanne, in the French speaking part of Switzerland. I have an MD in process engineering, but turned to IT shortly after graduating. I'm now working at the University of Lausanne, as an IT systems engineer. Since the adoption of Moodle by the university as our main online learning environment, my duties have mostly evolved around Moodle: developing the servers infrastructure, maintaining the software, developing plugins, and integrating Moodle with other information systems whenever feasible.

Jordi: Hello! My name is Jordi and I live in Tarragona, Catalonia, Spain. I am PhD in Computer Science with European Mention, in the field of Distributed Systems. Currently I’m working as software architect and software engineer at Universitat Rovira i Virgili. My University adopted Moodle in 2004 as its Virtual Learning Environment and we are responsible for Moodle integration with other University information systems. Besides, the University unit I’m working in, Servei de Recursos Educatius, is responsible for other teaching and planification applications and programs addressed to support to and increment teaching quality.

How did you get into Moodle and Moodle development?

Nicolas: As Moodle has taken more and more prominent position in my university's teaching support services, Moodle has become a central part of my work. What was initially just one service we provided among others became the central point of my job. I work in a service (RISET - Réseau Intefacultaire de Soutien Enseignements & Technologies) that values teacher input and requests a lot, so over time the list of third-party and home developed plugins grew quite a lot. We try as much as possible to follow a policy of sustainability when using third-party plugins, so our goal is of course the same when developing our own. In that sense, I try as much as possible to make any portable plugins public. This is for two main reasons: first, we profit so much from the whole Moodle community that it feels good to give something back, and second, the Moodle community is very efficient at giving feedback and requesting new features we sometimes hadn't thought of.

Jordi: Sincerely, I get into Moodle due to my job. One of my main tasks of my job is to support technically Moodle into my University, keep it up-to-date, planning and performing Moodle upgrades, as well as develop plugins (enrollment, blocks, locals or authentication) necessary for the University community. Apart from my contribution to the Merge Users administration tool, we contributed the Moodle community with other public plugins, like auth_ip, and other private plugins. Our aim is to make any plugin we develop as publicly available. However, private plugins were finally necessary since other University information systems we are synchronizing with, are so particular or complex that they do not fit into any Moodle standard plugin or they are related to private information systems.

I really like my job, actually, I enjoy it, and it allowed me to keep in touch with open source software and a live community like Moodle one, where people truly share and report issues as well as contributions (like the last ones in Merge Users plugin). I love that, I love contribute in something that helps and address needs from other people around the world, at the same time that they fit our needs.

Nicolas: Yes, I really like that, too! It's great to be able to collaborate with Jordi, even though we've never met in person. It is also very exciting to get feedback from people from all around the world about the work we're doing.

You both are set as the maintainers of the plugin. How does your co-operation look like?

Nicolas: I had first written a script for Moodle 1.9, which then got updated to support Moodle 2.0 by Forrest Gaston from Indiana. The script then evolved into a proper plugin with the help of Mike Holtzer from Pennsylvania. I was lucky enough that both of them – and some others – were kind enough to share back their own improvements, so I could move on and provide the first versions of the plugin via the Moodle plugins database.

I was even luckier later when Jordi stepped in, as he is really motivated by this plugin and improved it tremendously. I think he's now responsible for most of the code present in the latest versions. As I don't have any background as a software developer/architect myself, I'm glad I can rely on Jordi's experience. I think that thanks to him the quality of the plugin code and UI have improved a lot in the last year.

Jordi: We co-operate mainly via the Nicolas’ github repository, and then with very few private emails for long term planning and about particular things that need a mutual commitment to show publicly a common point of view.

As a team, we have advantages like: a) peer-review from the other part, and then, a major quality of the product we, with other contributors, are providing; b) shared responsibility since, most of the times, we only need that one of us replies to any contributor or question.

Working with Nicolas is always a good experience, since he is really positive and decisive.

As the thread at moodle.org shows, the plugin started as a simple script back in 2008 to solve Nicolas’ need to merge two user accounts at his site. It has significantly evolved since then. What’s your motivation for further development and maintenance of the plugin?

In our University we had a recurrent issue on multiple users for the same person, since there are several points of user registration. The good point is that we are provided with a list of merging actions.

So, we had to add into our Moodle instance something that should address that issue once for all. Making a research on Moodle and the Moodle community, I found the Merge Request plugin of Nicolas that really looked pretty good. I really liked the way it behaved: a search and replace of user ids throughout the whole database. We could see it as a “brute force” search and replace, but at the same time, efficient. I decided then to make a series of contribution to make it more modular and extensible, configurable, with the goal of having a cronable script.

Since then, the plugin has received quite attention and other contributions that both Nicolas and me are reviewing. When they are ok, Nicolas accept the pull requests in github, and finally the downloadable version in moodle.org got updated with last version.

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

Nicolas: I'm using NetBeans as IDE, git internally on the command line, and TRAC to keep track of Moodle issues. We also use Redmine to track our team's work, but as each member of my team works on different things, we don't use a centralized issue tracking system. For administrative tasks, I rely mostly on the command line, editing text with vim and accessing databases with native clients.

Jordi: I use NetBeans as IDE, and Gitlab + Gitlab CI as project manager and continuous integration systems respectively. In addition, I use command line for git commits and conflict resolution, with customized git scripts for issue management that also interacts with Gitlab to create merge requests and accept them. Gitlab, in addition to project management, allows us to provide peer review to what we are working with, prior to accepting changes. We used Redmine before Gitlab, but since then we have noticed an increment on our software quality. With Gitlab CI we ensure the expected behavior of our software and provide automatic software quality testing. Finally, we use phpmyadmin for an easy and graphical access to databases. However, in the real infrastructure, we have only access via SSH and then command line is the only way to interact with the whole system, using vim to edit files and native clients and customized scripts to connect to the databases.

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

Jordi: In our plugin, we only have, by now, a master branch, but we have planned to build several branches to make sure our plugin will work and then, separate backward incompatibilities. Since we use github for code management, development workflow is as usual.

In general, in our work, we have mainly four statuses for issues:

• Developing, in which we are solving that issue (bug, feature, enhancement, etc).
• Peer reviewing, in which some other colleague review other’s code and continuous integration is passed.
• Testing, in which some third person tests that what is added is what was asked for and what is expected.
• Accepted and resolved, in which that contribution is ready to be deployed.

Nicolas: As I’m working alone in day-to-day Moodle operations, my workflow is much simpler. Issues only have three statuses: open, in progress, and closed. This workflow is very flexible and open to interpretation, as I’m the one opening and closing the tickets, as well as deploying the fixes to our production servers.

Is there some bigger thing you would like to see included in your tool in a near future?

Yes! Testing! Unit testing and behat tests should be included. Since our contribution is in work time, we have the pressure of making things done in the shortest time, so that testing is, differently to TDD, the last thing to add. We know that it is a big effort, but that will add software predictability and quality.

What communication channels do you use to stay in touch with users of your tool? How can they can ask questions and/or report issues with it?

We use Nicolas’ GitHub repository as the project management, and then any request, bug or contribution should be reported there. However, we also reply to any question posted in both the forum page and the official Moodle plugin Web page.

If you were starting now from scratch, what would you do differently in your plugin?

Jordi: It is hard to say, because this plugin is really hard to design. It affects whole database by “merely” update a user id by another one.

To augment software quality and predictability, I would like to have seen an API from Moodle to allow changing ownership of the user’s activity. That way, since there are Moodle modules interconnected between them, each consistent part will really know how to update a user id with another one.

Since there is no expected feature in Moodle core and API, the Merge Users plugin has to include such know-how and process each database table properly. To do so, the Moodle community experience is necessary to add the correct behavior of our plugin in any single Moodle part, even in third party, non-standard plugins.

Above all, I would have prioritized on plugin settings (for local configurability) and efficiency (caching and sql statements performance).

Nicolas: It’s very difficult to say for sure. One thing that was clearly not done here was to assess the needs of the Moodle community before developing anything. I just had this problem with multiple user accounts to begin with, saw that no one had proposed a solution yet, and worked out some hacky script to do it. Then things and people kicked in and shared their improvements based on my first try. I’m very thankful for that, but I think that this is really (if you’re not very careful) a recipe for very bad software design. However, and I would say thanks to Jordi stepping is as a plugin maintainer, things stayed under good control.

So, if we were starting now from scratch I think we would probably take things the other way around: think of what we need in terms of features and configurability, and then design the plugin. I’m not so sure that the plugin interface would have looked very different, but I’m sure the code would have!

Jordi: Reading the Nicolas last words, I MUST agree on his final remarks. I would like to add that, doing that together right now, the result would be amazingly promising. And I would like to thank you Nicolas to have created this plugin and let me join to it.

Thanks a lot.

Let the code talk

The overall idea of the plugin is quite simple. Find all places where the core user table is referenced and replace one user id value there with a new value. When doing so, the plugin relies on certain implicit rules - or rather habits - common in Moodle database scheme. For example, it expects the relevant fields to be named like userid, user_id, id_user or user, which is valid assumption in many cases. Beside that, there is a list of exceptions. For example, the fields createdby and modifiedby in the question table are explicitly listed to be processed, too.

The tool takes care of some cases that require special attention. Typically, when the user id field is part of an compound unique index. These special cases are well described in the README file shipping with the plugin. The tool aims to support additional (contributed) plugins, too. There is no inter-plugins communication API/callback to handle this automatically. If the additional plugin needs a special care, it must be hard-coded into the merge tool.

Even quite powerful in its simplicity, this approach has obvious disadvantages. The knowledge about the relationships to the user table has to be manually declared in the merge tool's code. If it is missing, the given area is not merged and it may be hard to spot it. For example, the Workshop module tables are not handled well by this plugin.

Suggestions

I believe that what could help is to try and make use of some sources that already contain the required knowledge about relations to the user table. One of them may be the moodle2 backup classes where plugins annotate their data that hold the user id. The second one is the database scheme files in the XMLDB format.

XMLDB provides a way to declare foreign keys and this information is stored in the plugin's install.xml file. An example of such declaration is the following part of the mod/workshop/db/install.xml file:

<TABLE NAME="workshop_submissions">
    <KEYS>
        <KEY NAME="overriddenby_fk" TYPE="foreign" FIELDS="gradeoverby" REFTABLE="user" REFFIELDS="id"/>
        <KEY NAME="author_fk" TYPE="foreign" FIELDS="authorid" REFTABLE="user" REFFIELDS="id"/>
    </KEYS>
</TABLE>

This says that the fields gradeoverby and authorid in the workshop_submissions table should be considered as foreign keys to the user table. As such, they must be processed by the merge tool when transferring the ownership from one user to another. It's true that not all additional plugin maintainers pay attention to these aspects of the XMLDB file. But some plugins have this done right, and it's a good opportunity to use this information. There is an API for accessing information in these install.xml files - such as database_manager::get_install_xml_schema().

The plugin's code is organised into classes with custom auto-loading feature implemented. Unfortunately, the mechanism does not take eventual naming collisions into account. The plugin uses classes like Config or Logger. Not only the capital letters go against naming conventions in Moodle. More importantly, these classes are loaded into the global scope without the proper component name prefix. So they should be either renamed to something like tool_mergeusers_config or refactored to use Moodle namespacing rules. Checking for expected and correct naming scheme is something we pay serious attention when reviewing newly submitted plugins into the Plugins directory. It's not a secret that plugins are not approved unless they have this done correctly. This issue itself could be a good reason to actually start thinking of more advanced branching model for this plugin, that would allow to maintain separate versions for particular Moodle release. That would allow to modify recent versions so they can profit from the in-built Moodle features (such as the mentioned namespaces and autoloading).

Some areas of the code are not fully cross-db compatible. For example, when searching for a user, the plugin searches couple of fields for the given value - including the 'id' column too. As the 'id' column is of type BIGINT, the LIKE operator can not be used (without explicit casting) on Postgres 8.3 and later. In this particular case, I would simply suggest to remove the 'id' field from the searched fields (as is does not make sense anyway to have users with id 1426 or 87427 returned when searching for 42). As usually, testing plugins on at least MySQL and PostgreSQL platforms is warmly recommended - and it's actually something that the community can help with a lot.

At some places, the plugin seems to re-invent what Moodle core already provides for no obvious (or inline documented) reason. For example, $DB->get_tables() seems to be a better alternative to how MergeUserTool::__construct() populates the list of Moodle database tables.

Since Moodle 2.6, the icon i/tick_green_big.* is not available any more (see MDL-40369 for details) so the broken image icon is displayed at the merging logs page (yet another example of when the "one branch for all Moodle releases" model reaches its limits).

Conclusion

The Merge user accounts tool has been available for a while. Originating back to a simple script posted to moodle.org forum, becoming a report and later rewritten into an admin tool, it raised attention of several contributors.

There are situations when something is better than nothing. Even if the tool does not do its job perfectly and may leave some database records still referring to the old user account, the final result is acceptable and may be an actual win for the poor student with multiple accounts created. The maintainers do great job in describing the known limits of their plugin's functionality and leaving a log of what the tool actually did. I wish Jordi and Nicolas good luck and enough energy to keep the thing moving on. It's definitely on the right track.

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 spotlighting in this blog. It is called Archaius.

The Archaius theme has been available in the plugins directory for more than a year now and gets regular updates since then. The current release called Archaius Tigris was published just recently and is available for Moodle 2.5 and higher.

The theme uses common three columns layout. It has responsive features implemented so on smaller screens, side blocks stack below the main content region and the horizontal custom menu bar turns into the items tree accessible via the common hamburger icon.

The theme settings page allows the site administrator to configure basic color scheme (to some extend), upload the site logo images (separate ones for desktop environments and mobile devices - i.e. devices with screen width less than 768px) and eventually provide custom CSS and Javascript. Such settings became pretty common in modern Moodle themes though.

What caught our eyes and actually made us to feature this theme was the author's attempt to bring additional UI functionality beyond what Moodle core theme API provides. Namely, side block regions can be slipped out of sight horizontally via two control arrow-like widgets on sides. Vertically, side blocks can be elegantly collapsed and expanded but with slightly different behaviour from what we know from standard Moodle themes. Archaius makes use of the jQuery Accordion module for this. As a result, the user can focus on one block at a time easily. The block heading part itself triggers the collapse/expansion of the block so there is no need for additional control widgets (like the plus/minus widget used by default). This helps to keep the user interface look and feel very clean. Additionally, the theme provides similar behaviour for courses using the topic format. It turns sections into collapsible areas so users can again focus on what's important at the given moment.

Apart from these, the theme has in-built support for putting nicely animated slideshow to the front page. Slides content can be edited by administrators directly at the front page easily, with impressive results. This allows to implement good looking hero unit element at the front page.

The custom menu bar is sticky in this theme - it is always displayed at the top of the screen. That makes it to play an important role in the site navigation.

Interview with the maintainer

The plugin maintainer, Daniel Munera Sanchez, shared his thoughts about the project's history and development background.

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

Hi, I am Colombian guy, who studied computer science at EAFIT University, Medellin, Colombia. Nowadays I am master candidate at the same university. I love web programming, thats why when someone ask me what I do, most the time I only said, I am a passionate web developer.

Well, I don't like only computers, indeed. Until the third year of my degree, I was training in a professional soccer team called Atletico Nacional from Medellín, Colombia. But, I had to stop playing in order to better focus on my studies while putting football aside as a hobby.

Since my second year at the university, I have been working in a research group called LINEA i+D+I de Tic. The main focus of the group is educational informatics. Because of that, I have been very close to the use of technology in education. I have to said thanks to all people which have been part of the group, because I have learnt a lot from them - both from the technical and educational perspective.

I also had the opportunity to go to India as a trainee at INFOSYS. INFOSYS is an Indian company focused on banking software. It was a great experience because India is another world if you compare it to my country. By the way, I was learning English at that moment and receiving classes from people with Indian accent was a big challenge. When I came back to Colombia, a professor offered me an opportunity to go to the University of Bergen, Norway. Like most people in my situation and my age would do, I said YES!!. I was there for a year, working with applications to support research about linguistic and apps to teach Spanish as a second language.

After my experience in the viking lands I came back home. Nowadays, I am 23 years old and I am working part time in a company called Place to Train. The company was born from a research project I worked on before going to Norway. I like my work. When I go there, I realize what people with dedication and focus can do.

This is a summary of part of my life and professional experience. It was great to remind myself my experiences while writing this. I am very glad for the opportunities that life has given to me. I hope I can say some day that I have been in all continents doing what I love.

How did you get into Moodle and Moodle development?

As I said before, I am part of a research group. The research group is focused in educational informatics.

In my first year at the group, we developed platforms from scratch using Ruby on Rails. I was just learning it by that time but I was surrounded by VERY good developers who help me a lot. We were testing platforms to support learning processes as well. Moodle was one of the platforms we tested. Being honest, the first time I saw Moodle, I thought, WAW, this web platform is kind of ugly.

After my first year in the group, I got curious about Moodle and I talked with my brother about it (by the way, my brother studied computer science too). He helped me to understand how powerful Moodle is. After some research and conversations I understood the problem to be "married" with a technology. So, I started to find strong parts as well as weaknesses in different platforms and languages I knew at that moment (just from a novice point of view).

Since then I have been working a lot with Moodle because of my context (universities, teachers, ...). I have been trying to improve what people around me and mysel consider important. As an example: the appearance of the platform. Luckily Moodle has improved a lot. So it is not difficult now.

From that time until now, I have been learning where Moodle could be useful without treat it as a golden hammer.

What made you start with Archaius?

When people at the university realized how useful Moodle is, they started to use it more. We built platforms to support a master program for people in Bolivia and Colombia, a platform for internal courses, etc. After some time, I realized that I was doing almost the same modifications at all platforms: changing colors, animations, logos. I was just modifying templates. I was getting bored, because doing that and only that all time was kind of frustrating for me.

Then, I decided to study a bit about Moodle themes, which was mostly what I was modifying. So, I created a theme that fit most of the requirements from people that were working with me. Since that moment I got some free time to learn about Moodle plugins and philosophy. I was going to the research group office after classes to learn and extend my plugin to make it better. At that moment, most people who were working with me were designers. Thanks to that I had a great support to make things look good.

Finally, when I was in Norway, I talked with a professor to get some time at work to standardize my plugin and release it in Moodle community. She supported my idea to try and help people who were helping me since some years ago. So, I started my project.

It was the perfect place to do it. All my friends were in Colombia and my brother lived in Norway. I got support and I had less distraction. It is a nice way to say: I was without friends in one of the coldest countries in the world. I am just kidding. I had a great time in Norway and met good friends. But still, believe me, colder places are better for developers.

After some time, I took the risk to upload my theme to the Moodle community. Very kind people reviewed my theme. I had to fix small details and after some modifications, my theme was made available.

I had to change the name of my theme as a suggestion of Anthony Borrow. He suggested me a name related with the original name:

"Daniel - I want to give some thought to the name of the plugin. Chameleon was a core theme in Moodle 1.9. I wonder if it would be better to rename the theme so that folks do not confuse the two or think that your version is a 2.x version of the one previously in core. Would you consider renaming it? Having been a fan of chameleons in my youth, you might even consider renaming it to anole wink Peace - Anthony"

Spanish speakers will understand how problematic could be the suggested name, it was fun.

Archaius used to be just my hobby. I used to dedicate some part of my weekends and nights to improve it. But now, Archaius is part of my master thesis. It was the best way I found to dedicate more time to improve it and have some support (time, money, more time to sleep). So, if you have time and you are the person that makes the technical decisions of your company or institution, I will appreciate if you answer my questionnaire. It will help me a lot, even if are not using Archaius as a theme for your Moodle.

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

• Sublime Text and Emacs: these are my IDEs.
• Iterm: As a console is better than the mac console.
• MAMP: To run a local environment.
• Web Server: I deploy to my server for testing in multiple versions of Moodle.
• Grunt: To precompile assets and minified jquery plugins.
• Rescue Time: I am starting to use Rescue time to know how I am using my time when I am in my computer, it helps me to organize my time and realize how many time I spend in each application while I am coding.
• Github Client.

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

I use github as a repository of my project. For testing I have two steps: first I test it at my laptop. When I think it is good enough, I deploy it to my server where I have different versions of Moodle installed. I check it in different versions for a while, trying to detect problems. Most time I ask my friends to help me in this process. After this testing I fix reported bugs.

The process to release depends of two things. If people report serious problems, I make a quick release with the fix. Otherwise I release a new version when I think I have a great new functionality. For example the main improvement of my last release was to adopt Moodle standards of including jQuery plugins.

I like Evolutionary prototyping approach and I have been trying to follow it.

I have been developing this plugin alone (from the programming perspective). I decided to create a github repository and create branches for different versions of Moodle and in some cases just to create versions with different features. After more than a year I realized I was working almost all the time on just one master branch. The other existing branch was a special version for Moodle 2.2. I used to fix reported issues, commit and push changes to the master branch - even without creating an issue on Github. I realized it could be better. So I decided to stop the 'master branch anti pattern' and re-organized my development workflow.

For whole this month, I have been learning how to follow a good versioning process, how to use the milestones correctly and how to motivate people to help me in different ways to improve Archaius. After my last release called Archaius Tigris, I want to improve the development workflow. I consider that this is VERY important to get people more interested in contribution.

What is the next big thing you would like to see in Archaius?

• Performance: Adaptive Web Design and Responsive Web Design are great. But I have been always worried about performance, and now I want to improve page loading without breaking Moodle standards. The last release was a step forward in order to follow standards related to Moodle Javascript. Even if I do not completely agree with how Moodle load jQuery scripts. These changes won't be very attractive to people but I consider it as a very important improvement.
• UX: I have been studying a concept called Plastic User Interfaces. It gave me an Idea to control where and when Moodle should render or not some blocks (as an example), in order to preserve usability. I am already working on it, it is part of my master thesis. What I want to render in the interface is only what works perfectly. I want to give the blocks and mods the possibility to report to the theme where they are not able to work.
• Finally, I want to improve fonts. I realized how important fonts are for websites. I want to improve the possibilities of my theme to manipulate fonts.

What tools and communication channels do you use to stay in touch with users of your theme? How can they can ask questions and/or report issues with it?

Well, People usually make comments on the plugin page as a first option. But I have implemented other communication channels to improve the development workflow and the detection of improvements.

• Blog: I created a simple blog to answer some of the questions, because I think blogs are good tools to teach people how to do small hacks and answer tricky questions.
  
• Bug tracker: I use Github issues tracker. People can report issues there and I can add it to milestones.
• Messaging: I used to receive direct messages in Moodle. I am new in Moodle community and I am just starting to use the communication channels inside Moodle.

How can community members help with further development of the theme?

As a said before, I am improving development methodology and communication channels to give people more options to contribute in different ways. But, I have to say that many people have overcome the lack of communication channels and have helped me a lot to rethink functionalities and define priority of improvements. Some of them use comments, other the blog and direct messages inside Moodle.

The opinion of teachers is very important to me as well as opinion of all the people who use the software in their institutions. I am not teacher and I don't realize what can be more useful for them. I am mainly focused in students, because the courses of my company don't have a teacher. There are only video conferences and Moodle resource to prepare for a final exam.

Any pull request at Github is more than welcome. Anyone who wants to learn about my theme and propose changes could do it through issues at Github, cloning the repository, commenting on my blog and Archaius plugin page.

Y PARA LAS PERSONAS QUE HABLAN ESPAÑOL, es mi lengua nativa, cualquier contribución es bienvenida y no tengo problema en responder en español o inglés.

If you were starting now from scratch, what would you do differently in Archaius?

This is a complicated question because I have been doing the best with the time and the experience I had. I would say, versioning of my plugin is a complete mess. So, I would like to go back in time and had read some posts and articles on that before I started.

Finally, I would follow all standards since the beginning and would use Moodle tracker to expose my opinion and receive feedback.

But overall, I feel I was very lucky. When I started this project, Moodle 2.0 was released. Some people have said life was more complicated before.

Thanks a lot.

Web designer's review

We asked Barbara Ramiro, the web designer of Moodle HQ, for her short review of the theme.

Key features

When I was asked to have a look at theme Archaius, the first thing I noticed was a neat, clutter free, visually refreshing course page. Suddenly my course page was decluttered from the overwhelming course contents. With only the list of topics displayed, it gave me a quick overview of the course. All the lengthy activities and resources were hidden on collapsible topics until I expanded a few. This brought my focus on the topics I wanted to see without getting distracted from other topics which gave me a better virtual learning environment.

Apart from the collapsible topics, I noticed two quite prominent arrows on the left and the right side of the browser that toggle to efficiently dock and undock a set of blocks all at once. This made it so quick to hide all the blocks that I did not want to see while browsing the course content so I could focus on one thing and not get side tracked. It also made it easy to expand the course content area to maximise the learning space and compensate for the maximum width of 1200px. And this theme comes in responsiveness which makes the learning space suitable on small screens as well even without bootstrap.

Another thing I noticed on this theme was the accordion style on the blocks which neatly collapses a block when I expand another one. This feature again reinforces focus on one block at a time on each side rather than confused and lost with all the many expanded blocks. It also prevents the course page from a long scroll.

Overall, the unique key features of this theme gave me a sense of focused learning environment and a pleasing user experience. The collapsible topics, the blocks docking system and the accordion blocks make this theme unique, dynamic and worthy to be featured.

Room for improvement

I find the arrow on the collapsible topic a bit small which could be easily overlooked and since it is a bit close to the topic it could be mistaken as a bullet type. Although the entire topic block is clickable, I think it would be good to enlarge the arrow a bit and position it on the opposite side to make it obvious and intuitive.

Though the blocks could be quickly hidden to maximise the content area, it only spanned half of my screen. It would be good to update the maximum width of the page for large screen users and with high resolutions screens, the font size looked a bit small so it would good to scale up a bit to make it easier to read and look more modern.

Let the code talk

Archaius uses theme_base as it's only parent theme. The config.php file contains code that disables the standard docking functionality (as it provides its own alternative) and loads common javascript code (including the modernizr library). Additional JS modules are loaded in the theme_archaius_page_init() function if they are needed (based on the theme settings).

The theme uses the theme_overridden_renderer_factory class and overrides some core rendering methods to provide the desired functionality. Particularly, the subclass theme_archaius_core_renderer provides methods block() to render side blocks contents, and two more methods to modify the rendering of the custom menu and its items.

One database table is created by the plugin upon installation to hold the required data for the slides at the front page. All images used by the theme (site logos and those embedded into the slideshow) are stored in appropriate file areas in the filepool. The function theme_archaius_pluginfile() does not perform any access control and the files are available to the public.

The code slightly violates the Moodle coding guides in details (such as using camel case style for some $variableNames) but in overall, the code is pretty clean, structured and easy to follow. For the action argument, the PARAM_ALPHANUMEXT would be more appropriate than the currently used PARAM_TEXT.

Suggestions for the maintainer

When testing Archaius, the most annoying thing for me was that the theme does not store the user's layout preferences. If the user wishes to have side blocks docked, they probably have reason for that. The fact that on each page load, the blocks must be docked again manually, significantly degrades this otherwise neat feature. Same applies to collapsing course sections. Things like this should be stored permanently at the server via an AJAX call.

I would also suggest to replace the arrow-like icons that dock the side blocks with something else. These symbols are commonly used for browsing the content in carousel banners and their current usage in Archaius goes against this common experience. It's especially obvious at the front page when slideshow is used, too.

I would suggest to improve the default font size used by the theme. The current default setting make the theme look a bit archaic when compared with standard Moodle theme.

For some reason, the admin block search tool has been put into the top right corner of the screen which I personally found contra-intuitive. For non-admin users, the valuable screen space is displayed as empty.

It might be useful to have a separate site logo displayed at the front page and another one on all other pages.

Conclusion

I am happy to give the Featured plugin award to the Archaius theme. I appreciate the attempt to bring innovations into Moodle user interface. I believe the theme is a good choice for sites looking for a original and customizable theme. There is a potential in it for becoming a very popular Moodle theme in the future. I wish Daniel good luck and a lot of quality contributed patches from the community.

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(https://moodle.org/plugins/view.php?plugin=theme_rocket) 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 Moodle.org, here's the link to our staging server:

http://staging.dualcube.com/moodle/crispmoodle/

Git link: https://github.com/dualcube/crisp_theme

Looking forward to hear from you.

Thanks and Regards,

Arindam

Team DualCube,

Skype: moodlecafe

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 from both user perspective (by Moodle HQ’s Community Educator Mary Cooch) and development perspective (by myself).

The HotPot activity module allows teachers to administer Hot Potatoes and TexToys quizzes via Moodle. These quizzes are created on the teacher's computer and then uploaded to the Moodle course. After students have attempted the quizzes, a number of reports are available which show how individual questions were answered and some statistical trends in the scores.

The plugin maintainer, Gordon Bateson, shared his thoughts about the project’s history and development background.

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

Hi, and may I say first how proud I am that HotPot has been chosen for this column. I’ve been moodling since 2003, and this kind of recognition and encouragement from the Moodle community really means a lot to me.

Originally, I’m from England. My background is rather eclectic. After taking a gap year to work in the technical support section of a large pharmaceutical company, I got a degree in Software Engineering at Imperial College in London and then worked for two years as programmer in London. For the next four years, I was a freelance musician, playing the sax in jazz clubs, piano in ballet schools, and keyboards on cruise ships. One of the ships came to Japan, where I got off and became an English teacher. I worked in “conversation schools” for eight years, by which time I had studied for, and received, my Master’s degree in Teaching English for Specific Purposes (TESP), so I was able get a job at a Japanese university teaching English and doing research into Computer Assisted Language Learning (CALL). I have been doing that for sixteen years. Do you notice the binary growth of my career path: one, two, four, eight, sixteen years? I wonder what I will be doing for the next thirty-two years.

• Full story of how Gordon came to Japan
• More details of Gordon’s Job Experience

How did you get into Moodle and Moodle development?

Before Moodle, there were two strands to my CALL research. On the one hand, I was developing a simple learning management system which I called Automated Student Rollbooks. It was based on Excel workbooks and used Visual Basic scripts to produce HTML pages that were uploaded to a web-server. At the same time, I was developing a javascript file called hot-potatoes.js to enhance interactive exercises created with the Hot Potatoes authoring software, so that the results of students’ attempts at the exercises could be stored on a web-server. Imagine my delight and surprize when I found out that Moodle had already solved the problem of generating aggregate grades and restricting access to online materials to specific authenticated users only, and that furthermore a preliminary version of the HotPot module for Moodle was already available.

• More information about automated student rollbooks
• More information about hot-potatoes.js

What made you start with HotPot?

I liked Hot Potatoes from the outset, not only because the interface for teachers to build the quizzes intuitive and easy to learn, but also because surveys on my students have showed that the exercises are genuinely engaging and useful. I had already developed the hot-potatoes.js javascript script to extract results from a Hot Potatoes quiz and send them off to a server, so it was a logical next step to write PHP scripts necessary to interface the Hot Potatoes quizzes with Moodle. There was already a HotPot module for Moodle that Tom Robb had pioneered in 2003, but having blazed the trail Tom was ready to pass on the mantle of HotPot maintainer to me. In 2004, the HotPot module was judged to be stable enough for inclusion in Moodle 1.5 and it stayed as part of Moodle core until Moodle 1.9. Since Moodle 2.0, it has been a 3rd-party plugin, and I am proud to say it always ranked highly in statistics for the top downloads from the Moodle plugins repository.

• Statistics on the top downloads from Moodle plugins

David's note: HotPot would probably be the top downloaded plugin in our stats but there was an accidental data loss related to the moodle.org server crash last year. We apologise for that.

You seem to be releasing new versions quite often. What is your development workflow and how do you organise the code in terms of branching, tags etc?

My development workflow is that I develop and test changes to the HotPot module on a “private” Subversion repository, and then, when testing is complete, I push the modifications to a “public” GIT repository on GitHub.com. The computers that I use to develop the software are all synced primarily to the Subversion repository. On all my development computers, I have a Unix shell script that will update the local Subversion copy of the module, transfer all of the publicly available modifications to the local GIT version of the module, and then push those GIT updates to GitHub.com. The zip file download from the plugins repository on Moodle.org is simply a copy of the zip file on GitHub.com.

I do not maintain branches and tags. There is only one version of the HotPot module and it will run on any version of Moodle 2.x. To this end, the HotPot module has its own internal API for core components of the Moodle API that have changed between Moodle 2.0 and the latest version of Moodle - currently Moodle 2.8. These components include the APIs to access context, textlib, and logs. I understand that this makes the code slightly less efficient than is optimal, because there is an extra layer of API. However, it makes the code easier to maintain for me and enables me to reliably apply modifications that work across all versions of Moodle. I also believe that this approach makes it easier for admins to keep the HotPot module up-to-date.

Since the HotPot module is quite a mature and stable piece of software, most of the changes are small tweaks and fixes. I like to make these available as soon as I have tested them, rather than using a time-based release cycle. That is why there are many small and frequent updates.

• HotPot Git repository at Github

What is the next big thing you would like to see in HotPot?

Until last month, the big thing I wanted to see in the HotPot module was Hot Potatoes drag-and-drop exercises running on touch screen devices. However, that has now been implemented - yay! - so I can focus on the things further down my HotPot wishlist.

Probably the biggest item on my HotPot wishlist now is an editor for HotPot files that is available from inside the Moodle interface. The way I imagine it working would be that when you click on a file in the Moodle file picker, as well as “Delete” and “Download” options, there would also be an “Edit” option. Clicking “Edit” would initiate a suitable editor. This would obviate the need to edit files outside Moodle and re-upload them to a repository.

What tools do you use to stay in touch with users of your module? How can they can ask questions and/or report issues with it?

The primary channel of communication about the HotPot module is the HotPot forum. It is quite an active forum and posts usually receive an initial response within a day. If it is a bug report or a technical issue then I will probably be the first to answer, but the forum is also subscribed to by an army of veteran HotPot users who will take the lead in responding to posts about getting started with Hot Potatoes, best practice, creative uses for the software, and methodology.

The HotPot module also has its own tracker issue channel, which I respond to, but most of the traffic nowadays comes from the HotPot forum.

• Moodle Forums: HotPot (plugin)
• Moodle Tracker: Plugins HotPot

How can community members help with further development of the module?

The main way that community members can help with future development of this module is to subscribe to the HotPot module forum and join in the discussions there. Previous discussions on that forum have yielded new ways to use the module, new stylesheets and output formats, proposals for new features, and of course the camaraderie and community spirit that you would expect when like-minded people meet to discuss teaching and learning with Moodle.

If you were starting now from scratch, what would you do differently in HotPot?

I am tempted to say that if I were to write the HotPot module from scratch I would wait till Moodle 2.8 before I wrote a line of PHP code! However, that would be just be a light-hearted jest. Actually, I love Moodle 2.0 - 2.7, but I must admit that the constantly evolving Moodle API’s have caught me out on more than one occasion, and they will probably continue to do so. More seriously, I think that if I wrote HotPot again from scratch, I would try to make more use of the question bank. In fact, I intend to investigate that possibility for Moodle 3.x.

Thanks a lot.

You’re welcome, and a big thank to everyone in the Moodle community, and in the Hot Potatoes community, for all the help and encouragement toward the development of the HotPot module for Moodle.

Community Educator point of view

We asked Moodle HQ’s Community Educator Mary Cooch for her review of the HotPot activity module from user’s perspective.

I made my first Hot Potatoes exercise around ten years ago, having heard about it from other languages teachers. Apart from its intriguing name (Hot Potatoes from Half-Baked software) it appealed to me because of its simplicity and versatility. I became an official Hot Potatoes trainer and started to show teachers how they could use them on their shiny new interactive whiteboards. Then in 2006 when I discovered Moodle, I realised that with the HotPot module, any teacher could easily add their exercises to a course for students to work through and get useful,instant feedback. When I saw those scores automatically stored in the gradebook -it was a revelation which became a revolution in my own teaching!

The main attraction of this plugin is the ease with which non-technical teachers can create and upload a variety of activities which can include links, image, sound and video. HotPotatoes is freeware, and the exercises are created offline - which again some users find a bonus, as they can do this at their leisure, thinking through the questions. That said, I once did a live demonstration of how you can create a Hot Potatoes exercise and upload it to your Moodle in under three minutes - microwave style for busy educators! Creating multiple choice quizzes is fairly self-explanatory, and the saving and upload process is very straightforward, no complex “convert to SCORM” requirements that some commercial products require.

With the Hot Pot plugin, you can add exercises such as drag and drop matching, crosswords, jumbled up sentences, but it is especially good for gap-fill activities. Moodle’s built in Quiz is extremely powerful, but if you want to do a “fill in the blanks” exercise, there is quite a steep learning curve. I will often recommend to nervous new Moodlers that they add their Cloze tests with Hot Potatoes and the Hot Pot plugin rather than (at least initially) struggling with Moodle’s Embedded answer Cloze alternative.

Engaging exercises are very simple to make, and the Hot Pot plugin provides teachers and their managers with valuable reports and statistical trends. For those reasons it’s clear why HotPot is one of the most popular contributed modules and our first Featured Plugin.

HotPot in a developer’s eye

The HotPot module code has all signs of a mature and well maintained Moodle plugin. The code follows the Moodle coding guidelines and is readable. There are all expected files provided for the given plugin type. Files contain the standard boilerplate with the license (GNU GPL v3 or compatible) and authorship declared. Function and class names have valid prefix and the classes use valid namespace to prevent eventual collisions with other additional plugins and/or Moodle core APIs.

The module declares set of reasonable capabilities and uses them for access control. As most of other plugins, HotPot still uses legacy logging API but work has already started on supporting the new events/logging frameworks (with the course_module_viewed event). The installation and uninstallation scripts are provided, as well as the upgrade script allowing to upgrade the module even from old 1.x installations. Database tables owned by the plugin use correct name prefix. Some foreign keys are explicitly defined.

The CSS styles use correct selectors so the plugin’s styles do not affect other areas of Moodle when the styles.php file is concatenated with other plugins’ files.

Gordon makes use of subplugins in his module (see db/subplugins.php). There are three types of subplugins declared - hotpotsource (provides support for alternative sources of HotPot quizes), hotpotattempt (controlling the output format for various HotPot types) and hotpotreport (providing various reports such as statistical analysis or click trail report). Subplugins allow to extend the functionality of the plugin in a clean and well defined way. Relevant plugininfo classes are implemented for all three subplugin types (see classes/plugininfo/*.php) so they can be uninstalled via standard administration UI.

For historical reasons, the HotPot still stores its settings into the main configuration table - luckily with setting names correctly prefixed such as $CFG->hotpot_maxeventlength.

$setting = new admin_setting_configtext('hotpot_maxeventlength', … );

To prevent the $CFG bloat, plugins are recommended to have settings stored in the config_plugins table instead and access it via get_config(). The settings.php would then contain setting names like

$setting = new admin_setting_configtext('hotpot/maxeventlength', … ); // note the slash

The HotPot module itself as well as all subplugins that are part of the module pack have their English strings correctly defined in the language pack files and are available for translation at lang.moodle.org.

Script parameters coming from the user have their PARAM type defined and are obtained via expected input processing functions. The module correctly uses the $DB API to manipulate data in the database. The sesskey value should probably be checked at more places in the code.

The most of the included Javascript code is pretty native and does not seem to use a JS framework library (such as YUI or jQuery) much.

As an interesting pattern in the code, I would like to highlight the way how Gordon deals with evolving Moodle core APIs. Thin wrappers such as

function hotpot_add_to_log($courseid, $module, $action, $url='', $info='', $cm=0, $user=0) {
    if (function_exists('get_log_manager')) {
        $manager = get_log_manager();
        $manager->legacy_add_to_log($courseid, $module, $action, $url, $info, $cm, $user);
    } else if (function_exists('add_to_log')) {
        add_to_log($courseid, $module, $action, $url, $info, $cm, $user);
    }
}

allow him to maintain one branch for a wide range of Moodle versions. While I personally prefer maintaining the code on branches tightly bound to a particular Moodle version, I fully respect this as a valid approach.

Suggestions for the maintainer

• I would suggest to consider rewriting the included Javascript code into proper YUI modules and profit from the cross-browser compatible functionality this framework offers - such as executing AJAX calls or DOM manipulation.
• I recommend to improve the plugin record in the Plugins directory a bit, namely to add some nice illustrative screenshots and explicit URL where bugs and feature requests can be reported.

I believe the HotPot is a nice proof of the fact that plugins do not need to be necessarily included in the Moodle core to be well maintained. It's the person behind the plugin who makes it reliable. I wish Gordon good luck with future development of the plugin and I'm happy to give it the Featured plugin award in our Plugins directory.

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.

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.

David,

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.

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 http://docs.moodle.org/dev/Plugin_validation.

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.

David

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

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.

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).

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 moodle.org 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.