David Mudrak's blog

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