Hi Paul,
Sideblocks are added through the front page admin interface, and not the theme.
To add more blocks to your site's front page, turn editing on while logged in as an admin and select the blocks you wish to display from the "Blocks" block that will appear.
Patrick Malley
Posts made by Patrick Malley
A lot of great stuff here. I don't disagree. I would like to add some support for a stripped-down base theme:
Every theme that I create a new theme, it includes my own default reset of Standard values. For example:
h2.headingblock {border-width:0 0 1px 0;}
.coursebox {border-width:0 0 1px 0; padding-bottom:10px;}
.categorybox {border:none;}
I could go on as this is but a small chunk of what I do from memory.
It would be great if we had a true base theme. I think that Base should continue to be Standard (stripped down to bare essentials), and the theme users see when they install Moodle should be called something else (like Default or Sandwich or whatever).
Separating module CSS into module stylesheets: It doesn't bother me as long as those stylesheets can be overridden at the theme level. I think it's a great idea.
Putting styles_layout.css, styles_color.css, and styles_fonts.css together: I've never liked this setup even if it is logical. I like to see all rules for a given element in one place. Therefore, it makes more sense to divide sheets by function (styles_admin.css, styles_frontpage.css, etc.).
Every theme that I create a new theme, it includes my own default reset of Standard values. For example:
h2.headingblock {border-width:0 0 1px 0;}
.coursebox {border-width:0 0 1px 0; padding-bottom:10px;}
.categorybox {border:none;}
I could go on as this is but a small chunk of what I do from memory.
It would be great if we had a true base theme. I think that Base should continue to be Standard (stripped down to bare essentials), and the theme users see when they install Moodle should be called something else (like Default or Sandwich or whatever).
Separating module CSS into module stylesheets: It doesn't bother me as long as those stylesheets can be overridden at the theme level. I think it's a great idea.
Putting styles_layout.css, styles_color.css, and styles_fonts.css together: I've never liked this setup even if it is logical. I like to see all rules for a given element in one place. Therefore, it makes more sense to divide sheets by function (styles_admin.css, styles_frontpage.css, etc.).
Thank you for the more thorough description of how the YUI CSS and layouts would work. It all sounds great to me.
If I understand correctly from the above, the only items from the theme that would be stored in dataroot would be the items changed via the admin interface using settings.php?
If I understand correctly from the above, the only items from the theme that would be stored in dataroot would be the items changed via the admin interface using settings.php?
That sounds perfectly reasonable to me - use the YUI reset and YUI font standards but develop a separate, more semantic, layout system that specifically suits our needs. I have no particular desire to move to Boilerplate except it's very lean and doesn't force specific classes upon the designer for specifying layouts. If we can get this same benefit from the YUI CSS, that's great.