Patrick Malley

Hey Tim,

Can you please give a case when these would be used in a theme? I'm assuming the purpose would be to give a different look for admins?

Hey Sam,

I'm referring specifically to this:

http://docs.moodle.org/en/Development:Themes_2.0#settings.php

In my opinion, the dock (specifically) should default to off. The theme can have a setting to turn it on. This could be the case for other theme settings, when appropriate.

My thought is that I probably won't use much of this dock in the themes I'll be creating right away. It may be confusing to the admin having a setting that does not apply to their theme. If a theme settings.php file exists, we should use it.

I've started my quest down the Themes 2.0 path this weekend and have (what will probably be the first of many) comments about what I'm seeing.

These comments deal directly with the options shown on the Themes Settings page:

1. Adding allowthemechangeonurl as an admin setting was a good idea; no more config.php hacking necessary to include session themes. I wonder though if the description shouldn't be a bit more explicit for users. It says the following can be entered at the end of a URL: theme={themename}&sesskey={sesskey}. Two questions: 1.) Is the sesskey necessary? If so, how does know what that is? I tried it without the sesskey and it worked just fine. 2.) you can't just put theme={themename} at the end of the URL. You'll need to put ?&theme={themename} or just &theme={themename} if the ? is already there. Not sure how this could be written more clearly, but it's not clear now.
2. If we're going to allow a "Settings" page for each individual theme, shouldn't the following settings be included in those themes if appropriate: allowuserblockhiding, allowblockstodock, showblocksonmodpages? My thought here is that these are three settings that won't be included in all themes. Not all themes will want to allow user block hiding, use the dock, or allow blocks on mod pages. These settings here only confuse the admin in cases where their theme doesn't allow them to use these features. I'm all about context appropriate options.

These aren't huge issues, I admit, but I think conversations like these are important to improving the overall usability of the software.

Thank you, Sam. This does help as I wondered why the additional code was added to the base theme.

I wonder if it wouldn't make sense to include these variables and classes as an underlying feature. Why must this be added to the top of every new layout that we create?

I'll try to implement this later today and will let you know if I still have trouble.

I've just committed my first 2.0 theme to CVS and could use some help with some issues I'm having with the layout templates and regions.

Whenever I navigate away from the front page, I get an error that reads:

"Coding error detected, it must be fixed by a programmer: Trying to reference an unknown block region side-pre"

Can someone (perhaps Petr) have a look at what I've done and provide some guidance on what I've done wrong.

At the end of the day, I'm not quite sure how the layouts work. I have an idea, but not enough of a grasp on it to solve problems like this. Any help will be greatly appreciated.

Patrick