Moodle flavours
| Moodle flavours | |
|---|---|
| Project state | Planning |
| Tracker issue | |
| Discussion | |
| Assignee | David Monllaó |
Project specification coming soon...
Introduction
A flavour it's a set of moodle site settings, plugins and language packs. Moodle admins could create flavours from his installation, selecting which settings, plugins and language packs should be packaged into a compressed file and then, share the package with the Moodle community, store it as a backup or use it to replicate the same to other installations he/she manages. It could also be useful for administrators not very experienced with Moodle which haven't enough time to explore all the Moodle settings: they can install the latest Moodle release, look for a flavour which matches his needs and import it.
Examples
- Flavours for universities with the most "common" language packs, videoconferencing plugins and the quiz settings with "secure" values
- Flavours for schools with plugins more oriented to children
- Sets of audio plugins for music teaching
- Local language customizations for Italian (for example) and Romanic language packs, for languages teaching
- Packs of admin monitoring / reporting plugins
GSOC Original Proposal
Short description
This project purpose is to bring Moodle different flavours, allowing administrators to choose and load a flavour from a public repository. Every flavour could contain administration settings, Moodle plugins, sub-plugins, language packs and local language strings. The repository management could be done with a database module instance, that's not the project, the development to do is 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 all that options, but not everybody has enough time to do it.
To complete the short description and leaving apart the appfuse nomenclature, it is a Moodle packaging/deployment system for administration settings, installed plugins, languages and the local customizations (the recent subplugins and the local language strings) That project will not be useful without a database (like the M&P or themes dbs) on moodle.org to share, describe, comment or rate the submitted flavours.
The flavours should 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.
On the deployment side, the user interface can be similar to the courses backup and restore M2.0 steps to familiarized users and to specify which flavour contents will be added. Another important point is the versioning, there should be a control of the settings, plugins and language packs versions to avoid incoherences between incompatible releases.
I'm not sure about the nomenclature, packaging/deployment, export/import, backup/restore...
