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

Moodle flavours

From MoodleDocs
Moodle flavours
Project state Completed
Tracker issue
Assignee David Monllaó


A flavour is a packaged set of Moodle site settings, plugins and language packs. Moodle Administrators will be able to create a flavour from their installation, selecting which settings, plugins and language packs will be packaged into a compressed file. They can then:

  • share the package with the Moodle community
  • store it as a backup
  • use it to replicate the flavour to other installations they manage.

It could also be useful for administrators with little Moodle experience, allowing them to explore the Moodle settings and setup recommended by others.


  • Flavours for universities with common language packs, videoconferencing plugins and the secure quiz settings
  • Flavours for schools with plugins more oriented towards children
  • Sets of audio plugins for music teaching
  • Local language customisations for Italian (for example) and Romanic language packs, for languages teaching
  • Packs of admin monitoring / reporting plugins
  • Flavours for specific industry sectors (e.g. Retail, Automotive, Health, Defence - each have common needs)
  • Flavours for Distance Learning organisations
  • Flavour for Apprenticeships


Moodle 2.1 required

Community bonding period


  1. DONE - Refine the project proposal with Michael and the community feedback
  2. DONE - Define steps/screens and navigation
  3. DONE - Create mockups

Ingredients availables to include in a flavour

  • Site settings
  • Language packs
  • Custom language strings
  • Plugins
    • Subplugins
    • Question types
    • Activity modules
    • Authentication methods
    • Enrolment methods
    • Messaging processors
    • Blocks
    • Text filters
    • Editors
    • Course formats
    • Profile field types
    • Site reports
    • Course reports
    • Grade export methods
    • Grade import methods
    • Gradebook reports
    • MNet services
    • Webservice protocols
    • Plagiarism
    • Repositories
    • Portfolios
    • Question behaviours
    • Question import/export formats
    • Themes
    • Assignment types
    • Database field types
    • Database presets
    • Quiz reports
    • Workshop grading strategies
    • Workshop submissions allocation methods
    • Workshop grading evaluation methods
    • Local plugins


There are two main use cases: flavour packaging and flavour deployment.


This use case will allow Moodle Administrators to package their installation ingredients into a compressed file.

Steps to generate new flavours

  1. Ingredients selection
    • Ingredients listed in tree form
    • Expandable and collapsible tree nodes for easy ingredients selection
    • Checkable nodes maintaining the hierarchy
  2. File-system permissions and others checkings
  3. Download resulting compressed file containing
    • Flavour meta data such as name, author, description, contexts where the flavour could be used, creation time, source site URL and source site version
    • Selected site settings data
    • A set of directories with the selected ingredients reflecting the folder structure used in Moodle


This use case will load a flavour into a Moodle site. Flavours deployed should came from a known/trusted source.

Steps to deploy a flavour into a Moodle site:

  1. Fill the upload flavour form with the selected flavour
  2. Ingredients pre-visualisation and selection of which ones will be deployed
    • Ingredients listed in tree form
    • Expandable and collapsible tree nodes for easy ingredients selection
    • Checkable nodes maintaining the hierarchy
    • Deployment expected consequences
      • Versioning incompatibilities
      • Over-writes
      • File-system permissions issues
  3. Show results

Coding period


  1. DONE - Specify the file structure
  2. DONE - Add a class diagram
  3. DONE - Packaging system
    • DONE - Ingredients classes - packaging public interface
      • DONE - Packaging methods
      • DONE - Methods to populate the ingredients tree
    • DONE - User interface
      • DONE - Create a moodleform with flavour general info fields (name, description...)
      • DONE - A javascript tree view implementation to check ingredients
    • DONE - Packaging system
      • DONE - Use a moodledata temp folder to store the flavour contents
      • DONE - Create a XML writer which will contain flavour data and flavour ingredients info (not code) something like <plugins><mod><feedback>...</feedback></mod>
      • DONE - PHP compression library usage
  4. DONE - Deployment system
    • DONE - Ingredients classes - deployment public interface
      • DONE - Validation methods (is the folder writable? have you a newer version already installed?...)
      • DONE - Deployment methods
    • DONE - User interface
      • DONE - Forms
        • DONE - To upload a flavour
        • DONE - To previsualize the flavour and select which ingredients will be deployed (tree view)
      • DONE - Complete the previsualization form with expected results info
  5. Testing (iterative)
  6. DONE - Documentation (iterative)
    • DONE - Complete Moodle Docs documentation and refactor structure if is necessary
    • DONE - Ensure that all the functions/methods/classes have it's own phpDoc comment block

File structure

  • flavours_deployment.class.php
  • flavours_packaging.class.php
  • flavours_xml_transformer.class.php
  • flavours_xml_writer.class.php
  • flavours.class.php
  • forms/flavours_deployment_form.php
  • forms/flavours_deployment_upload_form.php
  • forms/flavours_packaging_form.php
  • ingredient/flavours_ingredient.class.php
  • ingredient/flavours_ingredient_customlang.class.php
  • ingredient/flavours_ingredient_lang.class.php
  • ingredient/flavours_ingredient_plugin.class.php
  • ingredient/flavours_ingredient_setting.class.php
  • lang/XX/local_flavours.php
  • index.php
  • module.js
  • pix/
  • settings.php
  • styles.css
  • version.php

Class diagram

Flavours class diagram.jpg


Packaging - Select flavour ingredients

Moodle flavours package flavour mockup.png

Deployment - Upload a flavour

Moodle flavours deploy upload mockup.png

Deployment - Ingredients previsualization

Moodle flavours deploy ingredients previsualisation mockup.png


Block admin

flavours screenshot Block admin.jpg

Packaging - Select flavour ingredients

flavours screenshot package.jpg

Deployment - Upload a flavour

flavour screenshot deployment upload.jpg

Deployment - Ingredients previsualization

flavour screenshot deployment preview.jpg

Deployment - Results

flavour screenshot deployment result.jpg

GSOC Original Proposal

Short description

This project will bring flavours to Moodle, allowing Administrators to choose and load a flavour from a public repository. Flavours can contain administration settings, Moodle plugins, sub-plugins, language packs and local language strings. The repository management could be done with a database module instance on or through the Modules and Plugins databse, although, this project will focus on the development of the flavour packaging and deployment system.

Long description

There are a lot of Moodle settings, plugins and integrations with other applications. It's fun to explore Moodle options, but not everyone has time to achieve this.

Based on Appfuse nomenclature, a flavour will be a Moodle package of administration settings, installed plugins, languages and the local customisations. Flavours will be distributed using a database (like the M&P or themes dbs) on where flavour contributors can share, describe, comment or rate the submitted flavours.

Flavours will be distributed as compressed files, with a .xml file to structure the flavour contents. The packaging system should respect the moodle and moodledata directory structure.

To deploy a flavour, the user interface will be similar to the courses backup and restore interface, which should be familiar to Administrators. During deployment, administrators will be able to selectively nominate the flavour contents that will be used.

Another consideration will be versioning; there will need to be control over configuration, plugin and language pack versions to avoid incompatibilities between releases.