← blogs.sussex.ac.uk

Maintaining sites for the students’ programme duration

At Sussex we made a decision that Moodle sites which related to a Sussex course should be maintained for the duration of the students’ degree programme. This means for any particular course we have sites for every year it is run.

For example Sussex 3rd year students have Moodle sites for all the course modules they have taken, through the academic years 10/11, 09/10 and 08/09. They can return to their first year, and indeed any sites they have been enrolled on during their time at Sussex.

This has implications pedagogically, socially and technically.

Pedagogical implications

There are advantages for the students because they can access their previous year’s sites so for example they can return to their original lecture notes, the discussions they had and the feedback they got from formative online assessments such as quizzes.

Social implications

Often student contributions to Moodle activities are chatty and temporal in nature and it is not always useful or desirable to have them inscribed permanently in the online learning space. Keeping sites for the entire length of a student’s degree ingrains the idea of permanency of student contributions and might deter students from contributing.

Technical implications

Whist we have tentatively explored hosting different Moodle installations for different years we currently keep all sites on one Moodle installation, having decided it is better to have one code source and database to maintain. This effects the method by which we roll sites forward to new academic years, navigate Moodle sites and server disc space.

Rolling sites forward

At the start of each academic year courses have new empty Moodle sites created for them.  Often the tutors want to import the data from the previous year’s site. There are two Moodle features which help tutors do this: “import” and “backup and restore”.  Because import is simpler we encourage tutors to use this method. To support this we added a plugin which meant the “import” process brought across the site section summaries if one didn’t exist.

Navigating Moodle sites

Because we keep Moodle sites for three years or longer we have many sites available to our users. If sites are sorted alphabetically users have to sift through many old sites which they no longer regularly access. In order to combat this we have added an academic year field to the database that allows us to sort sites chronologically.

Server disc space

In general sites within a 1.9 Moodle installation have separate file stores. This means that files used in more than one site are stored separately. Often tutors might use the same files from year to year. This means that we have different files containing the same data for each instance of a site (08/09, 09/10, 10/11).  As a result we currently have in excess of 400GB of data. This is an issue for our infrastructure team and it also means that there is too much data for us to have an exact development replica of the live system.


  1. Matt Jenner
    Posted May 25, 2011 at 4:39 pm | Permalink

    At our institution (UCL) we create a seperate copy at the end of the teaching year, this is stored on a seperate instance of Moodle, creating one each year. The idea is that any other course will follow your approach, where an empty container is made and they must import content to effectivly create ther archive copy themselves.

    I wondered, did you consider other methods, or have you found this to be a solution which works across the spectrum of courses in your Moodle? My concern is courses will not automatically be archived (or reset) by those who don’t understand the benefits or the methodologies of course life cycles – has this been a problem for Sussex?

    I probably have more questions, if anyone would email me directly that would be really great! (or a reply here :))

  2. Paolo Oprandi
    Posted May 26, 2011 at 10:10 am | Permalink

    Hi Matt,

    I’ll respond here in case we generate some wider discussion. 

    Just to be clear, we have a slightly different model from the one you are proposing.  We keep all course site instances and don’t archive anything.  Students can get back to last year’s course sites, course materials and continue participating in the course site activities if they choose.  The course sites exist on the same Moodle installation.  This why we have redesigned our landing page navigation so course site lists are viewed by year. Each academic year a tutor is given a new Moodle course site which they need to rebuild from an empty shell. If they want to replicate last year’s course site they can import it. 

    From informal feedback it is clear that the year transition process is an area of frustration for staff. As  you are probably aware the user experience of the “import” and the “backup and restore” features is poor as there are a lot of clicks and some unhelpful information. Furthermore the processes are both flakey Moodle features and are prone to failing.  This is, in part, due to PHP’s memory handling.

    We were very interested in Kent’s model which is similar to ours, but they have redeveloped the backup and restore feature using java.  Have you seen their Moot UK 11 presentation? As I speak/write I am currently designing a similar “rollover” tool but in php as we don’t have java developers who could dedicate time to this at the moment. What options are you considering at UCL?


  3. Posted December 11, 2012 at 11:45 am | Permalink

    Hi Paolo,

    Thanks for posting this. Our rollover procedure is similar to Matt’s; creating a separate instance of Moodle to store the previous academic year’s content. However, I think the model that you have adopted is preferable and we would like to explore this for our Moodle site in more detail. I’m wondering, has the move to Moodle 2 lessened your file storage space requirements for the ‘1 Moodle site, multple academic years’ model?

    best regards,

  4. Paolo Oprandi
    Posted December 21, 2012 at 10:29 am | Permalink

    Hi Cathal, whilst the motives for changing file handling in moodle were admirable we do not like the implementation. As a result of this and other design decisions we still haven’t bitten the bullet and moved to Moodle 2. We are still not prepared to subject our users to the functional, but non-user centred logic it exposes. We are hoping later versions of Moodle address our concerns.

One Trackback

  1. […] the duration of a student’s study. For more information about this decision see blogs post on “maintaining sites for the students programme duration”. As a result the identifier passed to Moodle was the course code appended with the term and […]

Post a Comment

Your email is never shared. Required fields are marked *