Learning the World

Our Moodle Wikis were working just fine (well, they were working about as well as the Moodle wiki ever does) until 1.9.4. That’s when they broke; you could select and upload a file (e.g. a photo), but the screen would go white (indicating a PHP error) and your file wouldn’t make it to the wiki. As we have a number of wikis that upload photos, this was a problem.

The issue appears to be a change in the default settings for the wiki. Making the wiki configuration tweaks described in this Tracker report fixed the problem:

• MDL-10641 Wiki binary files option broken

In 1.9.4, Moodle introduces a new security report tool which compares your Moodle roles against different security risks. My colleagues and I just spent the afternoon puzzling through the flags that 1.9.4+ raised in our test Moodle install. Unfortunately, “puzzling” is the optimum word here: we spent a big chunk of time just trying to understand what the report was trying to tell us. Here’s what I learned.

To start, you need to understand how Moodle tolerates risks based on roles (defined under “Risks” in the Moodle Docs wiki.):

• Guest - only capabilities without any risks are allowed
• Student - certain capabilities with spam risks are allowed
• Teacher - certain capabilities with XSS and privacy risks are allowed
• Administrator - all capabilities are allowed

This is important because any custom roles you’ve created are evaluated based on the legacy role that spawned them. So if you start with a student role, and give it some more advanced teacher-like options that allow XSS capabilities, then Moodle will set a critical warning flag because its exceeded the capabilities normally associated with a student.

I need to doublecheck this, but I think that if you change the legacy role associated with the custom role in question to “teacher”, then your custom capabilities will remain the same, but the report will run against the more permissive teacher role. That said, you may not want to get rid of the warnings (since it is helpful to know what a “super student” role could get themselves into) but at least this write-up should help you understand them.

I’d love to see Moodle create a more user-friendly report that says something like:

• “Your role ‘Teacher Assistant’ is based on the legacy role ‘Student’. By default, students are not allowed to have capabilities that permit Cross Site Scripting (XSS), but your custom role allows the following XSS capabilities” — I’d then include a list of the problem capabilities.

You can contribute to improving the Security Report by reading/commenting on this tracker item:

• MDL-18078: Provide a feedback for the admin in order to explain him/her what to do to fix the security problem rised up by the security report

Moodle has a nasty habit of leaving specail characters in file names after you unzip an archive. It will strips these characters (like apostrophies) from a file when that file is uploaded individually, but if you upload an archive, that process doesn’t happen.

The problem comes when you try and delete that file — Moodle’s scripts can’t handle the special character, and refuse to allow you to move, delete or otherwise modify the file. Fortunately, a fix is coming in Moodle 1.9.5 thanks to the work of Charles Fulton of Kalamazoo College at Hack/Doc Fest III at Reed College in January 2009.

You can read about it in tracker here:

• MDL-237 Special characters left in filenames after unzipping

A patch is available via tracker. A fix will be available in Moodle 1.9.5.

Two new bugs on my list have officially been squashed by the the Moodle core team:

• MDL-15926: WHen clicking on help for scales in forums, ALL the scales are shown, instead of just one (fixed Moodle 1.9.2, verifiedin 1.9.4+)
• Summaries don’t get imported from the source course to the destination course (fixed in Moodle 1.9.5, but available in the weekly 1.9.4+ builds)

The summaries bug has been kicking around for a long time, and is something we worked on at Hack/Doc Fest II at Kenyon College in June 2008, so it’s nice to see it finally make its way into core.

By default, Moodle uses Magpie RSS to parse its RSS feeds. Unfortunately Magpie tends to be buggy, and hasn’t been updated since 2005. At Hack/Doc Fest II at Kenyon College we put together a patch that swaps out Magpie RSS for the much more current SImplePie RSS (hat tip Charles Fulton, Kalamazoo College, who did most of the patching).

Details on how to swap out Magpie for SImplePie can be found in Moodle Tracker:

• MDL-7946: Use simplepie instead of magpie for rss parsing

This seems like a no brainer swap to me, but the tracker item could still use some vote love. The tracker doesn’t mention it, but this problem still affects Moodle 1.9.4.

If you unzip a folder containing files with special characters, those files become uneditable and unmoveable via the web browser; the only way to get rid of them is through the command line. This is because Moodle is not escaping the file names when they are created (as it does with single file uploads); instead of replacing the special characters with placeholders, the files get created with the bad characters.

A full rundown and a patch is available in Google tracker; hat tip to Charles Fulton for taking the time to debug this.

http://tracker.moodle.org/browse/MDL-2307

By default, individual course scales should not be accessible to other users on the site unless they’ve been designated a site-wide “standard” scale, which is something only admins can do.

However, we’ve discovered that if you create a Grade Item (via Grades > Choose an Action > Categories & Items > Add Grade Item) and click on the “Scale” drop down menu, you see all the custom scales available on the site.

• Tracker: http://tracker.moodle.org/browse/MDL-16431

Update 12/2/2008

It turns this is a duplicate of an existing bug, which will be fixed in Moodle 1.9.4:

• Tracker: http://tracker.moodle.org/browse/MDL-15926

This bug drove me (and the instructional technologists I work with) more than a little crazy.

If you create a page in the Moodle wiki that includes a pound (#) sign, and then edit that page, Moodle truncates the page name, forking it and creating a new page.

The original page continues to display, but when you go to edit it, the new page appears. If you then save changes and return to the initial wiki page, the changes do not appear (because they were made to the truncated page, not the original one).

Add groups into the mix, and it gets even more fun. We spent a good amount of time chasing our tails before we realized what the problem was.

This bug is already documented in tracker by Dean Thayer:

• MDL-17237: Can’t edit a wiki with a # (hash, number sign, pound sign) in it’s name

Our exact case was a little more involved than this. We had people creating new pages that some how got the original text into the new page, which isn’t behavior I saw in my tests. Yet if I look at the initial page for these wiki pages, I can see that they started with the same text as the initial page, and I don’t think the students or instructor copied text over into the new page.

It’s very odd, but I think it all comes back to that blasted # sign.

Scheduler, a third-parting appointment scheduling module for Moodle, doesn’t deal properly with Daylight Saving Time. Events spanning the daylight/standard time boundry appear one hour earlier in the scheduler after EDT reverts to EST.

A report for this bug is up in the Scheduler bug tracker (which is independent of Moodle’s own tracker; registration is required to view/comment on this bug)

• Scheduler doesn’t deal with Daylight Savings Time

It looks like there’s a bug in Moodle 1.9’s “Advanced Uploading of Files” that prevents students from seeing faculty responses submitted as revised files/comments unless a grade has been assigned to the assignment. This happens even if the assignment was set to “No Grade”. I haven’t seen this one in the wild yet, but I understand how it would be problematic. 

http://tracker.moodle.org/browse/MDL-16553