Hi,
I'm working on a new course format (hopefully will release as contrib when done; it's specific to our needs here but might be applicable more widely too), and two questions come to mind.
1) Is it OK if I make course formats able to have database tables? (The usual install/update.) There's a function that does this so it's a one-liner...
2) How about if I add format-specific CSS? (I haven't looked at how to do this but it's probably easy.)
Basically I want to make course formats 'first class' pluggable items like modules and blocks (those have both the above features), which at the moment they aren't.
#1 shouldn't cause any problem [I'm using it, it works] but there's a potential issue with #2 which is that obviously if you use different styling then themes won't work with your format. However that's basically unavoidable if your format needs different elements. Also, exactly the same issue applies to modules and blocks which are both allowed their own CSS.
If it's ok to go ahead with this I'll file bugs for the changes and check them into 1.8 HEAD.
--sam
PS I guess I could just ask Martin or somebody directly, but I figure it's better to keep people informed...
1) Yep, though you're also going to have to implement backup and restore for course formats if you do that.
2) This is easy, yes. All the modules do this with a styles.php. You just need to modify the style_sheet_setup() function that searches for all these to make sure it also looks in the course/format/xx directories (with a $THEME->coursesheets to control it, documented in theme/standard/config.php).
And yes, please file in the tracker for tracking.
2) This is easy, yes. All the modules do this with a styles.php. You just need to modify the style_sheet_setup() function that searches for all these to make sure it also looks in the course/format/xx directories (with a $THEME->coursesheets to control it, documented in theme/standard/config.php).
And yes, please file in the tracker for tracking.
Thanks for the pointers. I did know backup and restore would be needed but was still trying to pretend that problem didn't exist for just a little bit longer... 
I'll do that too. Not sure when I will complete this, it may be a few weeks. I filed the tracker entry now anyway.
http://tracker.moodle.org/browse/MDL-7401
--sam
http://tracker.moodle.org/browse/MDL-7401
--sam
I think that having course formats as plugins will be great and add boost to another area of Moodle. However, there may be more to do for the formats to become plugins than mentioned so far, like supporting certain properties that other code can inquire and certain functions that other code can call upon. There are currently explicit actions depending on the course format sprinkled in a number of places in Moodle. These are hardcoded for the 3 standard formats. I just saw something in the assignment module that triggered my memory.
Thanks for the tip. If I have time, I'll take a quick look for such problems and see what can be done, but I might not get to it (unless of course they break areas of code that the OU actually uses).
There are also a few other things that really ought to be done (which I am realising as I make progress implementing mine). Two I have come across are:
1) They need their own language file (presumably format_myformat.php, like blocks), but perhaps this might have performance implications.
2) They may need their own icons. Unfortunately the Moodle infrastructure for image files clearly needs totally changing (well, creating, in large part), possibly via a themeimage.php file that does a hierarchical search for images through themes, then 'standard' images including ones contributed by modules/blocks/courseformats/etc, outputting images efficiently from the perspective of expiry, caching etc. Again performance would be a consideration and in general that's way out of the scope of this change (it wouldn't be hard to do... but I'm behind schedule already).
--sam
There are also a few other things that really ought to be done (which I am realising as I make progress implementing mine). Two I have come across are:
1) They need their own language file (presumably format_myformat.php, like blocks), but perhaps this might have performance implications.
2) They may need their own icons. Unfortunately the Moodle infrastructure for image files clearly needs totally changing (well, creating, in large part), possibly via a themeimage.php file that does a hierarchical search for images through themes, then 'standard' images including ones contributed by modules/blocks/courseformats/etc, outputting images efficiently from the perspective of expiry, caching etc. Again performance would be a consideration and in general that's way out of the scope of this change (it wouldn't be hard to do... but I'm behind schedule already).
--sam
To clarify the language file thing, of course formats are free to use their own language files already, it's just specifically when getting the name of the course format, that one language string. Hm. Maybe I'll extend that too (so it works in either place) as it sucks to have to edit moodle.php if you install a new course format.
Yes, I also think that the scheme of handling themes and languages should to be seriously reconsidered. The trend to centralize CSS, language, and icons files is actually going against the grain of modularization and seems to be a regular support issue. Installing a plugin of any sort, be it a course format, an enrolment plugin, a question, a block, or a module, should require only dropping its folder into a correct place without having to move some files here and some files there, or modifying any existing files. Something for think about. A plugin should be self-contained. Or we need some standardized installation procedure.
Well, there's a difference between themes and languages.
Langages may be sucky but do fundamentally work (well, they will when Derek checks in his change to fix the order it looks for help files). It's possible to create a language, set it to inherit from (say) English, and there you go, everything (except help files at present, as above) works including support for _local language variants so sites can change some strings just for themselves.
Themes don't work correctly. You can set a theme to inherit from standard and most of it works (if you get the settings right) but the icons don't. There's some dodgy thing with an error handler which may resolve that (?) but I don't really think that is a good solution. It might be better than what we have here which is three copies of all the icons for three themes...
As for the language change I had an issue with here, it was worse than slotting in a file into an odd place - to add a course format you actually have to define its name in the moodle.php language file. However, having looked at the code and checked it's only used in two places, I will include a fix to that, so you'll be able to put course format names in the course format's own language file (format_whatever.php). Still has to go in the lang/whatever folder.
--sam
Langages may be sucky but do fundamentally work (well, they will when Derek checks in his change to fix the order it looks for help files). It's possible to create a language, set it to inherit from (say) English, and there you go, everything (except help files at present, as above) works including support for _local language variants so sites can change some strings just for themselves.
Themes don't work correctly. You can set a theme to inherit from standard and most of it works (if you get the settings right) but the icons don't. There's some dodgy thing with an error handler which may resolve that (?) but I don't really think that is a good solution. It might be better than what we have here which is three copies of all the icons for three themes...
As for the language change I had an issue with here, it was worse than slotting in a file into an odd place - to add a course format you actually have to define its name in the moodle.php language file. However, having looked at the code and checked it's only used in two places, I will include a fix to that, so you'll be able to put course format names in the course format's own language file (format_whatever.php). Still has to go in the lang/whatever folder.
--sam
I have now finished (I hope) and checked in this code, so if anyone other than me wants to make an advanced course format, you can. (So long as you are running the 1.8 HEAD development version, of course.)
It is documented in course/format/readme.txt although you'll need to understand how Moodle works in general (i.e. I wasn't going to explain how to do backup, in a 2 page readme).
--sam
It is documented in course/format/readme.txt although you'll need to understand how Moodle works in general (i.e. I wasn't going to explain how to do backup, in a 2 page readme).
--sam