User:Frank Ralf/Moodle 2.1 sections proposal

From MoodleDocs

See 2.1 proposal: Sections inside modules --Frank Ralf 18:08, 12 November 2010 (UTC)

Moodle sections proposal

Currently Moodle sections are always directly within a course.

This works fine but we need (and many other sites do too!) a way to place Moodle activities somewhere other than on a course main page.

OU context

Initially at the OU this will be used in the subpage module, which lets you create a subpage and add one or more sections and activities to it. This will be implemented with a hack using high section numbers that don’t show on the main page, and will require a few hacks to core code in order to operate cleanly.

While the subpage module would be a useful one for Moodle in general and could perhaps be included into core at some point, it might also be useful to have a way to add things inside other types of module at a later date, so a generic solution might be preferable.


My proposal is that the course_sections table should be replaced with a context_sections table.

The table is identical except that the course field becomes a contextid field. During upgrade, the table values are created in the obvious manner (this can be done with a single SQL query, SELECT INTO or whatever that is).

Note that the context in this table will have to be within a course, i.e. the system will probably not work unless the context either is, or has as a parent, a course (level 50) context. The system doesn’t need to enforce this, just ensure that UI won’t let it happen. This is because I don’t propose changing the course_modules table, so all activities must still live within a course, data will be cached at a course level (modinfo) and so on.


Modules (e.g. our subpage) that implement this feature are free to interpret the section number how they like.


Backup and restore for a course will include:

  • All sections contained within any activity being backed up.
  • (Possibly optionally) All sections at course context level.

Additionally, the backup system will not permit you to back up an activity that is contained in a section X unless the activity that owns that section X is also being backed up.

Caching (modinfo)

The modinfo cache will continue to cache all sections within the course. The information in this cache about sections will change slightly, which will have consequences for a few code areas including the course view page and course formats.

It should be feasible to find affected code (within core Moodle) with grep or similar tools.

Editing code

There will need to be some changes to core code related to editing activities:

  • Change scripts to do with editing activities (edit/delete/move activity, etc.) so that these can return to the correct place given the context, and not always the course view page.
  • Change JavaScript for moving activities/sections, also print_section, etc. so that the AJAX code can be applied to other pages.
    • I believe the JavaScript needs rewriting anyway in order to update it to YUI3, this might be a good opportunity.


When checking permission for a course-module that is contained within a section that is in another context, the system will need to also check that you have permission to access the parent context too.

For example if you have a section containing activities B, C inside an activity A, then if activity A is hidden or date-restricted, obviously that should apply to B, C as well.

This should be implemented in such a way as to not reduce performance at all in the case where the module is not contained inside another one. There might be an additional effort required when it is contained.


When displaying the navigation tree, these sections need to be shown inside their parent activity. This would also affect breadcrumbs, so you could have breadcrumbs looking like (I’ve missed out a bunch of them):

Home > Course > Library resources > Library quiz

where ‘Library resources’ is a parent context and ‘Library quiz’ is an activity inside a section in that context.