Course elements

Important : read our plugin support policy



The course elements are structuring primitives dedicated to contents.

In order to give a good unity of form, and to allow learners to clearly identify the educational demand, they allow a fast implementation of the contents, texts and messages. Some of them have added functionalities.

The teacher only cares about the local formatting of his message, without worrying about the visual “integration” of his message.


Course Element Subtype : Contact point.

Nota : student vue of the course element.

5 course elements types

There are 5 types of course elements with different functionalities:

  • Special Features
  • Generic elements
  • Elements of structures
  • Meta Elements
  • Educational elements



:M27: :M28: :M29: :M30: :M31: :M32: :M33: :M34:

Travis-ci Continuous integration

Note : Failing status is not necessarily the sign of a non functioning module. It just says that the Moodle code standards check are not full filling. This is a continuous effort of us rewriting the plugin code to get it compliant.


  • Valéry Frémaux ( - Architecture and development
  • Florence Labord ( - Plugin documentation and standard artwork

Road map

We seriously plan to rewrite fundamentally this module in order to simplify the implementation. the major reason of the code complexity of this module was the inheritance of tricky constraints of Moodle 1.9 architecture for being able to produce the course element content in the course view. This has not been reviewed because we needed at early moodle 2.x stages that the plugin keep entire compatibility with Moodle 1.9 contents.

The pressure to stay full compatible with old storage model is lower now, unless we can provide a good model translator for actual component architecture to new one.

I am sure that the component will gain in maintenability, and will lower risk of technological obsolescence in the future.

What should be great to achieve as workplan:

  1. Restructure storage adding a mdl_customlabel_data table capable to flat storing the element's internal individual values. This will discard completely the older ugly strategy that records the customlabel inside itself in a serialized way. Building the element content would be really such simpler.
  2. Mustache the rendering, or proposing the administrator to define the mustache templates for rendering the element just through global settings. This would let the labels to be very flexible in appearence, while based on a formal data micromodel.
  3. Allow administrators to add a customlabel CSS attached to the template. This is yet possible in themes providing the “Custom CSS” feature, but at a further location from where the element is managed.
  4. Let templates and CSS be stored in backup, so elements could move from a moodle to another. This will vote for storing a local copy of template and css rules in the instance record.
  5. Provide a global setting level moodle filearea to store all the graphic assets, icons, backgrounds, other images used in elements.
  6. Think about reserving also an instance filearea for overriding those assets.
  7. Develop a new customlabel element type capable to get any content from outside moodle using an embedded web service client, and using the captured content as its proper content.
  8. Develop a new customlabel element type capable to get any content of a direct HTML url (publicly accessible) and clip the content by regexps (start/stop).

The global goal of those changes is to make all aspect configuration possible without coding access.

As usual, such a radical change needs a lo of time, and probably budget. At the moment I lack both. So I do not expect short time resolution at the moment, but the road is traced.

Back to plugins index - Back to home

mod/customlabel.txt · Last modified: 2019/04/03 17:58 by florence