Moodle in English: Thinking about Moodle 2.0 themes

Thinking about Moodle 2.0 themes

by Tim Hunt - Tuesday, 9 June 2009, 5:25 PM

I am trying to get back in to my work on Moodle 2.0 themes. There are some things I am thinking that I am not sure are right, so I wanted to write them out here and get some feedback.

1. A Moodle 2.0 theme will have header/footer.php files, not .html

header.html will have to change a lot because of what I am doing in Moodle 2.0. For example, it will be responsible for calling the function to print the blocks. Therefore I think it is better to have a new file name.

That way you can make a theme that works in both 1.9 and 2.0 by having both header.html and header.php files.

In a similar way, I may decide that Moodle 2.0 themes should have a lib.php file, instead of a config.php file, but I am less sure about that.

2. Should themes generate the <html> and <head> tags, or should moodle core do it?

If you look at what goes inside the <head> tag, there seems to be a lot of very technical stuff like the doc type, and links to JavaScript. All the existing themes seem to just copy-and-paste this. That is bad, because if we ever need to change it (like now, but this is an extreme example) all themes have to changed. (I hate duplicated code.)

So, the alternative is that moodle core prints everything up to and including <body ...>, and everything after </body>, and the theme just had to deal with the content of the <body> tag.

Of course, the theme would still be able to influence what happens in <head>, for example by controlling which style sheets and JavaScript are included.

So, what do you think?

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Andrea Bicciolo - Tuesday, 9 June 2009, 6:31 PM

Hello Tim,

1: I do not see disadvantages on using .php files rather than .html, especially if compatibility with older .html theme files is maintained. About lib.php, from a "semantic" point of view I'd prefer config.php, anyway it moslty depends on what will be contained in this file. Currently config.php contains mostly theme config settings, so the name looks fine; in case the file lib.php would contain functions, probably could be good to add it to the theme an leaving config.php.

2: my +1 for including from Moodle core. However, as you pointed out, a fine grained control of what is included as well as meta tag management is clearly useful.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Frank Ralf - Tuesday, 9 June 2009, 6:33 PM

Hi Tim,

ad 1)
As much as I don't like Moodle's habit of naming (nearly) every file .php (CSS files for example) I think this is a good suggestion for keeping themes backward compatible. And if header/footer are indeed calling functions they can righteously be named .php files

ad 2)
No, they (the themes) shouldn't, at least not the technical stuff, but it should be possible for them to override the core settings.

BTW, I had a look at how Moodle core provides the DOCTYPE setting the other day and found dozens of references. Shouldn't that be a central setting? But perhaps I only haven't understood the code correctly...

Cheers,
Frank

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Howard Miller - Tuesday, 9 June 2009, 6:56 PM

1. Good idea...

I err on the side of... "as soon as you have php in a file then it's .php"! I assume that all 'old' themes will be totally broken anyway?

2. Yes, but....

I would like the option to opt out. So if you want to bang all this stuff in a variable and the header file just echos it then it gives the option not to do it for some reason I can't think of.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Patrick Malley - Tuesday, 9 June 2009, 8:32 PM

I would like the option to opt out. So if you want to bang all this stuff in a variable and the header file just echos it then it gives the option not to do it for some reason I can't think of.

This sounds reasonable. My +1.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Patrick Malley - Tuesday, 9 June 2009, 8:30 PM

1. This breaks forward compatibility of existing themes, does it not? If old themes won't work on 2.0, every existing theme will need to be updated before the upgrade. Is there a way that this can be done so that header.html and footer.html are used if header.php and footer.php are not present in the file?

2. Absolutely leave <head> in the theme. Theme designers should be able to edit <head> however they see fit; don't restrict them any further than they already are. Just because most themes just copy and paste this code does not mean that all themes do the same.

If new functionality requires something to be added to head, add it as an include so that it can be easily added to existing themes by all.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Petr Skoda - Tuesday, 9 June 2009, 9:35 PM

I agree with Tim, <head> should be imo generated in core code and themes should just supply extra information.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Ray Lawrence - Tuesday, 9 June 2009, 10:29 PM

I can't comment on the technical aspects of this discussion but some backwards compatibility is highly desirable (although I understand this is a pest and an additional overhead for a while).

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Patrick Malley - Tuesday, 9 June 2009, 11:31 PM

As long as there is an opt-out, I don't see this as a problem. Otherwise, we'll just be placing more restrictions on what designers can do.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Tim Hunt - Wednesday, 10 June 2009, 11:47 AM

1. We are more likely to be able to maintain backwards compatibility if we change to header.php.

If Moodle 2.0 finds that a theme is missing header.php, but has a header.html, then it can try to use the header.html while fixing things up to mostly work.

However, I would be quite surprised if a Moodle 1.9 theme worked well in Moodle 2.0 without being updated. I think we have agreement on this. Good.

2. a. First let me say that if core does take over printing <head> themes will be able to override everything some way, probably using the renderer idea that themes will use to override the HTML everywhere else, not but writing things to variables that themes can then screw around with using regular expressions.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Tim Hunt - Wednesday, 10 June 2009, 12:28 PM

2 b. OK, so this is where we disagree. Both Patrick and Urs say "Theme designers should be able to edit <head> however they see fit" / "themes must be able to set up the complete XHTML structure".

However, neither of them say why.

Meanwhile I have just looked at the header.html files of all the themes in main CVS and contrib. Here are the things themes have done so far with the freedom they have to edit the HTML header:

custom_corners and derivatives, use about 20 lines of PHP code to add the class name inpopup/notinpopup to the body tag as appropriate. This would be must better elsewhere, not in the header template, and in Moodle 2.0 there is already a call $PAGE->add_body_class(...) that makes this easier to achieve, and there is the proposal that moodle core should add this type of body class name automatically.

wood_custom_corners does something even more complicated, buit similar to custom corners. It is 45 lines of PHP to screw around with the class names on body.

chameleon and derivatives conditionally includes a few .js and a .css file based on a whole bunch of PHP logic via an include('ui/chameleon.php').

The lines theme includes a whole chunk of static JavaScript in <head> (wouldn't this be better in a .js file?) via an include('js/yui.php'). (Incidentally, it was not XHTML strict because it has < signs and did not wrap the JS in a CDATA section. I just fixed that.)

ck_choices_standard and ck_choices_standard_logo include a couple of extra.js files.

moodle-contrib/patches/mobile/customscripts/theme/.../header.html (last updated in 2006) completely change <head> - they removes everything except the <title> tag.

nahuel theme addes a little bit of CSS inline in header, rather than adding it to the theme's .css files!

matias is quite amusing. It starts with about 500 form-feed characters, in an attempt to discourage people from copying and pasting his 'wonderful' HTML and CSS (there are some comments to that effect in there too). It adds an attribution to the keywords meta tag, and hard-codes some styles like bgcolor on the body tag. (That was last updated in 2004.)

by the way, quite a lot of themes omit the doctype declaration, or other things.

From this I conclude:

Themes need an easy way to add links to .js files to head - with the option to do this conditionally based on some PHP logic. They should also be able to add extra .css conditionally based on PHP logic.
It would not hurt if there was a place where they could conditionally call $PAGE->add_body_class(...) based on some PHP logic.
In extreme cases (e.g. mobile theme made in 2006 when mobiles were less capabile than they are today) they should be able to completely change the normal <head>, but there is not need for this to be easy.

All this reinforces my view that <head> should be output by moodle core, but I will still listen to reasoned arguments to the contrary.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Urs Hunkler - Wednesday, 10 June 2009, 2:27 PM

Tim,

I have written "Please don't forget, themes are for themers and not for programers." What is unclear with this sentence?

I have written several times about the designer's needs here in the forums. Themers or designers are skilled in XHTML. When we can set up the whole XHTML structure, we can much more flexible react on different needs. When Moodle outputs the header inclusively body tag we need to program to include changes.

Please try not to be restricted in your developer thinking. Try to understand designer thinking when you create a part of Moodle which is mainly used by designers.

And when you may decide to go your developer way please write a good and easy to understand documentation how we can override the Moodle core method creating the header to output the header as I posted. That would create more cost on our side to create the extra code but is better than the need to be forced to hack around in 2.0 as it is needed in 1.9 themes.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Frank Ralf - Wednesday, 10 June 2009, 7:52 PM

Hi Urs,

IMHO there's not much theming going on in the header section of a XHTML page. As long as a theme can insert its own CSS and JavaScript and override core settings I see no problem leaving the header to the programmers.

In fact, there are some settings in the header which IMO must be provided programmatically, for example the encoding setting. With Moodle sites in such a lot of different countries, languages, and writing systems, the default encoding of a Moodle site has to be set by the site administrator in the admin interface and hence inserted into the HTML by code.

A similar rationale goes for the DOCTYPE.

At least Moodle core must provide this information if the designer hasn't catered for it in the theme.

And Moodle core has to provide some kind of XHTML structure, so you cannot demand that designers be able to "set up the whole XHTML structure". Of course, what kind of XHTML structure this shall be is open to discussion.

Frank

Average of ratings: Useful (1)

Re: Thinking about Moodle 2.0 themes

by Patrick Malley - Wednesday, 10 June 2009, 8:53 PM

Urs's suggestion below would allow for this AND keep control of the XHTML in the designers' hands.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Patrick Malley - Wednesday, 10 June 2009, 7:00 PM

Tim,

First of all, this statement is a bit condescending:.

by the way, quite a lot of themes omit the doctype declaration, or other things.

I'm sure you didn't mean it this way, but I read it as saying that designers shouldn't be trusted with the code, therefore we should take it away from them.

I don't really care what a lot of themes do wrong. I don't write them. What I do care about is increasing the amount of flexibility in Moodle so that more good designers will want to work with Moodle. That is what Urs has been pushing for all along.

Here's a more practical reason why:

Designers work with XHTML and CSS. That is the language that they feel comfortable with. That is the area they have the most control. By taking control of «head» away from designers, you add another layer of complexity that is unnecessary.

You may argue that control is not being taken away. That javascript and other bits could be added via some PHP method. I add:

Imagine a great designer, one who has never worked with Moodle, is hired to create a theme, and he wants to add some custom meta tags, some javascript, and perhaps an alternative style sheet. He will soon realize that the tools he knows how to use to get this work done have been taken away from him by programmers. He will have to search the documentation and the forums for a method for including these items.

You have to ask yourself why systems like Wordpress have so many great themes being contributed, while Moodle has so few? Certainly, Wordpress has a wider user base, but another reason is because Wordpress takes things like designer choice simplicity into consideration when making programming decisions.

I want to see greater freedom in Moodle themes. Not less. Taking something away, and adding more complexity is completely undesirable.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Tim Hunt - Wednesday, 10 June 2009, 9:09 PM

I did not mean to be condescending. I was just trying to establish some facts about what types of flexibility had been useful (or otherwise) in the past, as one of the things to consider when deciding the best way forwards.

I found another interesting thing today: How does Moodle output the 'Skip to main content' link that is added to the start of Moodle page to improve accessibility? Answer, a nasty hack, becuase there was no way to get it added to the start of the <body> tag on all themes.

So, based on the evidence I have seen, core developers need to change what appears in head more often than people making themes. But I am still listening for possible counter arguments.

OK, so as requested, I am imaging a theme designer starting a new Moodle theme. I assume they are following the docs. So, they copy the standardwhite theme (or anomaly if you prefer). Then they open config.php and edit a list of CSS files they want included, and other settings, expressed in PHP. Why should JS be any different?

... errm ...

That is probably not what you wanted me to imagine. How did your version go?

I think we have establised that I do not understand the requirements of a typical designer - at least a typical designer as portayed here. It would certainly help me if I could understand, so please do not give up trying to explain. (I can't help noticing that all the people here who are trying to explain this mytical 'typical designer' to me are people who are perfectly capable of writing PHP code, which is someting of a mixed message.)

No one has yet shaken my view that HTML, CSS, JS, PHP are all just different types of computer language. Sure different people know different languages to different degrees, and people prefer to work with tools they are familiar with, but that does not mean that they are incapable of, say, editing a theme config.php file according to some docs, if that is the simplest way for them to convey the information they need to convey to Moodle.

There is, of course, a difference between declaritive langugages like HTML and CSS, and procedural languages like JS and PHP. And I assume that a designer is spending more time thinking in visual terms, rather than in code. I suppose I don't really understand what happens at the point were the visual thoughts have to be translated into edits of a CSS or HTML file.

On the other side, I will take this opportunity to tell you one thing about how developers think. Don't repeat yourself, and Once and only once, are absolutely fundamental principles for writing well-structured and easy to maintain code. Therefore, the idea that theme developers might prefer it, if they have to copy-and-paste a whole lot of standard, and fairly incomprehensible HTML in the the <head> of every theme they make, and have to remember to update it if necessary on every Moodle release, Is very difficult for me to understand. Surely it is better if Moodle does that automatically?

On the subject of Wordpress: isn't Wordpress a much 'smaller' application, so the amount of work in making a theme is necessarily much less?

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Patrick Malley - Wednesday, 10 June 2009, 9:46 PM

Points all well taken. I know you weren't purposely being condescending.

If we were to generate the header in the core, would it still be possible to insert any code into the header of the theme? Or just javascript or css files?

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Tim Hunt - Thursday, 11 June 2009, 11:29 AM

Well, as I left the office yesterday - with some code very much work-in-progress, then it a theme could get some JS linked to by adding a line like

$PAGE->requires->js('theme/mytheme/script.js');

to config.php. And that is just using code I wrote aimed at developers writing plugins, not thinking about people writing themes at all. It would, of course, be easy to make the theme_setup function (the one that loads config.php) do the function calls based on a new $THEME->scripts = array(...); setting if that seemed like a better solution.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Urs Hunkler - Wednesday, 10 June 2009, 4:10 AM

@1 header.php is perfect.

@2 themes must be able to set up the complete XHTML structure. Core generates content which is echoed out into the XHTML structure. The following will be good to handle.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html<?php echo $direction ?>>
<head>
    <?php echo $meta ?>
    <meta name="keywords" content="moodle, <?php echo $title ?> " />
    <title><?php echo $title ?></title>
    <link rel="shortcut icon" href="<?php echo $CFG->httpsthemewww .'/'. current_theme() ?>/favicon.ico" />
    <?php echo $css ?>
    <?php echo $header_javascript ?>
</head>
<body id="<?php echo $pageid ?>" class="<?php echo $bodyclasses ?>" <?php if( !empty( $bodytags ) ) echo $bodytags ?>>

</body>
</html>

Please don't forget, themes are for themers and not for programers.

Average of ratings: Useful (1)

Re: Thinking about Moodle 2.0 themes

by Tim Hunt - Wednesday, 10 June 2009, 9:25 PM

(PHP interpolated into HTML always looks horrible to me. I would much rather use string concatenation.)

If the following better or worse than Urs suggestion, and why?

<?php echo $doctype ?>
<html dir="<?php echo $direction ?>">
<head>
<?php echo $coreheadtags ?>
<title><?php echo $title ?></title>
</head>
<body id="<?php echo $pageid ?>" class="<?php echo $bodyclasses ?>"<?php echo $bodytags ?>>
<?php echo $corestartofbodytags ?>

</body>
<?php echo $coreendofpagetags ?>
</html>

We need those startofbody and endofpage bits for various reasons. For example, to solve the skip link problem, and also so we can link to most of the JS from the page footer.

And what about if, instead it was more like

<?php echo $doctype ?>
<html dir="<?php echo $direction ?>">
<head>
<?php echo $meta ?>
<?php echo $PAGE->requires->get_head_code() ?>
<title><?php echo $PAGE->title ?></title>
</head>
<body id="<?php echo $PAGE->id ?>" class="<?php echo $PAGE->bodyclasses ?>"<?php echo $bodytags ?>>
<?php echo $PAGE->requires->get_top_of_body_code() ?>

</body>
<?php echo $PAGE->requires->get_end_code() ?>
</html>

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Urs Hunkler - Thursday, 11 June 2009, 3:00 PM

, and everything after

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Tim Hunt - Thursday, 11 June 2009, 7:36 PM

I was only experimenting to try to make your proposal a future-proof as possible, and also to explore what was considered acceptable in a template. I am still not convinced it is the best way forwards.

By the way, I do like your idea of completely separate templates for home page, normal pages, and headless pages, rather than an ugly if statement in a single file.

Oh, and my proposal for header/footer.php could just as easily be start/end.html, if people think that those are better names.

And, as Martin pointed out, whatever I do in the standard themes, you or anyone else will be able to create an alternate theme engine that does things the way you like.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Stephen Macchia - Wednesday, 19 August 2009, 2:45 PM

I work as a designer and Front-end developer and you shouldn't be including JavaScript into the body. You should follow progressive enhancement and unobtrusive principles that are considered industry standards.

All JavaScript should be contained in external files and called from a DOM load statement or through DOM enabled event listeners. Will get to the other points in a proper reply post.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Tim Hunt - Friday, 21 August 2009, 9:55 PM

In Moodle 2.0 all the JavaScript is being moved out into separate .js files, as per Development:JavaScript_guidelines. We mostly have Sam Hemelryk to thank for cleaning up all the old JavaScript mess.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Stephen Macchia - Saturday, 22 August 2009, 6:16 AM

Ah good work

I was just curious how come YUI was chosen as the JS library? and not Jquery or Prototype? And no I am not whinging, I am curious as to the reason/s.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Tim Hunt - Saturday, 22 August 2009, 4:33 PM

Welll, if you look on Moodle docs in the JavaScript FAQ, ...

Basically the decision was made 2 (or was it 3) years ago, when a Google Summer of Code student had a project to implement some Ajax features. At that time they surveyed the available libraries, and there was an extensive thread in the General Developer Forum that lead to the YUI decision.

If we did the same exercise today, there is not guarantee that YUI would be chosen. On the other hand, we have used YUI for a while and have a lot of YUI code, so before changing, we have to consider the costs of that.

There is nothing to stop you using jQuery in your own customisations. Look at the require_js funciton.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Martin Dougiamas - Wednesday, 10 June 2009, 9:40 PM

Hi Urs,

Definitely themes are for themers, of course.

To me, the example header.php you give above is actually a perfect example of programming code that has almost nothing to do with the appearance of the theme. Moodle code does most of the hard work here by inserting data via the hooks into a strrrrict structure. The majority of theme designers don't need to change any of these things, they just need to be able to easily specify what css and javascript files they want to add.

I think it makes sense to make this part a PHP function. Of course advanced themers can still easily override that function if they really want to, inserting all the extra logic they need. And of course the "standardtemplate" theme can provide a header.html file in your format to do the job.

eg something like:

 

class standardtemplatetheme extends coretheme {

    function print_header() {

        global $PAGE;



        include($PAGE->themeroot.'/templates/header.html');

    }

}

I know Tim *is* thinking about simplifying the work required for a themer, and ALSO thinking about long-term maintenance. I can't remember how many times in the past I had to go through all the themes (core and contrib) updating the rather flaky header.html and footer.html to add/remove/fix changes happening in core. It was quite a lot.

However, thinking from a themer point of view I often wanted to insert HTML inside the BODY tags at the top or bottom, and I think that's very common. Too common to make themers edit PHP functions.

Do we need a standard bodyheader.html and bodyfooter.html to achieve this? Or is this enough of a reason to keep header.php and footer.php for the whole lot?

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Urs Hunkler - Thursday, 11 June 2009, 3:30 PM

Thanks Martin,

so you took 1 AND 2. For me the best way to continue will be to look at Tim's Implementation once it is ready and work from there.

One example for a contrary designer versus developer approach:
In my actual themes I use 3 templates for the <div id="header"> part - one for "header-home", one for "header" and one for "header-minimal". Lots of redundant code. Since I use this approach I clearly see at one glance how the header is built and can work in changes easily and fast. I don't mind copying the code over to the other templates.

With the code reduction approach in the normal theme header <div id="header"> part I always needed to think and try a lot before I could get the header changes working.

With the different templates approach I am faster and feel much more in control than with the code reduction approach. I can do my work more efficiently.

Tim makes the world more complicated when he thinks his developer view is the only and best way to go. Very, very wrong And his way of telling us that everything except his opinion is stupid is not very helpful either.

And Martin, your maintenance example shows a developer oriented development approach. User oriented approaches are needed for superior products.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Urs Hunkler - Wednesday, 10 June 2009, 6:09 PM

@Martin Dougiamas

Martin please give a clear statement about the Moodle theme strategy. People looking into Moodle theme work will know what to expect and developers know how to plan theme related code.

Shall Moodle Themes be 1. easy to work with for designers 2. program code like all other scripts

If you declare 1. as the main focus for themes Moodle developers must stop to treat themes like other Moodle code and engage more to understand designer's needs.

If you declare 2. as the Moodle way to handle themes I'll cry and will stop to further argue.

Average of ratings: Useful (3)

Re: Thinking about Moodle 2.0 themes

by Tim Hunt - Wednesday, 17 June 2009, 10:03 PM

I've been thinking some more.

More significantly, I have just had a fairly productive couple of day's coding, and I think I have implemented most of the back-end behind http://docs.moodle.org/en/Development:Theme_engines_for_Moodle%3F. It is not actually hooked up to anything yet, so you can't use it (that is the next few day's work) however it passes all it's own unit tests, and the code is attached to MDL-19077 if you are interested.

It will probably be easier to look at in a couple of weeks when I have completed the initial implementation, so the new code is actually being used for real, and written http://docs.moodle.org/en/Developement:How_Moodle_outputs_HTML to explain it. At that point I will need comments in whether it is really a step forwards, and how it can be improved further.

But back to the things I was thinking about.

I had one good idea today. If we are changing from header.html and footer.html to something else, then why not change to a single pagelayout.html. All that we need is that somewhere in the middle of that file, you have a distinctive string (I suggest 'MAIN CONTENT GOES HERE'), then moodle can load that one file and slice it in half by finding that string to get the header and footer content.

I am still undecided about the best way to do <head>.

A. The best performance and cleanest code in core Moodle comes from having pagelayout.html contain just the HTML that goes inside the <body> tag, and have Moodle generate the rest.

B. A nicer thing for designers to work with (in the short term, if not for long-term maintenance) is if pagelayout.html is a complete HTML page with embedded PHP function calls and echoing variables where necessary. That is, basically a concatenation of what we have in header.html and footer.html at the moment.

Those two are basically what we discussed above. I now have a third option

C. Have pagelayout.html be a complete HTML page, but then Moodle core throws away the <head> tag it finds and generates a new one. That might work better for long term maintenance. It might also mean that when you are editing pagelayout.html in dreamweaver or whatever, you can put whatever hardcoded links to the CSS you need to make thing look right while editing, safe in the knowledge that Moodle will overwrite them.

As I say, I still don't know what to do. Fortunately, I am pretty sure that that part of the code will be relatively easy to change later if what I do at first does not work out. So I am just going to keep going for now.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Patrick Malley - Thursday, 18 June 2009, 12:12 PM

Two thoughts:

1.) Wouldn't it be pagelayout.php and not pagelayout.html?

2.) pagelayout.php is not very nice. Why not just layout.php or page.php?

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Tim Hunt - Thursday, 18 June 2009, 2:25 PM

You are right. Of those, I like layout.php best.

Also remember Urs's suggestion that actually we start having a few files like

layout.php, layout-popup.php, layout-home.php, ...

That seems sensible to me, but should be optional. That is, if a layout-thingy.php file exists (where thingy is $PAGE->generaltype) use that. If not use layout.php.

By the way, I just read the article about OOCSS which Frank linked to yesterday. I think it is recommending a similar approach to what I have been saying, that is that it is best if Moodle HTML is built up from what they call reusable objects. Anyway, I second Franks's recommendation that it is an article worth reading and thinking about.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Frank Ralf - Thursday, 18 June 2009, 7:34 PM

If we build Moodle HTML from "reusable objects" as building blocks - which is a good idea - then we should do the same with the respective CSS (for my mixed feelings regarding the concept of OOCSS see the above mentioned thread).

That's where IMO the "Moodle CSS file structure" is still open to debate (http://moodle.org/mod/forum/discuss.php?d=108771).

Cheers,
Frank

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Stephen Macchia - Wednesday, 19 August 2009, 3:14 PM

One of the main problems with having a single file named "pagelayout" it could potentially be very very very long if a proper theme engine was devised and visual control was given to Designers and Front-end developers, who get paid to work with visual concept, aesthetics, accessibility and usability.

From what you are proposing above, with "Moodle chopping the page in half" is pretty much what exists now.

The reason why the Wordpress theme system and "Wordpress tags" work so well is because you can control pretty much everything. Developers "develop" the code and designers "design" and create how that should be displayed.

Alot of the problems with Moodle and the reason why so many Themes are quiet visually poor are because the developers control the middle part of the screen, apart from CSS over rides (which is another complaint about file size and superfluous markup for another day).

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Tim Hunt - Friday, 21 August 2009, 10:14 PM

Yes, but Moodle code does not currently work the way Wordpress code does. Over the years, we, the moodle community, teachers and developers working together, have accumulated three quarters of a million lines of code that implements the functionality that teachers find helps them to teach. Moodle has always focussed more of teachers than software architecture.

Are you proposing we throw all that away?

Well, we chose not to. After much thought we came up with a proposal to greatly increase the control that designers could have, while at the same time only requiring minimal updates to existing Moodle code. That is what we have implemented in Moodle 2.0. It is a big step in the right direction, far bigger that I thought would be possible 9 months ago.

I am really looking forwards to what skilful theme designers like Patrick can do with the new possibilities.

If you think you can do better, please go ahead. Good luck. Please do not just whinge about how Moodle does not work the way you are familiar with, without offering constructive suggestions.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Stephen Macchia - Saturday, 22 August 2009, 6:28 AM

I would hardly say I was suggesting that Moodle and its functionality being scrapped, nor having a whinge. Perhaps maybe you might read it as a constructive suggestion for a path to be aiming for, rather than shoot me down. I only suggested wordpress and its theme engine because of its ease of use and available control.

Maybe if you looked and were familiar with the system it might help to further push the visual capabilities of Moodle and therefor eLearning teaching.

Average of ratings: -

Re: Thinking about Moodle 2.0 themes

by Tim Hunt - Saturday, 22 August 2009, 4:28 PM

Perhaps I am oversensitive, having heard similar complaints put in very unhelpful ways by other people in the past. My apologies.

Average of ratings: -