And I see there's also movement on this topic at
We're at the stage where we've finished our first deployment and are going through all our patches to see which might be interesting for 1.5 (see also this thread: http://moodle.org/mod/forum/discuss.php?d=17269)
One of the modifications I made was to allow 'importing course data'. Basically, from any course you are a teacher of, there's a new option to import data, where you can select a course that you've previously taught, a course in the same category, or search for any course. Once you've chosen the course you want to import data FROM, a process begins that looks just like the normal backup process - you get the list of modules and choose which ones you want. Once this process is complete, it will automatically kick into the restore part of the process, restoring into the course you started at, although it will cut down the number of screens you're presented with.
Basically, it's an interface to Eloy's excellent ( gratuitous plug ) backup/restore functionality that makes sense from a "sharing content between courses" point of view. You start off where you want the data to land up, and only go through one process to get there.
The patch at the moment is a bit hackish, I guess this is to open discussion as to whether we can use any bits of it, or how we can improve it/make it more elegant, for inclusion in 1.5.
This is something we have going in our FileManager (MyFiles) block, we already have linked content (new version should be in CVS/contrib later this week), where a teacher has the option to copy files or to link files, linked files are shared with other courses from the originating course and when the original is changed, all linked instances change (w/as copied files don't change when the original changes).
But now the shared/copyied files only show up in the MyFiles directory, the next step is to get them to show up in the course files directory or to have the myfiles directory (stored in modata) show up in the add image/add link view in the editor.
It originally came from the need for courses to repeat over semesters - so you'd make the first course for the first semester and add all the content... and then when that course finished you'd make a new one and import all the content from the old one. That way the old course would be 'dead' so it wouldn't matter if the material was out of date- you'd update it in the new course.
In fact, I'm not absolutely sure sure that linking course material (other than perhaps resources) is ideal. Perhaps you have three very similar courses, so you make one and then copy the contents to the other two - then if you're just linking rather than copying you don't get to customise the content in the second two at all. Maybe copying the contents over is a starting point, as they're 90% the same but if you're linking you can't change that 10%... I'm not sure, maybe both models have their separate uses.
Definitely linking files is very useful. I have to ponder this a bit
We create a course as mother course and then copy that course sometimes seven times. Would be great to have the choice between "copy anything" and "copy only the course-layout and link to mother". (a pragmatric course centered CMS?)
I think this would be very useful. I very often need to copy an activity from one course to another and the current route is: backup the other course, restore it to a new course, delete all the unwanted activities, backup again, restore to the current course. Each of those backup and restore processes involves about a hundred clicks because the current interface loves to ask for confirmation as often as it can. If your new interface streamlines this then it will be priceless.
It is really a shame that currently with all the effort that Eloy has put into the backup and restore process we are lacking the interface to use it for anything else than backup and restore of whole courses.
Unfortunately it is limited in that you can't select INDIVIDUAL activities - you can only select modules. Ideally, you'd have finer grain control. Check out this thread:
In which we're discussing exactly that.
I sent an email to Eloy ages ago about all this and I hope to work with him when he starts doing this to get the import/copying part to use the finer control.
I depends on the XML files being organized on a per-resource nested structure, something I haven't read into yet.
Eloy, what do you think? Would it be possible to do an 'indexing' pass on the XML file to discover its contents?
Another consideration (for backup, not so much with copying) is user data - currently you select each module with or without user data - this way would you want to select each instance with or without user data as well? I'm not sure if that would mesh in that well currently.
first of all, sorry by my laggy answer but, two days ago, my eMac logic board died and I've spent these days copying everything from its disk to my laptop, firewire disk and CDs. Now the eMac is "knowing the World", traveling to Apple to be repaired. Hope it will be back at home soon!
About these (really old ) functionality "individual selection of activities", my personal opinion is that it should be supported both in backup and restore.
With some exceptions (see below) I think that it should be really easy to implement at restore time, basically because the restore code in each module currently is executed for each activity, so calling it with only certain activities (pre-selected in a previous xml parse) shouldn't be difficult at all.
What is more complicated (due to its current implementation) is to allow such selection of activities at backup time. Currently I export all the module DB data per activity (cool!), but the moddata/module dir is copied completelly (bad!). Because of this, we should modify every module backup to copy moddata files selectively (by activity). Then we could implement the selective backup.
And the point I haven't been able to resolve is "how I backup (and restore) an uploaded resource?". As these type of resources are absolutely free (you can place them where you want and having every structure for images, scripts...), I haven't idea about how to deal with them! Perhaps we should build some type of html parser to be able to select what to copy (links, images, styles...) but it's really out of my skills and probably, out of the backup objetives. Although such type of parser will allow us to export/import resources in other formats (IMS, SCORM....) in the future!
Other details must be modified too to allow individual selection of activities to work at backup time, but I think they are relatively easy (computable) and I don't specify them here.
After all this, I think that, perhaps, it could be nice to implement the restore first as it sould be easier. The code should work for near every module but the uploaded-resource (and other "free-storage" modules). We could implement it module by module, adding an "restore_individual_XXX" function. In practically all the modules, it will call the standard "restore_XXX" function but we could use it to decide when to allow or no the individual selection in a module.
Having this working will allow moodlers to avoid the "double" backup/restore process and selectively load activities in their courses what is a long awaited feature. Then, if required, we could start with the backup part of the functionality.
That's my view of the problem and a possible roadmap to do it...when in Moodle's timeframe it will fit...uhm, difficult for now (for me).