Plugins traffic

Featured plugin July 2014: HotPot

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

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

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.

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.

David's note: HotPot would probably be the top downloaded plugin in our stats but there was an accidental data loss related to the 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 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 The zip file download from the plugins repository on is simply a copy of the zip file on

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.

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.

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

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.

Average of ratings: Useful (10)