Melbourne hackfest July 2015

Jump to: navigation, search

Developer meetings > Melbourne hackfest July 2015

When Thursday, July 9th, 2015 - 9.00am to 5.00pm
Where Robert Menzies Building, rooms W204 and W210, Monash University, Melbourne - as a part of MoodleMoot AU 2015
Hashtag #mootau15
Support Moodle Hackfest Melbourne 2015 course at and mootau15 devpad


Time slot Room A Room B
09:00 - 10:30 Contributing to Moodle development
Introduction to Moodle plugins development
Moodle developer's First aid station
11:00 - 12:30 Hacking group 1: Course Archiving and Roll-over Hacking group 2: Assessment Analytics
13:30 - 15:00 Unit and behaviour testing in Moodle: Introduction to PHPUnit and Behat Javascript modules in Moodle 2.9 and higher
15:30 - 17:00 "Show and talk" micro-sessions -

Contributing to Moodle development


Introduction session led by Marina Glancy, Moodle HQ's development process manager, was there for those new into Moodle development. Useful information and/or clarification for existing contributors was provided, too. A short overview of Moodle development practises, documentation, APIs, processes and tools discussed and demonstrated.

Relevant docs links:


  • To obtain the "Diff URL" value for your contribution hosted at your Github, use their button "New Pull Request". It does not immediately create a new pull request. Also note we have own process for contribution and we do not use the Github's pull requests.
  • For bug fixes, contributors are encouraged to provide patches for all supported versions. This is different process to that for security patches (which can't use public branches for obvious reasons).
  • For improvements or new features you only need to create a patch on master. Improvements are only integrated in the future versions but can be backported later (different process).
  • Q: Are there any guidelines / rules around when to create more than one commit within a tracker item? It seems that sometimes one request is integrated with multiple commits - is this ok?
    • A: Yep. Generally one commit per logical change. So if your change involves two significantly different things to solve one issue, two commits is good. In a lot of cases one commit is fine.
  • Q: Is there a better way to 'undo' your changes if you need to modify your commit than git reset HEAD^ ?
    • A: If you want to change your commit, just edit files, git add and then do git commit --amend. Then that commit will be modified - Excellent! Thanks.
    • A: google for command "git rebase -i", it allows you to do all the crazy stuff with commits - change sequence, squash, etc. Love it! --Marina
  • Q: Can you recommend the best toolset/IDEs to assist rapid faster code development/debugging? e.g. Eclipse/etc.? (Preferrably cross-platform, and free :D)
    • A: Sublime is quite nice and easy to use. is a good free alternative. A lot of people at HQ use phpstorm. Rapid development & debugging is more to do with how much you learn than what tool you use :)
  • Q: Are there any MOODLE core release versions where upgrading (e.g. db schema) features break/are particularly problematic? (Or is that a stupid question?)
    • A: 1.9 to 2.0? ;) We try to make the upgrades between each version as smooth an easy as possible.
    • Yep, thought as much, just aware of the vast version differences between 2.0->2.9
    • Always look at lib/upgrade.txt and the upgrade.txt files in your plugin folder, for example mod/upgrade.txt , blocks/upgrade.txt , themes/upgrade.txt , etc. They list API changes and other things that may affect upgrade
    • Great tip (above)
    • Moodle 2.6 has lots of API changes and deprecations, especially contexts

Introduction to Moodle plugins development

Overview of plugin types and common files and structures found in all plugin types provided. Contributing into the Moodle plugins directory. Guidelines and checklists. Led by David Mudrák.

Relevant docs links:


Course archiving and roll-over


Notes from the working group


Topic: Read-only/frozen courses

  • A new field in the context table - read-only per context, not propagated implicitly. The propagation should happen via the UI when setting the flag, but the computation logic should be context-level (performance).
  • Need to freeze the gradebook, too.
  • It will help us to discover existing bugs in caps definitions and usage (e.g. a capability declared as type of "read" while in fact it is not)
  • Idea/Suggestion: Where a course is "frozen" (read-only) allow "students with extensions" to have an "Student (Extended Period)" role to continue to submit?
    • A: Well, if there is a capability like "ignore R/O freeze flag" then yes, I guess
  • WRT the suggestion to use VM frozen site that links to live file dir - how would this be impacted by folks deleting/altering live files?
    • There's a config setting to prevent deletion of unused files from the filesystem, which was suggested to be used here; as files are stored based on content hash, no deletion means they'll always be the same
  • Backup/restore is not sufficient for true archival - it's more of an export/import, lots of data not copied etc; maybe 70% the same, still the potential for differences between original and "copy". Better to think of it like Export / Import that a real "backup"

Topic: Relative Course Module Creation Dates

  • Can we have some kind of report of all dates in the course, with ability to adjust them; overlay on site and/or personal calendar, so issues such as public/university/school holidays can be factored in?

Implementation idea:

  • Add a "relativecreationstr" field to course modules / activities
  • Use PHP strtotime() or some other "next thursday" or "+ three thursdays" (Provide syntax documentation link for users)
  • When a course is created from a source course (template/copy)
    • copy all the activities
    • update all the activities' start dates using: (a) the course start date, and (b) the relative period/interval/rule in the extra field (relativecreationstr)
    • set the activities start date (for all activities)
  • Use course creation date + interval to set the course module start dates
  • If a course start date is modified (course reset?) provide an option to "recalculate course modules using relativecreationstr

Topic: Rolling Personal Assessment Due Dates

  • Scenario: A MOODLE course has assessments (assignments, quizzes, etc.) and students are able to enrol at varying times, and the same course instance is used

for multple rolling cohorts (or individual students) where each student has - e.g. - 4 weeks since enrolment to submit quiz # 1.


  • Implement the activity relative date similar to above, but as a simple interval (an additional field?): e.g. "due_relative_start"
  • Allow activities to have a "due date relative to student's course enrolment date" flag / checkbox.
  • Then
    • Create a tables for core activity modules to maintain a link between a user's ID, the assignment ID, and the user'...
    • or add "due date calculation" logic into each core assignment modules, based on the flag in (2) to say:
      • If this activity is using "personalised enrolment due date" flag, then
      • calculate if the due date has passed for the student (if so, overdue, if not, student is able to submit)


  • Adding assessment/activities after student enrolment
  • Create table entries for students to set their activity due dates at activity creation?


Rather than adding new fields to all the tables, is there a way to have general core API usable by all plugins that would handle these dates calculation. With pluggable architecture allowing us for things like

  • Absolute date
  • Relative to a certain event date (course start, enrolment start date, course first access, ...)
  • Random date :-)

How many places are dates actually controlling state changes, i.e. workshop module states, assignment visible/open/due/closed? Can these be changed to use event-driven states (which could be date-based, relative to other things, etc - pluggable)? This would help with both rolling courses and relative dates, potentially

Assessment analytics



Priority 1: Allow students to indicate whether feedback was helpful

This suggestion proposes that students have the opportunity to rate the value of feedback they have been given.

  • No significant architectural problems were raised.
    • Feedback ratings can be recorded using a Feedback plugin, with students providing the input to that.
    • Some suggestions about where the ratings will appear.
    • Feedback rating could be a completion condition.
  • Several questions were asked by devs to be passed back to the working group.
Priority 2: A dashboard designed for students

This suggestion was to create a block for the Dashboard page to notify users when new feedback has been received and to temp them to go and view the feedback.

  • Some questions about efficiency were raised.
    • Should this be based on callback so multiple activities can contribute?
  • Several questions were asked by devs to be passed back to the working group.
Priority 3: Record whether students have viewed feedback and show feedback when marking subsequent assignments

Currently we do not track whether a student has viewed feedback provided to them. It is also difficult to find feedback for students' past submissions. It was suggested that we should track and indicate to teachers feedback has been viewed. When marking subsequent assignments, students' past feedback could be made visible so that a teacher can see whether the student has learned from the past feedback.

  • Discussion by devs about how to store this information.
    • General consensus was to store a value with the submission, but questions of whether this should be a count, a timestamp, a pair of timestamps (first and latest), or a series of timestamps.
    • A new event could also be triggered, but it would not be used when checking if students have viewed feedback.
  • Questions were raised about how far back feedback should be shown, whether it should be limited to the current course.
  • Some complications raised in relation to multiple attempts and capabilities.

Unit and behaviour testing in Moodle


Prerequisites for Behat

  • Selenium Server (standalone JAVA binary, which drives the FireFox or ChromeBrowser)
  • JavaJRE (to un the Selenium Server)
  • Firefox (or Chrome browser)
  • MOODLE code (2.9+ includes best behat content)
  • Apache/Nginx Webserver
  • PostgreSQL/MySQL database

For Ubuntu 14.04 (with Apache httpd and PostgreSQL)

1. Install Web Server, Database, Git

apt-get install openssh-server
apt-get install apache2 libapache2-mod-php5 php5-pgsql php5-intl php5-gd php5-xmlrpc
apt-get install git
apt-get install postgresql

2. Install Java Runtime Environment (JRE) for Selenium, and Firefox Browser (and Chromium Browser)

apt-get install default-jre
apt-get install firefox
apt-get install chromium-browser (onlt necessary if testing in Chromium)

3. Optional / Testing packages???

apt-get install phpunit-selenium (not necessary??)
apt-get install xterm

4. Download MOODLE core code (including behat files in MOODLE core), Create DATA folder

root@mootau15:/var/www/html# git clone git://
root@mootau15:/var/www/html# mv moodle moodle_behat
root@mootau15:/var/www/html# mkdir /var/www/moodledata_behat

5. Enable / Configure MOODLE config.php paths for Behat

root@mootau15:/var/www/html# vim moodle_behat/config.php

Add the variables, shown below configured:

root@mootau15:/var/www/html# grep behat config.php | grep -v '^//'
$CFG->behat_prefix = 'b_';
$CFG->behat_dataroot = '/var/www/moodledata_behat';
$CFG->behat_wwwroot = '[1]'; // must be different from wwwroot

6. Create a user and database:

root@mootau15:/var/www/html# su - postgres
postgres@mootau15:~$ psql
Cpsql (9.3.9)
Type "help" for help.
postgres=# CREATE ROLE moodle_behat WITH LOGIN UNENCRYPTED PASSWORD 'mypassword';
postgres=# CREATE DATABASE moodle_behat OWNER moodle_behat;

7. Download Selenium Standalone Server

root@mootau15:/var/www/html# wget [2] -O /var/www/selenium-server-2.46.0.jar

8. (If connecting with SSH/X11 remotely) Connect with X11 (e.g. MobaXterm so that x11 is forwarded back via SSH)

Set the DISPLAY variable to export X11 back to your display terminal:

root@mootau15:/var/www/html# export DISPLAY=<my ip address:0.0>

9. Start the Selenium Server in the background (on this terminal with DISPLAY set)

root@mootau15:/var/www/html# java -jar /var/www/selenium-server-2.46.0.jar &
[1] 19751
root@mootau15:/var/www/html# 14:19:00.158 INFO - Launching a standalone Selenium Server
14:19:00.199 INFO - Java: Oracle Corporation 24.79-b02
14:19:00.200 INFO - OS: Linux 3.13.0-24-generic amd64
14:19:00.222 INFO - v2.46.0, with Core v2.46.0. Built from revision 87c69e2
14:19:00.308 INFO - Driver provider registration is skipped:
registration capabilities Capabilities [{platform=WINDOWS, ensureCleanSession=true, browserName=internet explorer, version=}] does not match the current platform LINUX
14:19:00.309 INFO - Driver class not found:
14:19:00.309 INFO - Driver provider is not registered
14:19:00.379 INFO - RemoteWebDriver instances should connect to: [3]
14:19:00.379 INFO - Selenium Server is up and running

Note the change of folder!

root@mootau15:/var/www/html# cd moodle_behat

10. Initialize behat (inside MOODLE installation folder)

root@mootau15:/var/www/html/moodle_behat# php admin/tool/behat/cli/init.php

11. Run behat and start the test:

root@mootau15:/var/www/html/moodle_behat# vendor/bin/behat --config /var/www/moodledata_behat/behat/behat.yml
Moodle 3.0dev (Build: 20150702), pgsql, e5eefbbf0158318bea91ac7ab83c41671f594d69
Server OS "Linux", Browser: "firefox"
Started at 09-07-2015, 12:20

12. The Firefox browser should open and begin to run the test in front of your eyes!

Javascript modules and templates in Moodle 2.9


The example code used during the session: [4]

Example of checking out the branch into your existing installation (based on master):

cd ~/www/master
git checkout -b HACKFEST origin/master
git fetch [5] HACKFEST_AU15_START
git cherry-pick FETCH_HEAD

Other branches are HACKFEST_AU15_STEP2 and HACKFEST_AU15_FINAL



Show and tell


  • David Monllao - various vim plugins: [6]
    • [7] - a vim distribution with a bunch of plugins (including most/all david uses)
  • David Mudrak
    • autocomplete for password fields - booo browsers!
    • MDL-45772 - vote comment here - let's use a hidden field + JS and workaround the browser bug
  • Rajesh Taneja
    • Behat - browsermodproxy
    • recording a jmeter file and replay it - needs timing delays inserted
    • jmeter is popular - using a combination of manual jmeter scripts and generated scripts
    • needs a custom step to take the recorded jmeter file, and identify the variables so the script can be re-run without resetting the site
  • Morgan (UNSW)
    • Peer Assessment
    • Q: API for creating the evaluation form ? Question bank, Advance Grading)
  • Anonymous forums - Working notes
    • MDL-1071
    • Andrew Nicols interested in implementing this and trying to gather all use-cases
    • suggestion that we should not call it "Anonymous" - I've now renamed this to "User disguises"
    • Why restrict to forums? Proposal has scope to cover any context in Moodle