Note:

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

Moodle flavours: Difference between revisions

From MoodleDocs
No edit summary
No edit summary
Line 12: Line 12:
==Introduction==
==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 don't have 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.
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 or use it to replicate the flavour to other installations they manages. It could also be useful for administrators with little Moodle experienced, allowing them to explore the Moodle settings and setup recommended by others.


==Examples==
==Examples==
* Flavours for universities with the most "common" language packs, videoconferencing plugins and the quiz settings with "secure" values
* Flavours for universities with common language packs, videoconferencing plugins and the secure quiz settings
* Flavours for schools with plugins more oriented to children
* Flavours for schools with plugins more oriented towards children
* Sets of audio plugins for music teaching
* Sets of audio plugins for music teaching
* Local language customizations for Italian (for example) and Romanic language packs, for languages teaching
* Local language customisations for Italian (for example) and Romanic language packs, for languages teaching
* Packs of admin monitoring / reporting plugins
* Packs of admin monitoring / reporting plugins


Line 24: Line 24:


===Short description===
===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.
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 moodle.org or through the Modules and Plugins databse, although, this project will focus on the development of the flavour packaging and deployment system.


===Long description===
===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.
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.


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.
Based on [http://en.wikipedia.org/wiki/AppFuse 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 moodle.org where flavour contributors can 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.
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.


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.
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.


I'm not sure about the nomenclature, packaging/deployment, export/import, backup/restore...
Another consideration will be versioning; there will need to be control over configuration, plugin and language pack versions to avoid incompatibilities between releases.

Revision as of 07:49, 6 May 2011

Moodle flavours
Project state Planning
Tracker issue
Discussion
Assignee David Monllaó


Project specification coming soon...


Introduction

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 or use it to replicate the flavour to other installations they manages. It could also be useful for administrators with little Moodle experienced, allowing them to explore the Moodle settings and setup recommended by others.

Examples

  • 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

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 moodle.org 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 moodle.org 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.