Moodle Migration

Status

There has been interest expressed by a number of people to be able to import moodle data into Sakai, currently there are no known Sakai import implementations for moodle. If you know of one or are interested in helping write one please send a note to sakai-mig@collab.sakaiproject.org.

Current work

The beginnings of a moodle export file parser for moodle 1.4 have begun at https://source.sakaiproject.org/contrib/migration/trunk/import-parsers/moodle_1.4/

A 1.5.3+ parser has also begun at https://source.sakaiproject.org/contrib/unicon/archive/branches/2-4-x-moodle/. This parser does not extend the IMS parser applied to Bb and WebCT migration efforts. At this writing (Jan 11, 2008) it is limited to web links and file resource import.

The differences between exports from a number of versions of moodle are small enough that there could be a single parser that handles many of them.

The Moodle Course Export Format

Moodle exposes features for site- (i.e. installation) and course-level backup/export. For our purposes, we're interested in the archives generated by course-level backups. End-user documentation of the backup/restore process is available at the folllowing locations:

Based on examples provided by ASU, Moodle's course exports are zip archives having the following structure:

/ --
   |
  course_files/  <-- binaries (sometimes) referenced by objects in manifest
  group_files/   <-- purpose unclear
  moddata/ --    <-- seems to contain activity-specific files, e.g. forum and assignment binaries
            |
            assignment/ --
                         |
                         [some-number]/ --   <!-- large quantity of these
                                         |
                                         [some-other-number]/  <!-- large quantity of these, most containing one binary file
            forum/  <-- layout identical to ../assignment/  
  user_files/    <-- purpose unclear; presumably end-user owned files rather than course content
  moodle.xml     <-- archive manifest

The manifest schema (moodle.xml) does not appear to be documented outside of code.

Tools can generate schemas from moodle.xml instance documents, but the MIG:results aren't particularly useful in terms of trying to grasp the semantics of a given manifest and implement Sakai mappings.

Generally, though, manifests seem to take the following (heavily abbreviated) form, based on a review of manifests generated by Moodle 1.6.1 and 1.5.3+.

(Confluence is not happy with the size of this page if the entire example is inlined.)

<MOODLE_BACKUP>
<INFO>INFO Example</INFO>
<COURSE>

<HEADER>HEADER Example</HEADER>

<BLOCKS>BLOCKS Example</BLOCKS>

<SECTIONS>SECTIONS Example</SECTIONS>

<USERS>USERS Example</USERS>

<QUESTION_CATEGORIES>QUESTION_CATEGORIES example</QUESTION_CATEGORIES>

<SCALES>SCALES Example</SCALES>

<GROUPS>GROUPS Example</GROUPS>

<GRADEBOOK>GRADEBOOK Example</GRADEBOOK>

<MODULES>MODULES Example</MODULES>

</COURSE>

A Note on Moodle URLs

As mentioned in several locations in the examples above, Moodle content descriptors frequently reference each other, sometimes with absolute URLs, and sometimes with macro-encoded urls. For example, instead of http://some.domain.edu/moodle/file.php/1963/science_1.jpg, we'll see $@FILEPHP@$/science_1.jpg. Parameterized macros include an ID reference to some content object. For example: $@WIKIVIEWBYID*48468@$ . Here's the list of macro's encountered so far:

Name	Parameterized	Notes
$@FILEPHP@$	N	Presumably expanded in Moodle to http://some.domain.edu/moodle/file.php/XXXX/ where XXXX is the course ID
$@LINEFEED@$	N	Typically used to encode whitespace in manifest XML without resorting to HTML. Seems to be common in Wiki descriptors.
$@CHATVIEWBYID@$	Y
$@WIKIVIEWBYID@$	Y
$@QUIZVIEWBYID@$	Y
$@WIKIVIEWBYID@$	Y
$@FORUMVIEWBYID@$	Y
$@CHOICEVIEWBYID@$	Y
$@RESOURCEVIEWBYID@$	Y
$@ASSIGNMENTVIEWBYID@$	Y

The following URL formats are also of interest:

Example	Note
http://some.domain.edu/moodle/course/mod.php?update=44685	Meaning unclear. Int value does not correspond to an object defined by the archive manifest.
http://some.domain.edu/moodle/course/view.php?id=1963#1	Seems to link to the default course view, navigating to the section who's ordinal is "1"
http://some.domain.edu/moodle/mod/forum/view.php?id=42111	Presumably an expansion of $@FORUMVIEWBYID*42111@$. The interesting thing about that URL is that in the archive from which it was taken, it actually seems to reference the module's placement in a section rather than a module directly (/MOODLE_BACKUP/COURSE/SECTIONS/SECTION/MODS/MOD[MIG:ID = '42111'] rather than /MOODLE_BACKUP/COURSE/MODULES/MOD[MIG:ID = '42111'])
../../course/view.php?id=1783#workshopnine	This reference was found in an assignment definition (/MOODLE_BACKUP/COURSE/MODULES/MOD[MIG:MODTYPE='assignment']/DESCRIPTION). The relative navigation makes sense if we assume an assignment's URL takes the form /moodle/mod/assignment/view.php?id=XXXX. In this case, 1789 is the course ID. More interestingly, "workshopnine" is a valid anchor name because it is part of the markup inlined in a section summary (e.g. /MOODLE_BACKUP/COURSE/SECTIONS/SECTION/SUMMARY: "<a name="workshopnine" id="workshopnine"></a> <font size = "+2" font face="Arial, Helvetica, sans-serif"><em><strong>Wrapping It Up!</em></strong><p>"

Sample exports

A fairlly simple export sample for moodle 1.4.3 + (2004083131): backup-hsaimsmath-20060907-2303.zip

http://moodle.org/