I'm investigating in Moodle 2.0 theming and am pleased with the possibilities. Many of my old dreams how to work on Moodle Themes seam to have come true.
But where there is light there is also shadow:
Moodle 2.0 themes are a whole new world. When I started to investigate more in Moodle 2.0 I felt close to having never worked with Moodle before.
The all different theme structure, files and CSS demand intensive exploration. Looking at existing themes, mainly the base and canvas theme, becomes important.
To be able to understand the applied CSS rules is an important base to be able to write well functioning CSS in my themes. To be able to understand CSS rules I need to be able to read the existing CSS. The one line CSS rules in base and canvas are horrible to read. It takes time to convert them to a readable format - and that work needs to be done after each theme update.
Sam opened the tracker issue MDL-22351 - but nothing happened. In an old posting Sam writes that time is lacking. To take the CSS trough one of the several CSS beautifiers takes an hour or so. If this work would be done once for Moodle core Moodle CSS would become so much easier to understand out of the box.
The chance that well working CSS without unnecessary overwrites will be written will increase with good readable Moodle base CSS. So please someone convert the CSS to a readable format.
I agree. Please see: MDL-25511
Hi guys,
Ok a couple of things here, first the one line format:
For those who want to know why it was converted to a singleline format it was because it is was much much easier for me to move through the theme's CSS removing unnecessary CSS such as redundant styles, duplicate rules etc. It also made it easier to join the pre-existing combination stylesheets into single core cheets and made it easier to split the CSS based on its component into component sheets that live within the components directory (forum etc).
To be truthful I personally like it, I find it much easier to read the structure of a page and formulate the design based upon that, adding the styles is really just putting what I have on paper (on in gimp) into code.
That all being said I completely understand that its not everyone's cup of tea, it is a change from just about every online resource on how to create CSS, and I have no problem with it being converted back to a multiline format.
That initial tasks of converting the themes for Moodle 2 only needed to happen once, never again, and when we (shortly) move to GIT everything will be getting reviewed before commit so we can manage the changes going on to make sure no silly CSS gets added (by the way it is very rarely the themers that create silly css, its normally the developers).
The second issue is the beautifiers and MDL-22351, this is still unfortunately very low on my priority list simply because it works, yes inconvenient but not broken as such. I'm happy with a beautifier being used providing it doesn't mess anything up... hehe so as long as it is trustworthy. Oh and as long as it doesn't put tabs in, I hate finding tabs! but they are easily converted. :D
Cheers
Sam
Ok a couple of things here, first the one line format:
For those who want to know why it was converted to a singleline format it was because it is was much much easier for me to move through the theme's CSS removing unnecessary CSS such as redundant styles, duplicate rules etc. It also made it easier to join the pre-existing combination stylesheets into single core cheets and made it easier to split the CSS based on its component into component sheets that live within the components directory (forum etc).
To be truthful I personally like it, I find it much easier to read the structure of a page and formulate the design based upon that, adding the styles is really just putting what I have on paper (on in gimp) into code.
That all being said I completely understand that its not everyone's cup of tea, it is a change from just about every online resource on how to create CSS, and I have no problem with it being converted back to a multiline format.
That initial tasks of converting the themes for Moodle 2 only needed to happen once, never again, and when we (shortly) move to GIT everything will be getting reviewed before commit so we can manage the changes going on to make sure no silly CSS gets added (by the way it is very rarely the themers that create silly css, its normally the developers).
The second issue is the beautifiers and MDL-22351, this is still unfortunately very low on my priority list simply because it works, yes inconvenient but not broken as such. I'm happy with a beautifier being used providing it doesn't mess anything up... hehe so as long as it is trustworthy. Oh and as long as it doesn't put tabs in, I hate finding tabs! but they are easily converted. :D
Cheers
Sam
Good documentation makes the work easier for theme developers/designers. Good documentation is also essential for theme quality.
By the way Sam, the documentation you have written in the Moodle docs wiki is really good. Thanks for that huge help to understand Moodle 2 themeing.
Having easily readable CSS is part of a good documentation. So please change the one liners to a human readable format.
Smashing Magazine published an interesting article how formatting supports understanding. "The Poetics Of Coding"
In reply to Urs Hunkler
Re: Moodle 2.0 theming - applying font formatting to the body tag issue
by Urs Hunkler -
Moodle CSS lays a font fundament with the well thought YUI CSS reset and YUI CSS fonts rules. YUI has investigated some effort to make text look more similar on the different browsers. When you have a look at YUI 3: CSS Fonts you may see what I mean. These font rules are set on the body tag.
When in any theme font related definitions are assigned to the body tag the base system breaks - as done in "text.css" in canvas for example. Many advantages using the YUI CSS font rules are thrown away.
To keep the advantages add font related rules to a subsequent element like "div#page" in all themes. On the above mentioned web page YUI publishes a table on font size values you can use to set certain text sizes - working the same in many different browsers out of the box.
By removing the font-size from the body tag and setting the font size in text.css in the canvas theme to "font-size: 108%" for "#page" I verified that the expected 14px font size in the themes are set.
So please keep the font handling advantage given with the YUI CSS system and add your rules to a subsequent element. Patrick, would you mind to correct the CSS rule in canvas?
In reply to Urs Hunkler
Re: Moodle 2.0 theming - applying font formatting to the body tag issue
by Urs Hunkler -
Patrick - or anybody else - do you agree or disagree with my proposal?
In reply to Urs Hunkler
Re: Moodle 2.0 theming - applying font formatting to the body tag issue
by Thomas Hanley -
Urs,
Yes I agree, typography is very important in design and any CSS strategy that enables theme designers to achieve consistent cross-browser type display gets my vote.
~thomas
In reply to Urs Hunkler
Re: Moodle 2.0 theming - applying font formatting to the body tag issue
by Patrick Malley -
Sorry it took an additional prod to get me to respond. Been quite busy with 2.0 upgrades lately. I have looked at the YUI 3 CSS font guidelines and have added MDL-25512 to make the change.
In reply to Urs Hunkler
Re: Moodle 2.0 theming - applying font formatting to the body tag issue
by Sam Hemelryk -
This ones easy, it certainly has my +1. Thanks for creating an issue to undertake it Patrick.
In reply to Urs Hunkler
Re: Moodle 2.0 theming - file structure in the theme folder
by Urs Hunkler -
To get well structured theme directories with the advantage to easily know where to look for certain files is wise to propose and use for the Moodle 2.0 themes.
To restrict file linking to images, CSS and JavaScript files to one predefined directory as done in Moodle 2.0 does not help at all - in the opposite it is destructive to our theme design work.
I want to port the "plugin" structure I have developed for my themes to Moodle 2.0. One "plugin" covers a certain topic and contains all CSS, images, JavaScript etc. necessary for this topic in one folder. To use this topic in different themes means to copy the "plugin" folder to another theme and activate it - that's all. With the given Moodle 2.0 theme folder restrictions I can forget the "plugins" and their advantages.
Because I want to continue working with "plugins" I can not accept these restriction. I searched for workarounds - with different success:
- JavaScript was easy - adding "../" and the new path to the array in the theme config file does the trick like
$THEME->javascripts[] = '../' . $differentpath . '/modernizr-1.6.min'; - CSS gave some issues. adding "../" and the new path to the array in the theme config like
$THEME->sheets[] = '../' . $differentpath . '/test';works in production mode but not in design mode. Moodle strips all path related characters from the given name in design mode. I hacked "styles_debug.php" to deliver CSS in design mode correctly from other directories in the theme folder. For my development installation this solution I can live with for now. - Images I could not find any workaround for using the great Moodle file caching system. The only way around for me is to deliver the images directly with a CSS rule like "background: #fcfcfc url('custom:themedirurl/themename/differentpath/img/noise.png'); and a function for "csspostprocess" to replace custom:themedirurl with the URL to the theme folder. Quite bad, isn't it?
To solve the image issue would be quite easy just by adding one condition to the "resolve_image_location" function in the outputlib to set the theme directory as base instead of the pix directory. No existing theme would be touched.
if ($imagefile = $this->image_exists("$this->dir/pix/$image")) {
return $imagefile;
}
// start change uh 2010-11-22
if ($imagefile = $this->image_exists("$this->dir/$image")) {
return $imagefile;
}
// end change uh
Please remove these restrictions within theme folders in Moodle 2.0. They make no sense, as far as I see. But they are a huge annoyance for experienced theme designers.
In reply to Urs Hunkler
Re: Moodle 2.0 theming - file structure in the theme folder
by Sam Hemelryk -
Hi guys,
I must say Urs thank you for raising these topics, this one in particular is going to interesting.
I very much expect for this that people are not going to like my initial answer, but please read my full post and you'll see where I'm heading with my thoughts.
Its pretty simple the directories that are used were chosen to keep themes organised in a routine way which is both easy for the inexperienced and predictable for Moodle and its developers.
For those two reasons alone I would not immediately go off and add in additional places to look for resources.
Some of the technical reasons I'd steer away from it are:
Overriding images, one of the big things with images is that a theme can override the images its parents use. The changes you have to code Urs will work sure enough but if a new theme was to extend your theme it would not be able to override those images and in fact Moodle would not be able to find those images at all.
The work around is to introduce a similar change to into the looping check that follows that code but then that's adding to the massive performance hole that Moodle 2.0 themes already generate.
It is pretty much the same story with CSS and JavaScript, there is nothing to stop us adding more locations to search for these resources but each new location represents more of a performance hit.
Performance by the way is one of the biggest factors Martin wants us to look at with 2.0.1 and future releases. For now we need to slim the bohemoth we've created.
One other thing to take into consideration is that themes may not always be served from the theme directory, there was a bit of talk about a mysterious new ability to host themes from within the moodledata directory. I've just spend a couple of minutes checking and I can confirm its not presently possible but I will need to talk to Petr to make sure I haven't missed something or that this wasn't forgotten from theme redevelopment.
If it is true and this functionality is going to exist soon then you cannot guarantee a web accessible path at all. I'd put this is the `Maybe a roadblock` pile.
There is one obvious workaround nee solution to this problem that springs to mind every time I read over this post (I must've read it dozens of times now trying to write this reply).
You could split your plugin's off into themes. This is personally how I work. I have a couple of themes that do nothing but introduce specific functionatliy, or make very specific generalistic changes.
Each of these themes extends base and standard but also sets $THEME->hidefromselector = true so that it cannot be selected. The reason it extends base and standard is so that I can turn on $CFG->allowthemechangeonurl = true, switch to my theme on the URL and then develop the functionality without having to worry about conflicts or errors from the theme I am planning to use it with.
Some of the things I've used this for:
* Overriding the ugly icons in Moodle: I created a theme called silk which overrides the icons with the famfamfam silk icons which I like.
* Enhancing the dock: I made a theme that changes the way the dock behaves, it allows me to move the dock, and changes the way a couple of things happen and events trigger.
Once you have created the plugin as a theme it is as simple as setting it as a parent to make use of it!
Personally if this practically fits with the plugins you have/want I'd do this.
Ok so lets say that the above idea doesn't appeal to everyone.
Conceptually I think the following may be a good solution to this problem.
We could theoretically introduce a new $THEME config option:
This would allow you to specify one or more additional locations in which to search for images, css, and JS.
Why use the setting rather than just search everywhere anyway, because it localises the search when looking at a chain of extending themes. Rather than search several locations in all themes we continue searching for the general locations and then also search the specified additional locations for the theme plus any themes that extend it (so that they could override if required).
This of course would keep the standard structure the same as it is and easy to understand "Put your images in /pix/" whilst giving those who want to explore the deeper reaches of theme design/development the flexibility to specify additional locations.
At this point I will stop and let those interested process what I have written, please let me know your thoughts on this and what you think is the way to proceed. Also whether I have missing anything including the point
Cheers
Sam
I must say Urs thank you for raising these topics, this one in particular is going to interesting.
I very much expect for this that people are not going to like my initial answer, but please read my full post and you'll see where I'm heading with my thoughts.
Its pretty simple the directories that are used were chosen to keep themes organised in a routine way which is both easy for the inexperienced and predictable for Moodle and its developers.
For those two reasons alone I would not immediately go off and add in additional places to look for resources.
Some of the technical reasons I'd steer away from it are:
Overriding images, one of the big things with images is that a theme can override the images its parents use. The changes you have to code Urs will work sure enough but if a new theme was to extend your theme it would not be able to override those images and in fact Moodle would not be able to find those images at all.
The work around is to introduce a similar change to into the looping check that follows that code but then that's adding to the massive performance hole that Moodle 2.0 themes already generate.
It is pretty much the same story with CSS and JavaScript, there is nothing to stop us adding more locations to search for these resources but each new location represents more of a performance hit.
Performance by the way is one of the biggest factors Martin wants us to look at with 2.0.1 and future releases. For now we need to slim the bohemoth we've created.
One other thing to take into consideration is that themes may not always be served from the theme directory, there was a bit of talk about a mysterious new ability to host themes from within the moodledata directory. I've just spend a couple of minutes checking and I can confirm its not presently possible but I will need to talk to Petr to make sure I haven't missed something or that this wasn't forgotten from theme redevelopment.
If it is true and this functionality is going to exist soon then you cannot guarantee a web accessible path at all. I'd put this is the `Maybe a roadblock` pile.
There is one obvious workaround nee solution to this problem that springs to mind every time I read over this post (I must've read it dozens of times now trying to write this reply).
You could split your plugin's off into themes. This is personally how I work. I have a couple of themes that do nothing but introduce specific functionatliy, or make very specific generalistic changes.
Each of these themes extends base and standard but also sets $THEME->hidefromselector = true so that it cannot be selected. The reason it extends base and standard is so that I can turn on $CFG->allowthemechangeonurl = true, switch to my theme on the URL and then develop the functionality without having to worry about conflicts or errors from the theme I am planning to use it with.
Some of the things I've used this for:
* Overriding the ugly icons in Moodle: I created a theme called silk which overrides the icons with the famfamfam silk icons which I like.
* Enhancing the dock: I made a theme that changes the way the dock behaves, it allows me to move the dock, and changes the way a couple of things happen and events trigger.
Once you have created the plugin as a theme it is as simple as setting it as a parent to make use of it!
Personally if this practically fits with the plugins you have/want I'd do this.
Ok so lets say that the above idea doesn't appeal to everyone.
Conceptually I think the following may be a good solution to this problem.
We could theoretically introduce a new $THEME config option:
$THEME->additional_resource_locations = array('relative/location');
This would allow you to specify one or more additional locations in which to search for images, css, and JS.
Why use the setting rather than just search everywhere anyway, because it localises the search when looking at a chain of extending themes. Rather than search several locations in all themes we continue searching for the general locations and then also search the specified additional locations for the theme plus any themes that extend it (so that they could override if required).
This of course would keep the standard structure the same as it is and easy to understand "Put your images in /pix/" whilst giving those who want to explore the deeper reaches of theme design/development the flexibility to specify additional locations.
At this point I will stop and let those interested process what I have written, please let me know your thoughts on this and what you think is the way to proceed. Also whether I have missing anything including the point
Cheers
Sam
In reply to Sam Hemelryk
Re: Moodle 2.0 theming - file structure in the theme folder
by Urs Hunkler -
Thanks Sam for your detailed explanations.
I didn't want to add additional places to search files. My proposal would be to set the theme folder as base and start each file with a path within the theme folder. In the moment each file type has a different fixed base folder:
- CSS includes now look like 'stylefile' :: after the change they can look like 'styles/stylefile' or 'myfolder/css/stylefile'
- JavaScript includes now look like 'myjs' :: after the change they can look like 'javascript/myjs' or 'myfolder/js/myjs'
- Image includes now look like '[[pix:theme|image1]]' or '[[pix:theme|subfolder/image2]]' :: after the change they can look like '[[pix:theme|pix/image1]]' or '[[pix:theme|notpixbutmyfolder/img/image2]]'
This solution demands a bit more typing for theme designers, no additional speed issues and the convenience to use a flexible folder structure which fits the theme needs.
And I think overriding in child themes still works.
And when I understand Moodle caching right file search is only done when a file is not cached. In normal production mode Moodle delivers the compacted files from the cache. This way the place where the files are originally saved does not matter at all.
In reply to Urs Hunkler
Re: Moodle 2.0 theming - file structure in the theme folder
by Urs Hunkler -
I created the Moodle Tracker issue MDL-25690 and gave the "feature request" a "Major" priority because for more complex themes a flexible directory structure is essential.
Sam, any new insights from your side?
Everybody who agrees may vote for the issue.
In reply to Sam Hemelryk
Re: Moodle 2.0 theming - file structure in the theme folder
by Urs Hunkler -
At your proposal to use a "theme" for adding special functionality sounds promising and strange in the same time.
After thinking about your proposal I discover that the way to use a parent theme as "plugin" comes very close to the way I am using the plugins within themes now.
Some questions:
- Is the config file and the pix folder with the icons enough for your icon parent theme? No other folders or files would be needed?
- What happens with routines in lib.php? Can they be used by child themes?
- Can custom renderers be used in child themes when they are defined and activated in parent themes?
- Can parent themes and child themes use all defined custom renderer methods no matter in which theme in the parent theme chain it is saved?
- Can child themes add methods to existing custom renderers defined and activated in parent themes?
- In which 'plugin' theme the possibly used construct method "function __construct( moodle_page $page, $target )" would be used? Must be in the first one? It can't be used twice, right?
- Is there a speed issue when I add lets say 12 parent themes for 12 different enhancements?
I wrote I find using themes as plugins "strange" because the word theme does not fit with the task of a plugin. A theme is and does much more than a special feature plugin. But this is a communication/terminology and not a development aspect.
In reply to Urs Hunkler
Re: Moodle 2.0 theming - file structure in the theme folder
by Urs Hunkler -
Sam, did you have some time to investigate in answers to my questions?
In reply to Urs Hunkler
Re: Moodle 2.0 theming - file structure in the theme folder
by Sam Hemelryk -
Hi Urs,
Going through the questions in the same order that you laid them out:
1. The pix folders + config.php is all you need, in my case I also have one stylesheet the tidies up the widths/heights of some images so that browsers render without jumps. The content of the silkicons config.php file is:
2. Yes, child themes are able to use functions within parent themes. I would recommend if you need to do this to create functions within the child's lib.php that simply call the parents function. This way if the parent evolves in a way unsuitable for the child you can just change the content of the childs function rather than having to search+replace all uses of the child function.
e.g.
3. I haven't tested this however the logic is that only one theme renderer is being used, it is either the parent theme's renderer or the child theme's renderer.
It is possible to create a child renderer that extends the parent renderer however it can be based on only 1 renderer.
So if your child theme had several parents you could would only be able to use the renderer from one.
I've just had a quick look at code and I think that it would be possible without being too difficult or breaking backwards compatibility to come up with a method of chaining renderers so that you could have a theme with a renderer that could use the renderers of all its parents. I'll create a tracker issue for it after this reply although being that 2.0 has been released now I don't imagine it will get in any time before 2.1.
4. Presently if the child renderer extends the parent renderer then it is able to use all of the methods that the parent renderer has, yes.
5. A child can define any methods it wants and as above if it extends a parent renderer it can use the parents methods. As well as this if the child theme wants it can override any method the parent renderer defines allowing it to customise the parent renderers output.
6. The construct method is ALWAYS called on the top most theme, so in the case of theme renderers it is always the current theme renderers construct method that gets called. For this reason I would strongly urge you not to override a theme's constructor, unless you do things correctly it can break alot of stuff.
7. The first time a recourse is accessed there will be a speed issue, depending on how far down the parent chain Moodle has to look to find things however they are cached after the first request and then served quickly again. Or course when using developer mode things will always go slower ;).
Cheers
Sam
Going through the questions in the same order that you laid them out:
1. The pix folders + config.php is all you need, in my case I also have one stylesheet the tidies up the widths/heights of some images so that browsers render without jumps. The content of the silkicons config.php file is:
$THEME->name = 'silkicons';
$THEME->parents = array('standard', 'base');
$THEME->sheets = array('silkicons');
2. Yes, child themes are able to use functions within parent themes. I would recommend if you need to do this to create functions within the child's lib.php that simply call the parents function. This way if the parent evolves in a way unsuitable for the child you can just change the content of the childs function rather than having to search+replace all uses of the child function.
e.g.
// Within the parent lib.php
function theme_parent_dosomething() {
// Heaps of code to do cool stuff.
return $html;
}
?>
// Within the child themes lib.php
function theme_child_dosomething() {
if (function_exists('theme_parent_dosomething')) {
return theme_parent_dosomething();
}
}
3. I haven't tested this however the logic is that only one theme renderer is being used, it is either the parent theme's renderer or the child theme's renderer.
It is possible to create a child renderer that extends the parent renderer however it can be based on only 1 renderer.
So if your child theme had several parents you could would only be able to use the renderer from one.
I've just had a quick look at code and I think that it would be possible without being too difficult or breaking backwards compatibility to come up with a method of chaining renderers so that you could have a theme with a renderer that could use the renderers of all its parents. I'll create a tracker issue for it after this reply although being that 2.0 has been released now I don't imagine it will get in any time before 2.1.
4. Presently if the child renderer extends the parent renderer then it is able to use all of the methods that the parent renderer has, yes.
5. A child can define any methods it wants and as above if it extends a parent renderer it can use the parents methods. As well as this if the child theme wants it can override any method the parent renderer defines allowing it to customise the parent renderers output.
6. The construct method is ALWAYS called on the top most theme, so in the case of theme renderers it is always the current theme renderers construct method that gets called. For this reason I would strongly urge you not to override a theme's constructor, unless you do things correctly it can break alot of stuff.
7. The first time a recourse is accessed there will be a speed issue, depending on how far down the parent chain Moodle has to look to find things however they are cached after the first request and then served quickly again. Or course when using developer mode things will always go slower ;).
Cheers
Sam
In reply to Sam Hemelryk
Re: Moodle 2.0 theming - file structure in the theme folder
by Sam Hemelryk -
I should add regarding the notion of using theme's as plugins that there are still PLENTY of dark corners to that plan. For the more basic operations like overriding images, custom JavaScript things work well, the theme system has been designed to cope with those things nearly completely automatically. Other areas such as settings pages, lib file functions etc require more work to utilise, and renderers are cool but as discussed above they still need development, and we still need to convert much of Moodle to use them, unfortunately a job that will likely take years.
Whilst I'd love to promise the world when it comes to theme's and output I simply can't, Moodle 2.0 has been released and presently we arn't working on any new development or improvements to Moodle core, all efforts are being put into fixing immediate bugs and in-house projects such as the migration to our new versioning system (Git). Because of this new development will likely move foward slowly for the next couple of months, I would suggest that if there is something out there that you really want, produce a patch for it.
Cheers
Sam
Whilst I'd love to promise the world when it comes to theme's and output I simply can't, Moodle 2.0 has been released and presently we arn't working on any new development or improvements to Moodle core, all efforts are being put into fixing immediate bugs and in-house projects such as the migration to our new versioning system (Git). Because of this new development will likely move foward slowly for the next couple of months, I would suggest that if there is something out there that you really want, produce a patch for it.
Cheers
Sam
Sam, if you may have some time can you please check and hopefully investigate into the topics I described.
Thanks a lot for your support and the fast reactions on last tracker issues I reported.
Thanks a lot for your support and the fast reactions on last tracker issues I reported.
I was wondering when someone might answer this post of your Urs...it's taken them long enough.
Needless to say you have my support in all you are asking for on these issues...and I agree with it all, especially the CSS stuff and the fonts too.
Cheers
Mary