where theme name prefix, subtype infix and target suffix are optional.

vs.

class theme_overridetest_core_renderer extends core_renderer {}

What we have added is the class definition for our first renderer. Note:

The name of the renderer is VERY important it is made up of three sections joined by underscores:

theme : This will always be the same when overriding renderers from the theme.
overridetest : This is of course the name of our theme, and should be the name of the theme the renderer is being overridden from.
core_renderer : This is the renderer that we are overriding.

It would be nice if I could leave the name of the theme off, as a) it means less typing, b) it would be easier for people to share and re-use renderers. Perhaps it was only suggested to use it since you need to make the classname different in some way from the class you are using, so we could all just use "theme" instead?

The idea of that tutorial showed me that you can actually have a theme that has all the renderers in it that other theme can tap into. The "overridetest" theme, which Sam created to explain how to create a renderer, can be used to house all your renderers. You would then need only a renderer.php in your theme that calls, by name, the renderer you want as each renderer would have it's own name similar to mod-choice-renderer.php in MDL-37523 (MyMobile theme) currently awaiting Integration Review.

I see it like using @import url('/css/styles.css'); except in PHP it become include_once or requires_once depending on the circumstances.

As for the nomenclature for the renderers peculiar to Moodle, well that's something you must take up with the Moodle DEVs.

David - I decided to learn Moodle and PHP5 plus relevant subjects over Christmas. My coding is well below 100%, but I made a lot of headway with both Themes and Course Formats by:

Taking an existing theme, and extending that, using the documentation above. For example, I implemented a totally new custom menu with:

"All Courses" (the code for that already existed, it just didn't work in 2.4, so I ammended the Theme wiki page to suit)

"My Courses" so the student can see what courses they are enrolled in

"Current Course" so students can drop the Nav block and still find the right part of their course

"Previous and Next" buttons, to step through a course section by section

I don't yet have permission to share, but hope to before the Dublin Moodlemoot.

Marina has also done some great work and documentation on Course Themes, so I have a new course format where the user never sees a wall of death or a section full of unclicked URLs, but rather skips from activity to activity.

Whatever you do - stick to the coding/naming requirements for render plugins, and see what others are doing, because that is a great clue.

I spent over a week trying to figure out why nothing was working, and when I added this, everything came into play.

Also not, this is also a good place to upgrade the default media sizes, which are way too small with

if (!defined('CORE_MEDIA_VIDEO_WIDTH')) {

// Default video width if no width is specified; some players may do something // more intelligent such as use real video width. // May be defined in config.php if required. define('CORE_MEDIA_VIDEO_WIDTH', 800);}if (!defined('CORE_MEDIA_VIDEO_HEIGHT')) { // Default video height. May be defined in config.php if required. define('CORE_MEDIA_VIDEO_HEIGHT', 700);}if (!defined('CORE_MEDIA_AUDIO_WIDTH')) { // Default audio width if no width is specified. // May be defined in config.php if required. define('CORE_MEDIA_AUDIO_WIDTH', 400);

Finally, when debugging gets painful, I keep the following in each php file, and just insert into a problem area and change the comments to single line // and update the function name and variable that goes into $printdebuginfo and $object to match what I am trying to debug (or better understand, when it comes to objects like modinfo

/* Insert where needed for debugging, and update object name in printdebuginfo and in print_object(mycourse->has_children)

...and which I use regularly to remind me how to do something. But have got things off to a fine art now I know my working pattern for fixing bugs.

To start off with Moodle you need to follow the help info in the GITHUB how to set up your local GIT repo (repository) on your own PC and then follow the Git for Devs (above link), and then how to FORK an existing Repo like https://github.come/moodle/moodle.git

Then if you get stuck ask for Help in the general Developers Forum. Someone will come to your aid as they did for me here...

I don't know if I'd agree that git is 'easy', even after you get used to it, but it is an incredible tool and nearly every week I discover something else amazingly useful that it does and so it certainly makes my life easier overall as a result, so it's well worth sticking through any early learning pains.

So I probably do things in a different way to most people, that's why I probably find it easy. I tend to look for easier options.

The only difficult thing I find with GIT, is when trying to get out of a fix. For example If you write the wrong command, as I sometimes do, that ends up doing something which, in effect, I told GIT to do, but not what I thought it was going to do, because I missed of a / or a .. or whatever, and getting out of these fixes can be a nightmare. However, with lots of help from Tim Hunt I have come up with my own crib sheet, that is much written on and very curled at the corners.

I've been using GIT for two years now, and can confidentally peer-review other's work on my local server and still mess with lots of themes which I have on back-boilers as well...so everything is looking rosey. But then that's perhaps my optimistic perspective...as I tend to view things through rose tinted spectacles.