David Scotson

You should be able to repeat what you've done for the header, for the footer.

You just want to move the footer out of the div#page.container-fluid, and at that point you might want to put the content within the footer back inside a div.container-fluid like you've done with the header to keep the content in line with the rest of the page, even though the header goes wider to make the blue banner.

Hmm, just looking at the code it's not obvious where the divs are closed. I've I could find them then cut'n'pasting above the footer tag wouldn't be particularly tricky, but they're not very obvious. Looking at the source returned by your page, it looks like there's no closing div tags after the footer tag, so they're just being allowed to close themselves.

So you need to add some closing divs just above the footer until all the divs are closed.

It's a bit of a tangent but it seems that from a code development point of view Blocks are easier to create than Resource or Activity plugins. I'm not sure why this should be, I can't see any fundamental reason for it, but I think you'll find quite a few 3rd party Blocks that would have been better as Activities or Resources. And any move away from using Blocks will be resisted by people who need that functionality (though not necessarily in a block).

I think part of it is the desire to control the caching of assets. So instead of pointing to the URL of the file, you have some clever PHP code that fetches and returns the file and can do . Once that becomes the norm, you can get away with hiding your themedir from the web without breaking core functionality.

Assuming that's true then themewww should be phased out, since you can no longer rely on it.

Yep, but that's either a choice or an oversight. Moodle release notes could just say "theme directories must be web accessible, if you use a non-standard directory then set $themewww" and the problem would be "solved" (or rather defined to not be a problem any more).

But did anyone actually ever make this decision? Or did people just fix individual bugs as people reported problems without stepping back to look at the big picture, till we get to the point we are in today, where adding a font file becomes very tricky because you've got no guarantee of where the theme files will be located and so, instead of a url you need complicated PHP code just to serve up a logo, a font or an image. Except the obvious approach will work more than 9 times out of 10, so no one actually does this and Moodle Themes just seem a little bit unpredictably broken and unreliable.

The very existence of $themewww seems to suggest that theme directories are intended to be web accessible, otherwise what's the point of that variable? But maybe a decision was made at some point since then, I'd be interested in reading the reasoning behind supporting non-web accessible theme dirs if this was a planned change.

How does all this relate to $themewww? Does Moodle actually support theme dirs that are not web accessible? That seems to be the root issue here. If so, is that a good idea? To me it seems like a lot of extra complicated work for no obvious benefit.

http://docs.moodle.org/dev/Theme_directory_guide