Just about done with development of version 1.0 of the module. A couple of important, but hopefully straight forward tasks to do. One of these is adding the ability for BIM activities to be backed up and restored. That’s the purpose of this post. The plan is to find out how it is meant to work and plan how it can be done for BIM.

At this stage, I’ve worked out the basics of how this works. I think. I haven’t implemented it, so new wrinkles may appear. Current status is to defer work on this and focus on that functionality required for immediate use. This can be added in a little while.

How it works

The Module extension development book I’ve been using is pretty poor in its treatment of backups/restores. Some existing Moodle documentation includes:

Some basic stuff gleaned from the code of some activities – incomplete

  • Moodle looks for files backuplib.php and restorelib.php
  • Data is saved in a simple XML file format.
  • backup functions (from core choice module) QUESTION Are these specific to choice or common?
    • choice_backup_mods($bf,$preferences)
      Standard, purpose is to backup everything for this module
    • choice_backup_one_mod($bf,$preferences,$choice)
      Standard, purpose is to backup just a single instance of the module based on the $choice parameter as the id
    • backup_choice_answers ($bf,$preferences,$choice)
      Standard, previous function backs up the instance data and then this one saves some contents
    • backup_choice_options ($bf,$preferences,$choice)
    • choice_check_backup_mods($course,$user_data=false,$backup_unique_code,$instances=null)
    • choice_check_backup_mods_instances($instance,$backup_unique_code)
    • choice_encode_content_links ($content,$preferences)
    • choice_ids ($course)
    • choice_answer_ids_by_course ($course)
    • choice_answer_ids_by_instance ($instanceid)
  • Need to save
    • instance data

An attempt to describe the process

  • Moodle module backup works be essentially creating a XML file that contains all the information in the database tables associated with the module.
  • It assumes a hierarchical relationships in the data.
    • All instances of the module
      • Data specific to an instance. (non-hierarchical)
      • All hierarchical data for an instance (e.g. student feeds for a bim)
        • Data specific to a single instance (e.g. feed_url)
        • All hierarchical data (e.g. posts made to the feed)
          • Data specific to a single instance (e.g. content of post)
          • All hierarhical data (…and so on)
  • The nested/hierarchical relationship with the XML produced is mirrored in the functions that exist. The first one is MODULENAME_backup_mods($bf,$preferences) which calls the next level down…
  • Two other required functions with names containing …_check_.. are used to generate some options that allow the user doing the backup to choose what to backup.
  • Another function MODULENAME_encode_content_links is a bit of a mystery. Might be to “support inter-activities linking” or “recode links to ensure they work when reimported” – NOT SURE.
    I’m assuming that this is needed because as the database ids are created by a restore, they are likely to be different to the original data. If they do change, then it will be necessary to modify some other links. There are two types I could think of:
    1. links between database tables
    2. links in URLs with fields in the tables.

    The backup stuff for chat, seems to indicate the latter

  • The functions doing the save are meant to write XML by using fwrite and XML functions like “start_tag” “end_tag” full_tag”.

The bim hierarchy

  • bim
    • Instance data: id course name intro introformat timecreated timemodified register_feed mirror_feed change_feed grade_feed ….Other standard module stuff???
    • bim_group_allocation
      • Instance data: id bim userid groupid
      • NO HIERARCHICAL DATA
    • bim_questions
      • Instance data: id, bim, title, body, min_mark, max_mark
      • NO HIERARCHICAL DATA
    • bim_student_feeds
      • Instance data: id, bim, userid, numentries, lastpost, blogurl, feedurl
      • NO HIERARCHICAL DATA
    • bim_marking
      • Instance data: id, bim, userid, marker, question, mark, status, timepublished, timemarked, link, post, comments, title
      • NO HIERARCHICAL DATA

Implementing it

Seems a fairly straight forward process in generating the backup. I’m simply copying the backuplib.php functions from the choice and forum modules. Mostly choice as it’s simpler.

NOTE: In saving the data for an element they are not saving the foreign key back to the instance of the module. i.e. each question belongs to BIM, specified by the bim->id. But the BIM id is not being saved for the question. Obviously to be populated on restore.

I am wondering how some of the large text fields – including HTML – will go.

Also how the underscores in field names in the database tables will go. Seems the Moodle model is to run the text all together – minmark instead of my min_mark.

Getting it to appear

I have an initial backuplib.php up. Have tried to do a backup on the course with a BIM and it failed due to syntax errors in backuplib.php. However, when those were fixed there were no options in the displayed backup page for BIM. Something is missing.

Maybe it is the function bim_check_backup_mods – something in backuplib.php for the module that informs the general back up what to display. Let’s try.

Actually, it appears I had a typo in one of the functions.

A bit more provision of functions and hey presto, it is working, at least the bit I’ve implemented.

Next steps

  • Writing restore functions for course data.

    Got the initial ones working. Even tested them round trip.

  • Writing the backup functions for the user data.
    • student feeds – write data
    • student feeds – display
    • marking – write data
    • marking – display
    • group allocation – write data
    • group allocation – display
  • Writing restore functions for user data.
    • group allocation
    • marking
    • student feeds