General developer forum

• what do you think should be included in a flavour package?
  • I suppose anything that you can change about the standard Moodle install without writing code yourself would be nice. Settings, plugins and language packs, as you say, seems like a good set to aim for.
• what do you think about the name (flavour vs flavor) there is a Moodle standard about the British/American naming?
  • Depends which language pack you have installed
• what nomenclature should be used - backup and restore, export and import, packaging and deployment...?
  • Backup, Restore and Import are already used in Moodle to refer to course functions, so I'd suggest picking something that doesn't conflict with those terms.

Great idea. This could be very usefull for making sure all our new installations are set up correctly.

• what do you think should be included in a flavour package?

=> I would like to be able to backup and restore this:
custom translations,
backup settings, 
email settings,
security settings,
customized roles, 
grade scales
theme settings + non standard themes,
language packs, 
activated / deactivated modules blocks.

• what do you think about the name (flavour vs flavor) there is a Moodle standard about the British/American naming?

The dutch translation would be: "smaak", . There used to be a strange dutch translation for the themes: "uitzicht", "smaak" would be just as weird.

• what nomenclature should be used - backup and restore, export and import, packaging and deployment...?

Moodle configuration package or lazymoodleadminzip

I love the idea of flavours.

As a developer I often need to be able to replicate a moodle setup as quickly as possible to be able to start working. And the idea of having just one development environment that I can switch from one project setup to another with a quick upload of a flavour file is really very attractive. And one more thing - a flavour could also becomes a form of backup for a site.

I must admit that I did my own minimal version of this last year, and it is available on github (https://github.com/Beedell/moodle-report_configcopy). This is not a Flavours but it may give you a start with some code ideas. At the time the ability to replicate most admin settings from one site to another was all that I required. So this was based on the existing admin config classes, and simply creates an xml file representing most admin settings and the upload of this file to another site. The best bit of all was that it works for Moodle 1.9 and 2.0 and the xml file will move many settings between these sites! (Let me know if you want 1.9 code ... though why would you.)

I did not do all the 'nice' elements that would enhance usability as outlined in the project proposal, like the ability to 'turn off' the import of certain bits. I mention this because I found that some admin settings (particularly session settings for us), if imported could lock the site, so the ability to selectivly import would be very nice.

So good luck with this project - I think it will be well used when you have done it.

Hi,

what about dulicating or cloning, as it's more  or less a copy of the site you will do with flavo(u)r.

Best regards and good luck.

Hi David,

Looking forward to seeing this. I think it will be a widely used feature in organisations that have a large number of moodle deployments eg school districts, health/hospital districts, etc. Exciting stuff, all the best with it.

what do you think about the name (flavour vs flavor) there is a Moodle standard about the British/American naming?

From the moodle coding guidelines ... "The default language for all code, comments and documentation, however, is English (AU)." - http://docs.moodle.org/en/Development:Coding#Internationalisation (So "flavour" is preferred if that's the term you choose to use).

what nomenclature should be used - backup and restore, export and import, packaging and deployment...?

Probably best to steer clear of terms that are already used just to avoid confusion so my vote would be for something like package/deploy.

Cheers,
Shane.

Firstly, this is an absolutely brilliant idea that should prove immensely popular! A few initial thoughts below.

what do you think should be included in a flavour package?

• probably loads but the following come to mind:
• activity settings
• block settings
• installed third party activities and blocks
• current theme
• system roles
• homepage settings and content
• selected courses

what do you think about the name (flavour vs flavor) there is a Moodle standard about the British/American naming?

• I agree with the suggestion to use language packs to define
• however, have you considered using 'distribution' or 'distro'?

what nomenclature should be used - backup and restore, export and import, packaging and deployment...?

• package and deploy sounds the most appropriate to me

Hi,

There is a first version of the flavours packaging system available in https://github.com/dmonllao/moodle-local_flavours, it's only a demo and the generated flavours will not probably be deployable because of future changes in the resulting .xml format, but it can give you an idea of what could be included in a flavour.

All feedback will be welcomed

Hi,

this looks really interesting.  I'd love to see an open courseware flavour that could be made available for any-one wanting to apply configuration to open their Moodle courses up publicly - things like opentogoogle, self-registration authentication, more open permissions.

Do you have any idea when this development will make it into the core Moodle git repository?

Thanks

Jenny