David Mudrak's blog

Latest stable version 1.9.9+

There are 17 commits into the stable branch from the last development week. Tim Hunt fixed problem with deleting quiz attempts, occurring in quizzes in group mode with a group currently selected (MDL-22847) and two other issues in quiz. Dan Marsden and Piers Harding backported a series of patches from Moodle 2.0. That patches fix various issues in SCORM module (MDL-22332, MDL-22340, MDL-22168, MDL-21333, MDL-17891, MDL-21551, MDL-22741, MDL-21492, MDL-21761, MDL-12834 and MDL-21306).

Future version Moodle 2.0 Preview 3

There were 159 commits into the main development branch in the last week. Microsoft contributed native SQL*Server adapter for their new SQL Server PHP driver (sqlsrv). PHP extension XML-RPC become required for Moodle 2.0 and the prerequisite was set in admin/environment.xml. Moodle uses XML-RPC extension for hub communication, web services and Moodle networking (MNet). There are already first reports from the community that this will be issue with some cheaper web hosting providers and even some core developers are not quite sure about this step, so the decision may not be final yet. On the other hand, Moodle is not trivial application and one should not expect it runs just everywhere (just because of memory requirements, at least).

Quotes of the week

“Loan calculator 2.0! Now with extra mortgage sales! Order now and get 2 licenses of Moodle 2.0 for free.”
– David Mudrak can’t believe the Loan calculator block still survives in standard Moodle distribution

“Eventually there will be unicorns and rainbows and everyone gets a pony.”
– Sam Marshall dreaming about the future when developers would be happy with how Internet Explorer renders Moodle 2.0 pages

Cleaning user input

Sanitizing data inserted by users is a must. Without proper cleaning, data submitted by users could break database integrity or contain SQL injection (and it is not just about hackers, parents are malicious, too). In Moodle, there are two basic functions that every developer MUST use before processing user input. These are required_param() or optional_param(). They both use clean_param() to make sure that the script does not get unwanted values. Developer declares what type the parameter is – for example PARAM_INT for integers, PARAM_BOOL for booleans, PARAM_FILE for safe file name etc. See the top of lib/moodlelib.php for the comprehensive list of them.
In most of cases, clean_param() just uses regular expressions to get rid of invalid characters. Sometimes it returns the original value without the dangerous parts (as in PARAM_ALPHANUM, for example) and sometimes it returns empty value if the parameter does not fit the conditions (as in PARAM_URL that either returns the original value if it is ok, or nothing).
In some cases, just formal syntax check is not enough. For example PARAM_LANG not only checks that the provided value is safe name of the language pack directory (by checking it against PARAM_SAFEDIR internally) but also checks that the given language is actually installed at the site. The same applies to PARAM_CAPABILITY, PARAM_AUTH or PARAM_THEME. As I realized recently (thanks to one of quite frequent discussions with Petr Å koda), this sort of checks must be implemented with extra care and security risks analysis. If clean_param() calls other core functions, we must know exactly what is happening with the value itself during its clean-up, especially when we rely on 3rd party libraries. The point is that parameters are usually checked before the script calls require_login() so that we do not know much about the current user’s rights yet. Therefore, parameter handling functions are potential doors into Moodle core system for anonymous users. Simple checks based on formal syntax rules are generally safer as they keep the request “ante portas” and additional validation can be done later during the script execution, for example when we already know who the user is, what capabilities she/he has, if the combination of all parameters is valid (like the submission, assessment, course module and the course must match).

Post scriptum

Moodle 2.0 translation portal http://lang.moodle.org is up and running in production mode now, language pack maintainers can start translate Moodle 2.0 now. Thank you all for being patient.

Latest stable version 1.9.9+

There are 5 trivial commits into the stable branch from the last development week (from Tuesday Jun 15 to Monday Jun 21). David Mudrák (also known as “I” in this blog ) fixed coding error producing PHP notice and improved a check of user context existence in the list of users (c36671d). Helen Foster fixed spelling typo in a Quiz help file, spotted by Stuart Mealor (MDL-22842). Tim Hunt fixed several broken $Id$ CVS tags.

Future version Moodle 2.0 Preview 3

There are 69 commits into the main development branch from the last week. The highlighted one for this week is Sam Hemelryk’s one which adds a new element – colour picker – available for administrator config screens (MDL-22806).

Quotes of the week

“Gentlemen, we have reached a milestone. The download is exactly 1,000,000 bytes. Now we have to get it in the right order.”
– Martin Dougiamas knows the secret of sofware engineering

“We do not need any new API for fetching of course record – we have DML with MUST_EXIST flag which is the right way now; we should not include course/lib.php on each page anyway.”
– Petr Å koda removed get_course_by_id(), get_course_by_idnumber() and get_course_by_shortname() from course/lib.php

Good morning, students, and welcome to the course

On Monday, Petr Å koda committed the enrolments patch he was working on recently. The patch is quite huge – it touches 225 files, removes 7603 lines of code and inserts 11019 lines. You can see the changes nicely at github. This patch was one of the last significant things to be included in Moodle 2.0 release so let us have a closer look at it.
Shortly said, the patch changes the enrolment implementation – that is where and how the information about the users participation in courses is kept. In old Moodle versions (up to 1.6) there used to be two database tables to hold the enrolment information – user_teachers and user_students. Each of these two tables represented a relationship with M:N cardinality between the table user and the table course, with some additional information (the start and end date of the enrolment etc). When Roles and capabilities were introduced in Moodle 1.7, these tables were dropped and the capability moodle/course:view started to control if the user is allowed to participate in the course.
Subsequently, it become clear that the implementation based purely on capabilities is not enough in some real scenarios.

• There is a conceptual difference between “view the course” and “be seen as a course participant”. For example, you want to let school Inspectors to enter the course but nobody should be able to know about them. Therefore, hidden role assignments had to be introduced.
• With the capability, it is pretty difficult – but not impossible – to manually order teachers names at the course information page (you know – all teachers in the course are equal, but some of them are more equal than others).
• Many enrolment related information are kept in the course table and therefore must be shared by all enrolment plugins – for example the start/end dates of the enrolment availability, course cost, enrolment key etc.
• Enrolments are not manageable with system-level groups of users.
• Moodle should support common tasks like enrolling students in advance (so that the administrator can prepare the winter term enrolments during the summer), the enrolment can be temporarily disabled for the student or students should be given read-only access to the course after it has finished. These things are kind of doable in Moodle 1.x, though one could expect quite cleaner and more straight procedures from LMS.

Petr tried to deal with these and many other issues by re-designing the internal enrolment system. In fact, Moodle 2.0 did a small step back to pre-1.7 enrolment ages and now there is again a table to hold the list of all course participants – user_enrolments. This table holds the list of all users that participate in a given course – that is they should be listed as course participants (in most cases, these are good old teachers and students). The enrolment record has its state flag – at the moment it can be ENROL_USER_ACTIVE or ENROL_USER_SUSPENDED. See is_enrolled() function for details.
It must be said that the enrolment itself does not give the user any other privilege but to open the course home page. To submit assignments, post into forums or take a quiz, the user must have appropriate role assigned. Both edge cases are valid – enrolled user without any role (for example a student who finished the course or the learner with outdated subscription) and a user with a permission to visit the course without being considered as enrolled (for example the school headmaster or an inspector from the Minitrue). From the UI perspective, the users from user_enrolments table are called Participants or Enrolled users. The users without the record in the table who have the capability moodle/course:view (typically administrators, managers, inspectors etc) are called Other users.
Yet another big change is that enrolment plugins (that is manual enrolment, LDAP based enrolment, External database, PayPal etc.) now have instances in all courses they are used. All instances of enrolment plugins are registered in the table enrol. This table now contains columns that used to be in the table course. Therefore, every enrolment plugin instance can have its own configuration – like enrolment key, dates, expiry notification settings etc. The database table user_enrolments links the given user with the enrolment plugin instance (which in turn is linked with a course). Every instance is allowed to modify just own data – this helps to prevent situations like when a teacher manually unenrolled a student who was enrolled by an external system and the student got enrolled again during the next synchronisation. This is not allowed any more – one plugin can not modify data of an other one.
From the developer point of view, it is nice that you can get course participants again at SQL level (this was not possible before due to complex permissions algebra). This may rapidly increase the performance of some parts of Moodle.

Post scriptum

My lovely wife won a motor scooter in SMS contest! I may become 50 km/hour pirate of the roads. Yahgrr!

Latest stable version 1.9.9+

There were 5 commits into the stable branch in the last development week (from Tuesday Jun 8 to Monday Jun 14). Martin Dougiamas bumped the version to 1.9.9 and fixed a potential memory overflow problem occurring during the activity import when a teacher is enrolled in many courses (MDL-19880). This fix caused a regression, spotted and patched by Alan Trick and committed by Eloy Lafuente (MDL-22740). Tim Hunt committed patch provided by Vadim Dvorovenko, fixing a typo causing breakage of the questions restore process (MDL-22720). Gordon Bateson committed a patch submitted by Ramon Eixarch, fixing questions import problem in case of Hotpot format JMatch and JMix (MDL-22726).
Security announcements for Moodle 1.9.9 were published yesterday at our MSA page. Moodle 1.9.9 fixes four security problems, two of them are considered critical and one of them major. Registered administrators were notified and encouraged to upgrade their sites before the detailed description of these issues was published, see Moodle security procedures for details.

Future version Moodle 2.0 Preview 3

There were 76 commits into the main development branch during the last week. Repository plugins mahara and remotemoodle were moved from standard distribution into contrib.

Quotes of the week

“Oh dear I’m a geek. New neighbours move into the next flat while their extension’s built. How do I welcome them? Let them connect to my wifi”
– Tim Hunt

“Only people that truly hate PHP can program something with it. The others who love it are not programmers ”
– Petr Å koda

Latest stable version 1.9.8+

There are 7 commits into the stable branch from the last development week. Most of them are just final cherries before the upcoming 1.9.9 release. Sam Hemelryk patched HTMLPurify library so that it does not normalise line breaks into \n. It seems that some text comparison checks are broken due to this operation done by PARAM_TEXT or PARAM_CLEAN (MDL-22654). I have committed Tim Lock’s patch that fixes SQL error in the Recent activity block caused by Workshop 1.x code at recent PostgreSQL servers (MDL-22448). Petr Å koda fixed a critical bug in setnew_password_and_mail() function, spotted by Tim Hunt. The function did not salt the password with hash_internal_user_password() when it was storing the newly generated one into the database.

Future version Moodle 2.0 Preview 3

There are 77 commits into the main development branch from the last week. We are tuning the code for the beta release. To highlight one issue for this week, Dongsheng Cai is converting all remaining legacy file upload forms into the new File+Repository APIs (MDL-22574), including bulk user imports, outcomes import, questions import etc.

Quotes of the week

“Writing proper documentation is part of the development task. Just throwing random code into CVS then abandoning it is not good enough. Particularly with a core library. The work is not finished until there are full PHPdoc comments, and an overview on Moodle Docs in my opinion.”
– Tim Hunt discussing File API with Petr Å koda

“At least the file code seems to work, it is better than long spec with tons of docs and rubbish code that can not work ”
– Petr Å koda discussing File API with Tim Hunt

Do not include JavaScript too early

In Moodle 2.0 there is a new framework for including JavaScript code. Thanks to a bug reported by Miquel Escarrà (MDL-22651), I have realized kind of malicious aspect of the system. If developers requires a JavaScript module for page in a course context, they must do so after the current $PAGE was informed about the course. During the initial script setup, global variable $COURSE is set to the site course (front page) by default and it is re-set to the current course later, typically by calling require_login() which in turn calls $PAGE->set_course(). During the JS module registration, all needed strings are fetched by string_for_js() method of page_requirements_manager (accessed via magical $PAGE->requires). The problem is that the course may have set a forced language which overrides the currently selected language in the session. Therefore, if JS module is registered too early (before the $PAGE knowns the forced language), the strings are different than they should be: they are obtained from the language pack set in the current session and not from the language forced by the course. If the same string is fetched again (by another module, for example) later during the PHP script execution, when the forced language is already known, string_for_js() throws coding exception. Which is good because we want to know we did something wrong.
This sort of bugs are quite difficult to reproduce as they emerge in a very specific situation and environment. In this case, it helped that the reporter provided detailed description of his steps leading to the error.

Post scriptum

I am looking forward the Czech MoodleMoot 2010 in Brno later this week. @mootcz10 #mootcz10

Latest stable version 1.9.8+

There are 4 commits into the stable branch from the last week. I added an empty string ‘parentlanguage’ into English langconfig, because as a general rule, every string must be defined in English pack first (MDL-22575). The fact that parentlanguage was not defined required hard coded exceptions in the new translation system. And I do not like exceptions. However, this change introduced a regression – language import utility tried to fetch the parent language for English. Fortunately Eloy spotted and fixed it promptly (MDL-22585). Yet another regression, caused by the recent patch in the Assignment module, was fixed by Petr Å koda (MDL-22181).

Future version Moodle 2.0 Preview 3

There are 160 commits into the main development branch from the last development week. On Monday, the branch was tagged as Preview 3. Sam Hemelryk rewrote the blocks docking mechanism significantly (MDL-22560). In the new version, there is now better support for themes. The performance was improved. Docking mechanism is not completely based on YUI3.

Quotes of the week

“2.0 is getting fun to use now. Just need the last 90% of effort to finish the remaining 10% features.”
– Martin Dougiamas

Post scriptum

My Linux machine uses two-state logic. Either it rocks, or it sucks.

Latest stable version 1.9.8+

There are 4 commits into the stable branch from the last development week. Sam Marshall fixed an accessibility issue, preventing IE users from navigating the page with keyboard (MDL-22518). Martin Dougiamas fixed the cases when getremoteaddr() returned NULL because the script was executed via CLI. The empty value violated the non-null constraint on lastip in user table and some scipts (for example LDAP authentication plugin) could not create new user accounts (MDL-19628). Petr Å koda committed Ye Chen’s patch that fixes critical bug in get_users_by_capability(). The symptoms of the bug include “No users were found with permissions to submit this assignment” in case of an assignment in group mode. HTML purifier has been upgraded to the version 4.1 and is available as an experimental feature for PHP5 servers.

Future version Moodle 2.0 Preview 2

There are 281 commits into the future release branch from the last week. Among many other improvements, the function get_string() now uses on disk cache to store the result of merging of standard language pack with the local customization and parent languages. Included YUI libraries have been upgraded to 3.1.1 and 2.8.1. The rotation of the vertical text (also known as the book spin) can be configured via string “thisdirectionvertical” in langconfig.php.

Quotes of the week

“Tracker going down for restart, java needs it monthly kick in the ass”
– Jordan Tomkinson knows how to keep our servers up and running

“Going to commit patch which removes dirroot from config.php, yay!”
– Petr Å koda is always happy when he is cleaning up Moodle source code

New Moodle development books

I like IT books and have dozen or two of them on the shelf in the office. I usually do not read most of them, though. Especially those just copying online documentation and manual pages. It is quite interesting trend that computer books have usually hundreds of pages while the real added valuable information could be compressed to five of ten pages of text. But the shelf full of thick computer books gives an impression that the guy really knows what he is talking about when asking you to turn it off and on again
Given that, I appreciate books that offer more than you can find online in API documentation. And I guess the new book on Moodle 1.9 development by Mike Churchward and Jonathan Moore from Remote Learner (U.S. and Canada Moodle Partner) can be the case. It was released by Packt Publishing together with yet another one by Paul James Gadsdon, dealing with Moodle custom themes development.
I have ordered both of them and am looking forward to see how they are written. According the sample chapters available, they look as promising guides and tutorials on the subject. Shall be noted that by buying Moodle books, you help support Moodle development as a percentage of all sales goes to the Moodle Trust.

Latest stable version 1.9.8+

There are 4 commits into the stable branch from the last development week. Tim Hunt fixed a wrong capability checking in Quiz module (MDL-22410) and several regressions in clean_param(), introduced when we were converting ereg to preg, because ereg functions are deprecated in PHP 5.3 (MDL-19418).
Martin Dougiamas committed a bunch of patches that kills the scripts expected to be included only, if they are called directly via URL (MDL-22388). During the initial setup of every script life time, Moodle core defines constant MOODLE_INTERNAL which shall be used to make sure that the script is included and not called directly (constants can’t be defined via URL even with bloody register_globals on). This trick helps to prevent libraries, forms definitions and other scripts from potential security holes. My mom told me not to talk to strangers so I personally prefer silent one-line check

defined('MOODLE_INTERNAL') || die();

instead of explaining the poor hacker that the direct access to the script is forbidden (Mahara uses this shorter form and I just like it).
Gordon Bateson found a way how to deal with an XHTML issue in Hotpot by using IFRAME instead of OBJECT for Internet Explorer, as HTML forms are not able to escape OBJECT in this browser.

Future version Moodle 2.0 Preview 2

There are 141 commits into the future release branch from the last week. It is now tagged as Preview 2. Since Preview 1, there are many improvements and bug fixes. Many thanks to all who help us with testing.

Quotes of the week

“Ha, some song just came on my radio station by a band called CSS. The song is called CSS Suxxx. Just when I was swearing at css”
– Martin Dougiamas experiences reaffirmation from the world

Watch your back!

Backup and restore support used to be my not very favourite part of Moodle modules coding. I was kind of scared (and bored) by all those direct fwrite() calls to generate XML representation of the module data. With the new backup/restore framework, written by Eloy Lafuente, this is not true any more! Eloy has prepared really well designed system that deals with a lot of tasks automatically, yet in a flexible way. Following his tutorial on backup support for Moodle 2.0 activity modules, I was able to quickly hack a working prototype of Workshop backups.
What I like the most so far is the way how module just defines a description of its database structure and lets the core to actually fetch the data a convert them into XML representation. Given the necessary amount of information, new backup system is able to “automagically” handle all relations, references to other tables and including embedded files (only those really needed by the module, of course!).
There are still parts to finish both in Moodle core and in modules – most notably the ability to backup subplugins information and to restore 1.9 backups. But I can sleep well again as backup and restore is not nightmare any more for module developers.

Post scriptum

After more than eight years, one of the characteristic symbols of Moodle, the default user icon (yes, that very well known smiley cake), was replaced by a bland avatar for the standard theme in Moodle 2.0. That is ironic that the smiley actually replaced the original “shadowhead with something a bit more positive”. The story of the “f1.jpg” image and how it resisted various attempts to replace it is sometimes quite interesting. Anyway, I will miss it… So long!

Latest stable version 1.9.8+

There are 4 commits into the stable branch from the last development week. Dan Marsden fixed a bug in SCORM backup/restore (MDL-22301) and yet another one which was caused by not using absolute file paths when including a PHP file (MDL-22340). In Moodle, the best way to include other files (typically libraries or forms definitions) is to include the main config.php via dirname(__FILE__) and then include all other files needed via their full path, using $CFG->dirroot or $CFG->libdir.
Eloy Lafuente updated the timezones database shipped with Moodle to version tzdata2010i (MDL-18576). This database contains information about the world’s time zones and daylight saving time and helps our in-built calendar to calculate correct dates and times for users from all around the world. Moodle uses so called Olson database, a public-domain collaborative compilation of timezones data, currently maintained by Paul Eggert.
Pierre Pichet committed a patch fixing buggy behaviour of calculated question type on duplicate (save as new question).

Future version Moodle 2.0 Preview 1

There are 158 commits into the future release branch from the last week. On Thursday, Martin Dougiamas announced the release of Moodle 2.0 Preview 1 version, the first milestone on about 10 weeks long track to reach final Moodle 2.0. See the preview release notes for more information.

Quotes of the week

“It is a good idea, so I put it in the tracker. The point of the tracker is that it remembers things, so we can forget about them.”
– Tim Hunt on tracker.moodle.org

“I’m really looking forward to 2.1 and working on modules again.”
– Martin Dougiamas knows that many of improvements in 2.0 lie in the dark deep of Moodle architecture internals and are never to be actually seen by users

Installing Moodle from the command line

I love Linux for many reasons and not only because it is free as in being free after drinking beer. Since the first days with Linux, I’ve been impressed by the power of command line utilities, following the Unix philosophy of doing just one thing, doing it well and cooperating with other small programs. From version 2.0, Moodle supports installation and upgrades from the command line. Of course I was happy I could spend some time on improving these routines a bit.
CLI programs for common administration tasks (installation, upgrade, switching the maintenance mode and resetting a forgotten user password are supported at the moment) can be found in admin/cli/ directory of standard Moodle 2.0 source code. You should run them as the same user as is used for the webserver process (apache or wwwrun are used usually).
This is an example of how I installed a fresh Moodle 2.0 at my notebook today:

$ php admin/cli/install.php --lang=en
--wwwroot=http://localhost/moodle20
--dataroot=/var/www/moodledata/moodle20
--dbname=moodle20 --dbuser=apache
--dbpass=xxxxxx --dbsocket

In this example, the script runs in an interactive mode, asking for all needed data and using the provided ones as default. There is also a possibility to execute the script in non-interactive mode, providing all required information as CLI parameters. Such an option may be interesting for hosting providers as it allows to automate the process of creating a new Moodle site.

Post scriptum

http://www.projectcartoon.com/cartoon/1

Latest stable version 1.9.8+

There are 10 commits into the stable branch from the last week. Half of them, committed by Dan Marsden, deal with various SCORM issues (MDL-22168, MDL-22046, MDL-21568, MDL-18202, MDL-21444). Tim Hunt fixed three Quiz issues (MDL-22241, MDL-20586, MDL-22257). Thanks to Gordon Bateson, Hotpot module now uses HTML OBJECT tag instead of IFRAME, due to XHTML 1.0 strict compatibility (MDL-17702).

Unstable development version 2.0dev

Total of 294 commits found their way into the future version branch last week. Several various subsystems and major patches were included – for example the new My home page, Moodle Hubs support and many others. Petr Å koda’s recent patch, that reimplements the whole enrolment subsystem and changes some of the key concepts of roles and their assignments, is still being reviewed in a separate branch. Martin Dougiamas is going to announce the release of Moodle 2.0 – Preview 1 version, just working on the release notes yet.

Quotes of the week

“Users will remember for almost forever a bad/broken release; but will quickly forget that a stable/fine/working release was a year late.”
– Greg Mushial summarizes his experience from 40+ years involved in software development

“Beta version software is likely to be useful for internal demonstrations and previews to select customers. Some developers refer to this stage as a preview, a prototype, a technical preview (TP) or as an early access.”
– Wikipedia, Software release life cycle

Help tooltips in Moodle 2.0

Among many other (and definitely more significant and more important) improvements in Moodle 2.0, there is a new way how the help tooltips are handled. From the users’ point of view, help is still available via those question mark icons. Instead of opening a pop-up window in the browser, Moodle 2.0 uses YUI3 overlay to display a “bubble” with the help text. The behaviour of the tooltip had been a subject of a discussion (MDL-22067) and at the end, it was decided to follow the functionality found in Mahara or Github.

From the developer’s point of view, help texts are not stored in separate files any more. In the dark past, help files used to play a role of inline help, documentation, manuals or even tutorials on using Moodle. Nowadays, with Moodle Documentation portal being actively growing thanks the community contributions, we are trying to revert helps to what they are supposed to be – useful hints on various user interface elements, their meaning and usage. Therefore, the help files are being migrated into proper Moodle strings in 2.0.

For every help, two strings must be defined. One for the label of the thing the help is describing. In the forms, this is the label of the input element in almost all cases. The second string is the help text itself. The identifier of the second string must be the same as the identifier of the first one, just with “_help” suffix, for example:

$string['subject'] = 'Subject';
$string['subject_help'] = 'Message subject will be used as a title at the message view page.';

Let us say we want to add such help in a Moodle form, for ‘msgsubject’ input field. You would probably have a code like:

$mform->addElement('text', 'msgsubject', get_string('subject', 'mymodule'));
$mform->addHelpButton('msgsubject', 'subject', 'mymodule');

That would use the string ‘subject’ defined in your ‘mymodule’ language file as a title of the help and the string ‘subject_help’ defined in the same file as the help text. To get the same result in Moodle 1.9, you would have the help defined in a HTML file, let us say help/messagesubject.html a the code in the form would look like:

$mform->setHelpButton('msgsubject', array('messagesubject', get_string('subject', 'mymodule'), 'mymodule');

To display a standalone help icon anywhere at your page, use help_icon() method of the core renderer instance:

echo $OUTPUT->help_icon('subject', 'mymodule');

Help strings can use Markdown syntax for basic HTML formatting. We use that just for producing bullet list from the lines starting with asterisk.

To give the translators something to start with instead of rewriting all help strings from scratch, we are copying the contents of the translated help files into new help strings wherever it is possible.

Post scriptum

I can’t think of anything to write here today

Latest stable version 1.9.8+

There were 12 patches committed into to the stable branch during the last development week. Helen Foster once again reworded the help describing the behaviour of a recently added  gradebook feature as Elena Ivanova suggested (MDL-21218). Pasi Häkkinen discovered a malicious incorrect usage of HTML entity that led to Flash version detection being done by AJAX call at every page load instead of once per session and Petr Å koda promptly committed Pasi’s patch (MDL-22154). Dan Marsden backported Vlas Voloshin’s patch fixing the display format of exhibit time periods in SCORM 2004 packages (MDL-18835) and fixed yet another issue with First Access and Last Access dates in SCOs (MDL-16184, MDL-21423). Sam Marshall fixed a bug producing empty links when there was no group picture. Such empty links created an invisible tabstop which is confusing for screenreader and other keyboard users (MDL-22174). Tim Hunt backported some parts of unit test failure display improvements (MDL-22174). Eloy Lafuente fixed a bug in backup/restore machinery so the manually added links to the course main page are transformed into new URL, reported and tested by Larry Elchuck (MDL-22176). Petr Å koda committed a patch provided by Gordon Bridge. That fixed a bug in the Assignment module which overwrote the grade item identifier in the Gradebook with a number (column “id” of the Assignment module instance in course_modules) instead of the value defined for the activity in modedit form (column “idnumber” in that table). This critical bug had been reported before but could not be reproduced until Gordon described it in details and found the nasty line (MDL-22181).

Unstable development version 2.0dev

There are 141 commits into the main development branch last week. To highlight one, Eloy Lafuente merged first parts of the new backup/restore backend he was working on in a separate git repository recently. Sam Hemelryk is going to work on the backup/restore user interface. As many other parts of Moodle 2.0, backup/restore subsystem will be fully implemented during the beta period (which starts in six days!). The last huge  change that is going to land before the feature freeze next week is Petr Å koda’s new baby – the reimplementation of enrolment plugins. After that, Moodle 2.0 APIs and database structures should be considered more or less stabilised and the team will focus on fixing the regressions only.

Quotes of the week

“That github interface is very nice”
– Martin Dougiamas after reviewing a patchset before it was committed into the main CVS repository

“Would be nice if core developers actually tried to run the code before they commit it into the repository.”
– David Mudrak gives a hint on how to prevent the most obvious bugs

“Whoa, that was quick!”
– Pasi Häkkinen found his bug fixed in 57 minutes after it had been reported

I am, YUI

All modern web applications use advanced JavaScript based techniques to increase the usability of the user interface. Things like inline editing, re-populating the parts of the page via AJAX calls or saving the forms without reloading the whole page are quite common for users today. To ease the integration of JavaScript and skip fiddling about with its different implementation in various browsers and their versions, web projects use some JavaScript frameworks like jQuery, Dojo Toolkit or YUI. The latter one, Yahoo! User Interface library, has been chosen as the official JavaScript framework for Moodle since long time ago. Moodle 2.0 ships with the most recent version YUI 3.1.0 while still providing a way how to use some widgets from earlier 2.8.0 version.

Moodle core does a lot of work for you behind the scene with including YUI libraries and their dependencies in correct location of HTML produced by your code. The most straightforward way to include JavaScript on your page is to define the code in the file module.js in your plugin directory. To avoid collisions of global variables and functions, all your code is supposed to be wrapped in a namespace. Since 2.0, we put all Moodle JavaScript code into a global M object and plugins are expected to use their own M.plugintype_pluginname namespace. For example if you write an activity module called foobar, all your JavaScript functions should be defined in M.mod_foobar namespace.

To include your code at the page and to initialize it from PHP, use $PAGE->requires->js_init_call(), providing the name of the initial JavaScript function as the first parameter. This initialization function must accept YUI instance object as the first parameter which we call Y, as is common in YUI 3. Once you have YUI instance, you can do whatever magic this library offers to you, including the possibility to load additional YUI modules with Y.use(). The ‘Hello world’ example of using YUI in Moodle 2.0 could look like this:

Let us say you are working on FooBar activity module. In your PHP script, for example /mod/foobar/view.php, add a line

$PAGE->requires->js_init_call('M.mod_foobar.init');

Then create the file /mod/foobar/module.js with the following contents

/**
 * @namespace
 */
M.mod_foobar = M.mod_foobar || {};

/**
 * This function is initialized from PHP
 *
 * @param {Object} Y YUI instance
 */
M.mod_foobar.init = function(Y) {
    alert('Hello world');
}

Or, instead of just displaying the alert, to modify the current HTML code (for example to add some elements via JavaScript or to remove some non-JS support code) just use

M.mod_foobar.init = function(Y) {
    Y.one('#mycustomholder').set('innerHTML', 'Hello world');
}

See YUI 3 documentation for more great examples. You may also find this blog post useful (I did, thanks Eloy for the link).

Post scriptum

I love xkcd.