If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Talk:Paged course formats

From MoodleDocs


What is the general idea of 'Paged course formats'? - Will it be that you get to see the section name as a list, then if you wish to view it opens in a new tab within the browser?

Discussions around this

Some of the options currently around for alternative formats

Representing several different approaches.



Doed much more than just offer page view. Eiting magic as well.

  1. Folderview Blog post:
  2. Comments by Michael: Including Folderview in Moodle 2

Paul's comment: "Paul Chapin added a comment - 07/Jun/11 3:20 AM : The folder view format doesn't really do it. Basically, that's just a topic format with a different interface. It doesn't deal with the situation of the instructor who wants to make a large amount of reference information, usually files and web links, available as part of a topic or week without visually overwhelming the students. By allowing for a hierarchical structuring of material using folders the amount of information the student is presented with at any given time can be limited and organized logically. It's really files and links that we want, but if that's implemented, adding the rest of the resource types should be fairly straight forward" MDL-27646


Unsure of status for 2.

  1. Flexipage and Moodle 2.0:


Three forms: Topics, Weeks and Latest First

  1. - Same as Topic's format but with a 'toggle' and a cookie to remember state per user per course that can be persistent. Developed much further - see CONTRIB-3378 below.
  2. - Same as Week's format but with a 'toggle' as above.
  3. - Same as above but current week is displayed first and preceding weeks after for the user. In 'editing' mode it is the same as Collapsed Weeks.

Combined into one:

  1. CONTRIB-3378

Which has four forms: Topics, Weeks, Latest Week First and Current Topic First. Available from Modules & Plugin's Database and documented on Collapsed Topics Course Format

Above collapsed forms developed by Gareth J Barnard.


Experimental jQuery Masonry (# format for Moodle 2.1:

  1. - Uses the jQuery Masonry plugin to arrange sections as close together as possible. Resizes automatically depending on content.


Not strictly a "paged format" But getting very good reviews. Looks classy.

  1. Seems a good option

"The Grid Format was originally contributed by Paul Krix. It has since been updated and is now maintained ny Pukunui Technology. This format adds a more graphical interface to viewing Moodle topics and also avoids the "scroll of death" issue by using placeholder graphics to represent each topic. When clicked upon, these graphics launch the topics in ajax windows" from


There are at least two in plugins:

Plus Lei Zhang (and Awesome Moodle) bar

Catalyst have coded two options included in Moodle in Schools package.

Section Menu Option

OU format option

See this blog post and video:

Some thoughts

1. For weekly courses, one page per section is not necessarily ideal. Instead the OU course format (studyplanner) by default just shows the current week (highlighted) with +- n weeks either side. There is then a link 'Show entire study planner' if you need to find something else. Section 0 is always visible. I think this is a good model (speaking as an OU student here). However, the 'mdl_course.coursedisplay' proposal, with just two settings, does nothing to make this easier. Therefore, I am skeptical about the value of hard-coding that into Moodle core.--Tim Hunt 20:09, 12 April 2012 (WST)

Yes, agreed. But how many extra settings can users cope with before they give up? A good case for admin defined course defaults and "Advanced" settings. Ray Lawrence

I wonder whether it would be better to use the course format settings rather than adding a field to the course table for this. This would enable each course format to define it's own settings but would mean a change in priorities for the workload --Andrew Nicols 21:59, 13 April 2012 (WST)

2. Even if you press on with your plan, it seems silly to just list the weeks on the course front page in weekly format. Surely it is worth displaying the current week in full there. It will save students one click almost every time they visit the course.--Tim Hunt 20:09, 12 April 2012 (WST)

Agree. Ray Lawrence

Actually, Tim, this is more or less what I was referring to with the "Accordion" format as a third option in that menu. Basically it's Gareth's Collapsed Format. It would look as you describe and the other sections would be clickable and would expand in-place. I can see it's probably it's less clicks for the weekly and topics format to expand the currently-selected section on the main course page even in the one-section-per-page format, but I'm a little worried about the inconsistency of the interface. Happy to do it if there's no other objections though. Martin Dougiamas 15:58, 13 April 2012 (WST)

It's quite hard to work out what is being proposed. Is it one section/week on a page or a collapsible format. both. A sketch would be handy. Ray Lawrence

3. Has anyone at HQ actually downloaded and installed the OU's subpage module? I know it solves a separate problem, but please spend some time looking at it now for two reasons. A. When you do the "Check for regressions in modules caused by course assumptions" bit, you should try to ensure that they benefit modules like subpage, as well as your course format changes. B. Subpage functionality might be worth adding to Moodle too, and the code already exists and works.--Tim Hunt 20:09, 12 April 2012 (WST)

My reservation about this is that it adds a layer the location of which isn't clear to users. I don't think we can have a format that add an element of mystery to the masses. Think how confused uders can be by activities in Orphaned courses if one isn't careful with it. Ray Lawrence

I've looked at it. Sorry it's just too much to add on at this stage with the short time period and so much to do already. Martin Dougiamas 15:58, 13 April 2012 (WST)

4. Be very careful when defining format_renderer_base. If you have format_weekly_renderer extends format_renderer_base, and format_renderer_base generates output for something, then a theme cannot do theme_mytheme_format_renderer cannot usefully extend format_renderer_base to change the output, because format_weekly_renderer still extends format_renderer_base, and not theme_mytheme_format_renderer. (I made this mistake in a few small ways with question_type_renderer base, e.g. the feedback_image mehthod, although I mostly got it right by creating core_question_renderer to output the common parts of questions.) Basically, prefer composition over inheritance ( Hunt 20:09, 12 April 2012 (WST)

5. I am worried that you are trying to do this in a rush before the 2.3 deadline, particularly if you are not going to delay mdl_course.coursedisplay until 2.4. It occurs to me that a lot of this could be done initially in third-party course-format plugins. Then, once everyone can see it working, and has been bowled over by how amazing it is (assuming you are right, and I am wrong) you can then refactor the code into Moodle core.--Tim Hunt 20:09, 12 April 2012 (WST)

Frankly these exist already and do it in all kinds of wierd ways. I want a simple setting that implements it in core formats in the simplest possible way. Others are free to build on top of it with plugins later. Martin Dougiamas 15:58, 13 April 2012 (WST)

5.1 I disagree with Tim over implementing initially in third-party course-format plugins. As this is a 'core' functionality change it should be implemented there as 'gospel' way of implementing the functionality so that there is no confusion over interpretation of how it should work. Because if each contrib developer takes their 'view' then we will have a mismash that will have to be sorted and then the contrib developers have to refactor back to the HQ defined standard. I don't live and breathe PHP or Moodle (sacrilege I know) so tend to follow and adapt the 'guru' written code in the core formats as a basis of learning and implementing the correct functionality, hence I consider a core 'guru gospel' implementation to be the better solution. Gareth Barnard 21:20, 12 April 2012 (WST)

Agree. It's fundamental stuff. Let's take it steady. In core.Ray Lawrence

5.2 I do agree with the thought of it being rushed as although I consider a lot of users have been screaming for this for ages, it would be better to get it right first time even if this takes a little longer. As a bodge job could put users off Moodle completely and cause them to lose faith in the quality of the product. Gareth Barnard 21:20, 12 April 2012 (WST)

6. We have not yet published the Moodle 2.x code for the studyplanner course format, but if anyone want to see it, we can probably share it. Just ask.--Tim Hunt 20:11, 12 April 2012 (WST)

7. Do we really want the course format options to be part of the already very long and complex course settings form. Whey not have a separate link in the settings block for 'Weekly format options', or something like that. Much simpler all round.--Tim Hunt 20:13, 12 April 2012 (WST)

Yeah simpler but will they see it there? Some of the settings are quite key ... Martin Dougiamas 15:58, 13 April 2012 (WST)

8. I override the function 'section_class.prototype.swap_with_section' in '/lib/ajax/section_classes.js' in the contributed 'Collapsed Topics' course format because I use a table for my layout and hence two table rows per section. Therefore, will I still be able to do this? Before I get blamed for using a 'table' tag instead of a 'div' tag and a set of 'ul' tags, tables work for me because the layout is tabular and conceptually is a table in the Object Orientated sense (bar the three/four/more legs), and indeed the W3C specification of a 'table' states 'The HTML table model allows authors to arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells.' and that is exactly what I am doing as an arrangement of the sections as rows and columnar subdivision of content / section information. It also works better with Internet Explorer and manipulating the Document Object Model with JavaScript at the client end. Gareth Barnard 21:20, 12 April 2012 (WST)

Eagerly awaiting this, a few comments on the spec.

-The section name (as a link to the separate page)

I'm having visualising this, could you add a mock up to clarify intentions.

- Controls to hide/show that section, as usual

Is this referring to Hidden sections?

- Tthe section summary (truncated if it’s too long)

IMO any automatic setting here will cause issues. Course designer needs to be able to add content as required. It's up to them to manage.

- More sections can be added by a big "plus" icon at the bottom, and old ones can be deleted if they are empty.

In both paged and standard layouts? Would be great.

- The section pages should be seen as "sub" pages of the course page and can have their own blocks.

This could make things pretty complicated.

What would happen if teacher switched to standard view from paged?

How would Nav and settings block behaveon a page?

- There is no longer need in per-user setting to show only one section in the course (it confused people anyway).

So what happens with legacy courses where this in use and standard layout courses when users want to focus on a single section/week?

- Add a user preference controlled by link/button in UI to switch between old-style menu (for expert users) and this new-style pop up (as default, for new users).

Expert users? My vote is for one method

- Extend course settings with format support

Ideally this would be extended to set defaults in the adminitration course defaults. This would be popular and more user friendly than the current change config.php approach.

Ray Lawrence