David Mudrak's blog

There were 53 patches submitted for integration this week; 10 of them were rejected, 43 survived both review and testing and got into the official repository. Regular weekly builds were released on Wednesday.
Today on Friday morning, Tomaz Lasic spotted a critical regression at School Demo Moodle site. Due to recent changes in modinfo library, Workshop module’s navigation stopped working completely, throwing coding exception because the new modinfo API was not backward compatible by mistake. This issue was promptly fixed by Sam Hemelryk and emergency weekly build of Moodle 2.0 was re-released.

Current stable version 2.0.1+

Total of 40 accepted pull requests affect Moodle 2.0 branch. ♦ Andrew Davis added new index to the table user_info_data consisting of userid and fieldid fields to increase performance when searching over custom user fields (MDL-17201). ♦ Dan Marsden fixed several SCORM module bugs and cleaned up its code. ♦ Dongsheng Cai fixed a bug in file picker. Internet Explorer was trying to download repository_ajax.php instead of executing it via AJAX request when users had .php files associated with an external editor. Dongsheng also fixed a bug in Wiki module’s upgrade code, dealing with wikis with the same title (some issues with Wiki upgrade seem to be still open – see comments in PULL-196 for details). ♦ Eloy Lafuente submitted a set of patches, mainly dealing with database access – wrong usages of get_text() and get_recordset_xxx() and using words reserved in Oracle as bind placeholders. ♦ John Stabinger fixed various issues in several Moodle 2.0 themes. ♦ Petr Å koda submitted a bulk of patches fixing many areas of the code. ♦ Rossiani Wijaya improved Multimedia plugins filter so that it now supports YouTube playlists (MDL-25573). ♦ Sam Hemelryk improved performance of the new navigation system (MDL-25291). The reporter Petr Å koda noticed that the new administration block is loaded for navigation purposes at almost every page even though most users (students) can not see anything in it. Sam implemented a new session flag to indicate whether there is actually something to load for the administration block. Not trying to load an empty block makes quite a noticeable performance difference in number of included files, RAM consumption and get_string() calls. ♦ Sam Marshall submitted another patch leading to the proposed improvements of get_fast_modinfo() function. ♦ Tim Hunt submitted three patchsets, all dealing with issues in Quiz module and Question bank.

Previous stable version 1.9.10+

Three accepted pull requests affect Moodle 1.9 branch. ♦ Andrew backported MDL-17201 discussed above. ♦ Dan Marsden backported a SCORM issue MDL-25320. ♦ Petr Å koda fixed a bug in an enrolment plugin – sites using IMS Enterprise file for enrolments should upgrade.

Quotes of the week

“Ooh duh – somebody actually documented it. I wasn’t expecting that ”
– Sam Marshall was lucky enough to find up-to-date information at a documentation page for developers

“git blame or blame git – that’s the question”
– Eloy Lafuente comments on Sam Hemelryk’s experience in MDL-25791

Performance matters, women say

Although Moodle developers focus on performance these days, not many performance related patches landed this week yet. And I can understand why. From my own experience, working on performance is pretty time consuming job requiring a lot of comparison tests on production data to get valid results. Luckily, Moodle 2.0 has inbuilt support for xhprof – a profiling tool written by Facebook developers. Large sites admins and Moodle developers can use this tool to compare how various tiny improvements save milliseconds of execution time and to analyse the complex function call graphs, identifying performance bottle necks.
From what we could see so far, the performance of the new navigation system (used at almost every page) and the recently improved filtering system (which makes major part of frequent format_text() function) should be our primary targets now. I started to study the current implementation of text filters and the mechanism of how they are chained, looking for places to improve. While reading the code, some important questions emerge that will need design decision soon.
One of them is a well known “nolink” feature. Moodle users know this as a button in HTML editor that is supposed to “prevent automatic linking” within the selected block of text. This feature was introduced back in 2003 as a part of glossary terms auto-linking feature. Later the feature was used by other parts of Moodle – activity names linking, database records linking etc. As all these automatic linking features are now implemented as standard filters, the concept became less clear. Is the text wrapped by “nolink” marks supposed to be processed by other filters that do not actually create links? Shouldn’t it be replaced with some “do not apply any filter on this block of text” feature?
Beside this conceptual question, there is an issue with the actual implementation of the feature, too. Originally, the part of the text where no automatic linking was supposed to happen had to be wrapped by <nolink> and </nolink> tags. Later as a part of transition to full XHTML support, these tags were replaced with valid <span class=”nolink”>…</span> pair. It works pretty well for short strings – typically glossary terms. But this syntax fails badly when the inner text contains another span tags as it becomes difficult (if not impossible) to identify the correct substring by regular expressions (we can not afford full DOM parsing for obvious performance reasons). Also, using spans makes it impossible to start the protected block in the middle of one paragraph and end it in the middle of the second one because HTML tags must nest correctly.
The solution I am about to suggest is to introduce a new syntax using a couple of empty span tags. The start of the protected block would be defined using something like <span class=”nofilterstart”></span>. The block would end at the place where <span class=”nofilterend”></span> is found. XHTML specification recommends not to use the minimized tag syntax for empty span elements, so even if shorter <span class=”xxx” /> would work (and Moodle will support it probably), our HTML editor would produce the syntax with closing tag. This way, both issues with proper nesting and inner spans would be solved.
You see – I got into a completely different area than the performance of format_text() I started to work on But it is quite related in fact. If the filter manager is able to detect some common parts of the text that no filters are expected to modify, it can save time spent on search & replace job that every filter does. Any feedback, idea or contra-proposal is welcome, of course.