Moodle in English: HEADS UP: Major theme changes landing

Go, Petr, go!

Average of ratings: -

Permalink | Show parent | Reply

looking forward to see the changes

Average of ratings: -

Permalink | Show parent | Reply

+1

Average of ratings: -

Permalink | Show parent | Reply

After updating Moodle to the latest 2.0dev Moodle does not load any CSS. Instead styles.php returns the "A required parameter (sesskey) was missing" error.

Do I need to work with a fresh 2.0 or is there a bug?

Average of ratings: -

Permalink | Show parent | Reply

Thanks for corrections. After an Moodle update the theme display works now.

Average of ratings: -

Permalink | Show parent | Reply

From what I've seen so far the opportunities to work with the page design in Moodle 2.0 look great.

_ Taking Tim's custom_corners renderer example I was able to understand the renderer basics and could make a first step integrating a renderer in a theme.

_ With the Javascript handling we got an official option to integrate other JS frameworks besides YUI

Thank you very much to the Moodle developers and specially Tim for all his work implementing the new objet structure in Moodle 2.0 and Petr for working on the theme implementation.

I am looking forward to create marvelous learning environments to support learners and trainers based on Moodle 2.0.

Merry Christmas I wish everybody celebrating Christmas, some nice days to all others. And a successful year 2010 for everybody.

Average of ratings: -

Permalink | Show parent | Reply

Thanks Urs.

Do not forget to thank Sam Hemelryk. He went round huge numbers of Moodle scripts and updated a lot of the old deprecated function calls to the new libraries. He also cleaned up a lot of the old inline JavaScript. Basically, a whole lot of fairly boring but important stuff.

Also, Nick Connault, who converted a lot of the old weblib.php functions to $OUTPUT methods.

And there there were the theme makers here, who nagged us until we actually did something about this, and gave feedback on the proposals. (I still wish some of the original discussions could have been more constructive, and less confrontational. Apologies for my part in that.)

Anyway, these changes have been a good team effort, and I hope that as a result, we have spotted in advance all the potential problems, and avoided them. I still have this nagging worry that it six months time, we will discover some terrible flaw when it is too late to do anything about it, but I think that is just paranoia

Average of ratings: -

Permalink | Show parent | Reply

To see all these changes would I have to reload Moodle 2.0 or are these changes only available to registered theme designers?

Average of ratings: -

Permalink | Show parent | Reply

Registered theme designers??? wide eyes

It's a huge list of changes - starting from http://tracker.moodle.org/browse/MDL-20204 and http://docs.moodle.org/en/Development:Theme_changes_proposal

Even if Petr and Tim could explain most changes in Docs it will take several months to study and test all little changes they have made to theming system of moodle 2.0 wink

- and all changes are not yet even implemented...

Average of ratings: -

Permalink | Show parent | Reply

Well...one has to ask politely in case one treads on another's shoes! I thought, from what Petr said at the start of this thread, that there was an elite group of developers and theme designers on-board who were all poised ready to take on a mammoth task of testing. LOL

I've seen the list of changes, most of which have gone over my head...but I did wonder where these changes are taking place.

Of course from what Tim has said in his last post, I do appreciate that a lot of hard work has gone into all of this by those updating various parts of the system. where most of the jobs are pretty boring and time consuming.

Well I just want to say that I for one appreciate what they are doing...

Will Moodle 2.0 be fully tableless, or is that too much to hope for? LOL

Thanks...

Mary

Average of ratings: -

Permalink | Show parent | Reply

The easiest way to track what is going on in Moodle 2.0 is to set up a test install using CVS. See CVS_for_Administrators, and update regularly.

Anyone can see the latest code and try to understand it. Similarly, what documentation there is, is in public on http://docs.moodle.org/.

But we all need to work out how best to make themes using the new system, so don't be afraid to ask questions here about the bits that are not clear to you.

We do want Moodle 2.0 to be table-less. That is another area where CSS experts can help.

Average of ratings: -

Permalink | Show parent | Reply

OK...I'll have a go at setting up a test install using CVS...then I'll be back with some questions!

Thanks

Mary

Average of ratings: -

Permalink | Show parent | Reply

Could you please update Development:Theme_changes_proposal to Development:Theme_changes to document the actual state?

Average of ratings: -

Permalink | Show parent | Reply

You're welcome.

Average of ratings: -

Permalink | Show parent | Reply

Today I saw that you implemented The 'Holy Grail' 3 column Liquid Layout in the base theme for the table-less page structure

Is it a test or did you decide to use this marvelous solution with this strange name? If you have not yet decided which way to go with page layouts I want to encourage you to follow this way - I have chosen this solution for my Moodle template work on my lab site after intensive researches. Implementing the solution showed that it works well. And the solution is well documented.

Average of ratings: -

Permalink | Show parent | Reply

This was just a test, but yes I liked it a lot. I have another commit pending with my experimental theme that is using YUI grids.

Unfortunately there is one major problem, the integration of the collapsing navbar, it was kind of easy to implement with the table layout, but I do not know yet how to solve it with the CSS column layouts. SamH should be working on that after the holidays.

I am still working on the themes internals and outputlib, I expected it would be finished by now, but I had a flu and had to spend some time in bed

Anyway, thanks for your feedback and Happy New Year!

Average of ratings: -

Permalink | Show parent | Reply

Petr, I hope you are well again.

@"experimental theme that is using YUI grids" You surely remember what I wrote about YUI grids - YUI grids are too specific.

And

1.) The "Holy grail ..." offers the 2-1-3 column layout which delivers content first before the side columns. With the way Moodle pages are calculated and rendered in 2.0 it is even more important to send the content before the side columns are calculated and rendered. Does the YUI grid offer this option?

2.) The "Holy grail ..." offers equal hight columns. Based on it I can implement the "lines" and "color" theme in 2.0 which depend on equal hight columns. Does the YUI grid offer equal hight columns?

Another approach

Instead of forcing a layout as the one and only solution there might be a commitment to officially support different layouts - for example the YUI grid based layout and the "Holy grail ..." layout. Pairing the layout.php scripts with the fitting layout.css would make sense and increase flexibility. Fonts, colors, module specific CSS etc. can be placed in other CSS files. You may choose one or the other layout.php/layout.css pair and use the same other CSS files.

Designers could better choose the base layout fitting their design needs. And would not be forced to implement strange named grids.

If this "open" approach might be chosen it doesn't really matter that much, which layout you use for the base theme in Moodle.

Average of ratings: -

Permalink | Show parent | Reply

The "collapsing navbar" is a very special beast. I think the functionality is marvelous - the actual implementation and look is awful.

Such a central navigation element needs to be implemented very close into the overall design and navigation. Now it looks to me like an alien element. And the "collapsing navbar" is quite different from the navigation patterns users know and expect.

It needs for example to be part of an horizontal menu like the one on moodle.org when one is present. A horizontal menu plus this side menu would break common navigation expectations and experiences.

As you see we need to be able to implement the "collapsing navbar" in different ways. Can the "collapsing navbar" be implemented with a renderer giving the opportunity to change the integration into the page with a different renderer when necessary?

Here again a flexible approach would make a good solution.

Average of ratings: -

Permalink | Show parent | Reply

On GIGAOM I read the article "User Experience Matters: What Entrepreneurs Can Learn From “Objectified”. One of the central sentences in the article is "Great design means that one look and the end user reacts by knowing what to do with a knob or a button, without as much as even thinking about it."

That's the goal for design helping users doing their jobs.

Average of ratings: -

Permalink | Show parent | Reply

I saw that too, so I tried it out after uploading the latest Moodle 2.0 as at 26th December. I was not too impressed because it didn't fit well on my PC using screen set to 1024x760 resolution (my personal preference). Also there was a problem when I tried to change back to the standard theme. The Admin panel kept collapsing each time I tried to select Appearance/ Theme/. In the end I renamed the base theme so that it reverted back to the default theme so that I could reset it properly.

I'm not sure what caused the odd behaviour, but I did wonder if it was linked to javascript? I've not had that much time, but I want to try some ideas on creating a theme based on the Base three column layout.

Cheers

Mary

Average of ratings: -

Permalink | Show parent | Reply

The "Theme designer mode" has a major issue.

A course page loads in 2 sec in normal mode. The same page takes about 16.5 sec in "Theme designer mode". (styles about 9 sec., images about 6 sec.) This load time is not acceptable because it means waiting for each page reload. Normal page change times are essential when working on page design with CSS and/or XHTML.

One solution might be to build one styles.php in both modes. As is for normal cached mode and one where you don't copy the CSS into one file but collect all CSS with @import like "@import url("http://server.com/moodle_20/theme/standard/style/layout.css");" in one file and don't cache. (Themes not accessible by the web server can't be delivered this way. But in a development environment you can always save the theme in the themes folder.)

Collecting the CSS files with @import I implemented for "design mode" in Moodle 1.9 and it works well. Besides the much shorter load time another advantage of this approach is that you see all CSS files with their names in the browser and this helps a lot while developing CSS.

The existing approach is technical and not at all user friendly. Please change the "Theme designer mode".

Average of ratings: -

Permalink | Show parent | Reply

Petr added a new task to http://tracker.moodle.org/browse/MDL-21208

as a part of

http://tracker.moodle.org/browse/MDL-20204

It might be a good time for all of us to dig up different testing tools ... to help core developers with this huge task.

Average of ratings: -

Permalink | Show parent | Reply

Try the designer mode now, it should be a bit faster

Please test if the current page structure is suitable for your favourite design tools, I tried it with just a few tools and it seemed to work fine - I am just a CSS beginner (for many years already).

It would be also nice if you could describe your CSS designer workflows here, I would like to learn a bit myself...

Petr

Average of ratings: -

Permalink | Show parent | Reply

I haven't tried your new code yet but I made just a quick check with DynaTrace and it looks like the major bottlenecks were files theme/styles_debug.php and theme/yui_combo.php.

Attached some images 2) & 3) Designer mode enabled and the last image without Designer mode (and I am not at all sure that my analysis is correct - I have used this tool only a couple of times...

:

Average of ratings: -

Permalink | Show parent | Reply

Petr, it works well now - Thanks!

It did not seem to matter which time (in seconds) we use as long as there is some value. My current value is

$CFG->THEME_DESIGNER_CACHE_LIFETIME = 300;

I have some difficulties in getting the idea of using javascripts with current layout system. http://docs.moodle.org/en/Development:Theme_changes_proposal says that "If more advanced themes need extra javascript files we could add an optional /theme/javascript.php file and a new config option with list of JS files.

When I tested one elastic jQuery theme layout that worked fine some months ago it looked now that all extra javascripts were stripped away from layout files (home.php, general.php...)

What's the best practice - can extra javascript files still be included to theme files (with some config setting) or is it still possible to use also external javascripts with some other ways in themes?

Average of ratings: -

Permalink | Show parent | Reply

@extra javascripts

I got extra JS loaded the following way:
_ save your JS files in the "yourtheme/javascript/" folder
_ add the following setting to config.php
/** List of javascript files that need to be included on each page */ $THEME->javascripts = array( 'jquery-1.3.2.min', 'jquery.tools.min' );

Average of ratings: -

Permalink | Show parent | Reply

Ah - now I think I found the reason why I thought it might not work...

When I tested it I saw http://tracker.moodle.org/browse/MDL-21124 ( implement theme/javascript.php )
Then I found file theme/javascripts.php
From standard theme I found folder javascript and in standard theme config.php $THEME->javascripts = array('navigation');
using the same method as you said here.

But when I tested it in the morning I did not see script tags in source so i thought that it would not work and that javascripts were not read.
Now when I tested this method again source still does not have any script tags but actual javascript does work - meaning that tags from those scripts in folder javascript are obviously collected to some other javascript file like css is collected to one file - is this correct?

Average of ratings: -

Permalink | Show parent | Reply

Yep, JS is collected and delivered by "javascripts.php". This is the file you may check for your JS code.

Average of ratings: -

Permalink | Show parent | Reply

THEME_DESIGNER_CACHE_LIFETIME is a constant, not $CFG value, you have to define('THEME_DESIGNER_CACHE_LIFETIME', 300) instead in config.php. The default value 4 should be suitable for 99% of cases, we usually use defines for things like this.

Average of ratings: -

Permalink | Show parent | Reply

These tiny things can sometimes look complex - or new... big grin

Average of ratings: -

Permalink | Show parent | Reply

Thanks Petr, the page load time is a lot faster now.

And I changed the parameter order to display the "sheet" name first in the styles_debug.php urls. In the moment the sheet name comes last and you need to check the end of the long url to find out the name of CSS file. Please consider to integrate this change into core.

Average of ratings: -

Permalink | Show parent | Reply

Petr or Tim, how do I define JavaScript in the theme config.php to be loaded in the header?

Average of ratings: -

Permalink | Show parent | Reply

In the latest Moodle 2.0 version the theme javascript is loaded from the header. May be my question was ambiguous - therefor another one:

How do I define where JavaScript files linked from the theme are loaded. Some shall be loaded from the header, some shall be loaded from the footer.

Average of ratings: -

Permalink | Show parent | Reply

I apologize for my delay in responding. I took a bit of a break for the holiday.

Here are my first impressions:

1.) The navigation bar that is collapsable to the left side of the screen is not going to work out for themes that add some sort of left and right margin to provide depth to the page. For example, collapsing the navigation bar using anomaly is awkward and confusing.

2.) The Standard theme config.php links to http://phpdocs.moodle.org/HEAD/moodlecore/theme_config.html for options related to customization. This page will not load.

3.) The documentation at http://docs.moodle.org/en/Developement:How_Moodle_outputs_HTML (also linked from Standard theme config.php) appears to be outdated.

4.) In the new settings block, when I click on the Site Administration link, I think that I'm expanding the menu, but I'm taken to Site Administration > Notifications (moodle/admin/). This link should not actually take me anywhere. The correct behavior would be similar to that of the "My profile settings" option that is also in this menu.

I'm going to play a little bit before I write any more. My first task will be to start working on altering the new Standard theme just to get a sense for what I'm doing. If there is anything specific you'd like me to do, please let me know.

Average of ratings: -

Permalink | Show parent | Reply

That navigation block does indeed have some strange behaviours but if you click the triangle icons instead of links things seemed to be smoother. For some reason I have had again lots of troubles with IE that does not seem to catch all stylesheets or javascripts - that work ok with all other browsers in my custom themes (first test versions. Might there be some restricions for IE again or are some features partly implemented for IE??

By the way, did you know that Firefox 3.5 is now the most popular browser version world wide in Global Stats...

If you want to test changing of some basic settings with jQuery or ThemeRoller I might get a easy-to-use test version available after some days - styles can be used in normal themes also without jQuery - but I don't know yet if my problems with IE are caused by these scripts or IE itself (and code of moodle 2.0). Have you tested for example Anomaly of moodle 2.0 with IE8, does it look the same as with other browsers?

Average of ratings: -

Permalink | Show parent | Reply

That navigation block is also themable and movable with css but most of people might prefer vertical or horizontal menu - yet we have always some doubts about "new things"...

Average of ratings: -

Permalink | Show parent | Reply

The problem is not only in my scripts.

In designer mode IE is always broken (does not read styles like it should) and if designer mode is disabled IE8 mode is always broken - IE7 mode works - and IE6 /Quirks mode shows typical IE6 bugs...

So for example current moodle 2.0 version of Anomaly does read styles "correct":

- with all "modern browsers" (Firefox, Chrome, Opera, Safari...) and

- with IE7 or IE8 in compatibility view if designer mode is disabled

Average of ratings: -

Permalink | Show parent | Reply

Bloody IE! Reinstalling my VirtualBox test boxes.

It used to work when I originally implemented it, looks like a recent regression. Going to fix it today, sorrrry.

Average of ratings: -

Permalink | Show parent | Reply

Strange, all IE browsers work fine for me in my experimental theme. Could you please try a fresh CVS checkout and set $CFT->theme = 'experimental'; with all your IE browsers in all modes?

Average of ratings: -

Permalink | Show parent | Reply

I have been testing this with IE8 developer tools and Microsoft Expression Web 3 SuperPreview and it looks like Experimental theme and Standard theme work ok but custom themes like current 2.0 version of Anomaly and my standard theme based test theme might render css of standard theme in design mode (even if standard theme is not selected - source shows css files from anomaly) and if design mode is disabled Anomaly and my test theme do render ok in IE7 or IE8 compatibility mode (3) but in pure IE8 mode (4) css looks most broken.

Screenshot 1 is from IE8 compatibility mode designermode enabled and 2 from IE8 mode designermode enabled in ANOMALY theme...

I guess there is some logical explanation for this behaviour - I have to check the layout files etc.

Take a break now Petr and let's continue with these themes (and editors) next year... ( = tomorrow? tongueout big grin )

Happy New Year!

Average of ratings: -

Permalink | Show parent | Reply

IE has caused so much extra trouble for everybody that the easiest solution would be to use always a different theme/code for IE from the beginning and let other browsers use the nice features (X)HTML, scripts and CSS can offer...

Millions of IE-only-bug-fixes during the past years. mixed

Average of ratings: -

Permalink | Show parent | Reply

I would suggest moving this whole discussion from the forums to a more permanent place on Moodle Docs as there surely will be more people in the future who will need this information as reference.

Happy New Year to you all!
Frank

Average of ratings: -

Permalink | Show parent | Reply

I have created Themes 2.0 FAQ as a reference for questions regarding the new theming system in Moodle 2.0 - please contribute

tia
Frank

Average of ratings: -

Permalink | Show parent | Reply

I suppose we are all waiting that Petr gets the "prototypes" ready and docs about 2.0 theme changes up-to-date to know what can be done and how...

Basicly I like all the new ideas - instead of changing the design of plain header and footer we were hoping the capability to control all parts of moodle with layout files and renderers - I am afraid some of "good old features" might also be lost or restricted more than before with the latest changes.

When Petr has finished the major changes it's time to start collecting frequently asked questions from forums...

And after all - Good things are worth waiting for... wink

Average of ratings: -

Permalink | Show parent | Reply

One update:

I took away most css files that I had added from standard theme to my test theme and left for now only styles_hacks, styles_layout and my custom css file to

$THEME->sheets = array(
    'styles_hacks',
    'styles_layout',
    'styles',
);

in theme config.php

All modes of IE render now changes ok so most likely the problem is just some of the odd restrictions IE has and we should try to use minimal number of css and other files in themes.

Average of ratings: -

Permalink | Show parent | Reply

Oh this is a misunderstanding:

1/ "standard" theme is dead - it is there only for developers working on non theme related code, it will be deleted once we create some "newstandard" theme and migrate all usable code from it into base. Do NOT extend standard theme any more!

2/ "base" is supposed to be new general original for all other themes, we now have multiple levels of inheritance - it means that ppl may extend "newstandard" which is going to extend base. Base will definitely not be suitable for normal use, it is supposed to be really minimalistic with as few CSS as possible.

3/ "experiment" is supposed to be example of new generation of highly customised themes

4/ ignore anomaly and the rest of themes - I wanted to delete all old themes from CVS, but I got persuaded by other devs not to do that - it was a mistake because those old themes in /theme/ are confusing for you and other developers.

My current plan is to:
* finish outputlib refactoring
* fix all docs and add more
* start discussion about the navbar and how to solve related issues
* work on base + my experiment theme to should ppl what and how ppl add new themes

Petr

Average of ratings: -

Permalink | Show parent | Reply

Thanks for that...this make more sense to me. Now I know where to start themeing.

M

Average of ratings: -

Permalink | Show parent | Reply

Working with the Moodle 2.0 design possibilities with themes and renderers is real fun

I wish everybody a good new years night and a successful year 2010.

Average of ratings: -

Permalink | Show parent | Reply

ditto!

Average of ratings: -

Permalink | Show parent | Reply

Some questions:

What is the best way to get the Moodle base URL in the theme layout scripts?

Average of ratings: -

Permalink | Show parent | Reply

Some questions:

What is the best way to get the Moodle theme URL in the theme layout scripts?
theme_config holds the dir but not the URL, so $PAGE->theme->dir delivers the directory. I need the theme URL.

Average of ratings: -

Permalink | Show parent | Reply

Themes do not have URLs any more, instead everything must go through the theme/styles.php, theme/javascripts.php and theme/image.php. All pages get the same stylesheets, all pages get the same extra javascript.

Average of ratings: -

Permalink | Show parent | Reply

Ok, we will see if this approach is flexible enough.

To be able to deliver JavaScript code efficiently it will be necessary to send most JS from the footer. But some JS needs to be sent from the header. How can I define in the theme which JS is delivered from the header and which is delivered from the footer?

Average of ratings: -

Permalink | Show parent | Reply

"To be able to deliver JavaScript code efficiently it will be necessary to send most JS from the footer" - I disagree here, the most important thing is to cache JS (and also CSS) in browser and do not issue any extra http request to server.

Originally we were loading JS and CSS from PHP files that were including our config.php - looking back this was really horrible for performance, it did not matter if we did that from footer or header, because the bottleneck was our server. Even using *.js and *.css files does not eliminate http requests, if you try to hack around it with httaccess or apache config you will run into major problems during upgrades.

During the Christmas I have implemented the new YUI3 combo loader support - theYUI JS+CSS can now be loaded both from PHP (html head) but also from javascript as YUI3 modules - hopefully this will fully replace the lazy loading from footer. Please note YUI3 resources are either preloaded from HEAD or then later automatically fetched when initialising YUI Y instance.

So the current status is:
1/ all theme CSS and JS is fully cached in browser - 0 http requests per page (yay)
2/ all YUI3 and YUI2 code is cached in browser - 0 http requests per page (yay)

I also started thinking about ways to improve loading of JS from plugins and core subsystems, for now we have the $PAGE->requires->js() which can be further improved to eliminate http requests (full browser caching).

Should we actively pursue the goal to load everything from footer? I personally think it is much more important to cache JS properly in browsers (we need to solve versioning there like in YUI combo loader) without any http requests per page. For performance reasons we should imo load all other JS stuff using the new YUI3 loader on the fly. Dongsheng is going to explore the possibilities more this week

Is JS and CSS parsing speed a potential problem? I hope not any more for modern browsers like Chrome, Safari or Firefox, I personally do not care much if something is a bit slower in IE6 or IE7

My plan for this week is to work on experiment theme, Sam H will be probably working on anomaly migration, hopefully by the end of next week there will be more theming examples in cvs...

Average of ratings: -

Permalink | Show parent | Reply

@"I disagree here, the most important thing is to cache JS (and also CSS) in browser and do not issue any extra http request to server."

Hmm. You may read the article series Loading JavaScript: Even a caveman can do it. A long an very interesting read.

Web sites I am involved with will change often because CSS and JavaScript always needs to be enhanced on different parts. It's by no means ready at any time - that's even more true with Moodle sites.

In the article series on page LABjs: why not just concat? part 2 you read:

"Sure, the user’s browser cache is not fully reliable and a significant portion of views happen with empty caches, even with return visitors. But that doesn’t mean we should throw the baby out with the bath water and completely ignore the browser cache as being irrelevant. We should intelligently try and figure out what code is less likely to change, and what code is more likely to change, and separate the two code segments into two files."

So intelligently loading JavaScript with blocking is even better than loading JS from the footer. But restricting the system to one big JS file and hoping the cache will do seams not the right way to go.

I propose to use a flexible loading system. If the YUI loader and the Moodle implementation is handling all issues then this system is ok. If not a better loader should be considered.

Average of ratings: -

Permalink | Show parent | Reply

I did study various JS loading tricks, but thanks for the pointers to more info :-)

1/ our JS and CSS is not changing often on production sites.
2/ even if the JS/CSS is changing the new theme framework copes with that via versioning
3/ Moodle sites are not optimised for random visitors that view just one page
3/ we are not concatenating everything into just one file: there will always be several separate files: preloaded YUI2 JS and YUI3 JS, YUI3 CSS, theme CSS, theme JS, custom plugin JS files.
4/ you can load YUI JS and CSS directly from YAHOO to offload moodle servers which also helps sharing of browser cache between different sites

The important aspect of new outputlib/theme framework is that everything is handled by core which means we can significantly change/improve it without touching the themes or plugin code.
The latest version in CVS is definitely not perfect, there is a lot of room for improvements. I hope we have much more options now. IMHO it also depends on how the Moodle UIs evolve in general. More ajaxy sites have different requirements/optimisations than traditional old style PHP apps.

Back to your original question, how do themes load JS from footer? They can not use $PAGE->requires->js because themes do not have public urls any more. If it is really necessary in future we would have to add $THEME->footer_javascripts = ''; into theme config.php. Technically it is very easy to do, I personally do not think it would give us any extra perf boost, but I may be wrong of course. Once we have some working themes we can benchmark it simply by doing $PAGE->requires->js with unsupported public theme url ;-)

Thanks for all your valuable feedback!!

Average of ratings: -

Permalink | Show parent | Reply

Hey Petr - just saw your tracker issue "(MDL-21244) add $THEME->javascripts_footer = array() option" because you added me as a watcher

THANKS!!!!

Average of ratings: -

Permalink | Show parent | Reply

Hey, I really think about all you say (even if I do not reply immediately) and I sometimes/often change my mind, but it may take some time

Average of ratings: -

Permalink | Show parent | Reply

He he - it's typical for all of us - we have strong opininions about different things, we are busy and when somebody else tells us what to do we usually first resist the (new) ideas but read the backgrounds anyway.

I have used jQuery that much that I might say that Urs has very good arguments for his opinions. Even if jQuery could not be used in core files of moodle it is still good that we can use it in custom themes and plugins some way - and Yes We Can! big grin Still the easier this is...the better. YUI is ok - we can do most tricks with both of these the same way - in my math plugins I was going to change all previous yui tabs to jQuery Ajax tabs because that way the content of each tab was loaded only after pressing each tab and in yui tabs all tabs were loaded at first at the same time causing a really long waiting time for IE users and therefore the performance of jQuery tabs looked better. Obviously it is possible to create similar tabs with YUI3 too - or even better - it just takes some time to create them.

Like Urs said the list of sites using jQuery is impressive - about 21% of most popular web sites use jQuery today while about 3-4% use YUI. Here you see some of them:

http://docs.jquery.com/Sites_Using_jQuery

But you have excellent arguments for your opinions as well. Here we see just a typical difference between developers and designers and the way to use code. Developers want to "tie strings" and designers want to loosen them...

No hurry Petr, you can first implement all needed changes to moodle 2.0 now and if it is necessary the possible ways to use different javascript libraries can be checked later. Our task is to help you where/when ever you need our help... wink

Edit: here the reference for those percentages - http://www.backendbattles.com/JavaScript_Libraries

Average of ratings: -

Permalink | Show parent | Reply

Moodle.org is among these 10000 most popular sites (Alexa rank somewhere near 7000) and Open university http://www.open.ac.uk/ is a little more popular (Alexa rank near 6000) but mostly these Alexa top rank sites are commercial sites (media or business)

Anyway here some selected examples among those top 10000 most popular web pages (check the source and search jQuery)

http://www.msn.com/

http://www.microsoft.com/en/us/default.aspx

http://www.xbox.com

http://twitter.com/

http://www.amazon.com/

http://www.imdb.com/

http://espn.go.com/

http://support.dell.com/

http://www.foxnews.com/

http://www.fox.com/

http://www.usatoday.com/

http://www.guardian.co.uk/

http://www.telegraph.co.uk/

http://www.time.com/time/

http://www.thesun.co.uk/sol/homepage/

http://www.news.com.au/

http://www.mozilla.org/

http://europe.nokia.com

http://www.mtv.com/

http://www.smashingmagazine.com/

http://www.pcworld.com/

http://pbskids.org/

http://www.ubuntu.com/

Most creative design may not be found from most popular sites or most popular learning environment sites but many sites take ideas to their design from most popular sites... wink

Average of ratings: -

Permalink | Show parent | Reply

And today I see that you implement $THEME->javascripts_footer = array('navigation'); in the themes

Average of ratings: -

Permalink | Show parent | Reply

Another very important aspect is if the YUI loader can load jQuery and jQuery plugins in a comfortable way. jQuery is my JavaScript framework of choice. With jQuery I am able to develop within a reasonable amount of time - which means within a amount of time clients are willing to pay for.

About 2 month ago I tried to refactor JavaScript I had written with jQuery using YUI. It's just adding some DOM elements to a page and attaching some CSS and event handlers to it to handle an open/close animation - relatively easy with jQuery. I gave up after two days with YUI because I was not able to solve the task within a reasonable time. I would have needed to write many more lines of code to solve the task with YUI.

Searching the internet brought some few YUI sources to support me with my task. For jQuery I can find many sources and have access to several good books - not a least the new jQuery Cookbook.

In YUI I will not investigate again in the near future. I hope very much Moodle 2.0 will be open and flexible enough to handle other JS frameworks elegantly.

And I read form several postings in the forums that I am not alone with this opinion.

Average of ratings: -

Permalink | Show parent | Reply

Did you try YUI3, it is very different from YUI2.

Sorry, the decision to use YUI was done long ago, there is no way back, unless of course YUI is dead, which I doubt. I am personally not going to study jQuery, because there is no room in Moodle core for two similar frameworks. I did not have any preference, but now I intend to stick to anything that was selected before.

First you talk about performance, then you want to load two similar frameworks on each page, hmmm.

If you really, really want to implement theme with jQuery you can:
1/ load it from another site (such as google apis)
2/ load it from $CFG->wwwroot/local/jquery/* local plugin (this is the right place for extra stuff in 2.0)
3/ load it directly from $CFG->wwwroot/theme/yourtheme/jquery/* (strongly discouraged, not compatible with custom $CFG->themedir)

In any case I think that no stuff using jQuery will be included in official Moodle 2.x package. I think if more contrib plugins need it the developers should agree on common location which could be the /local/jquery/x.y.z/* maybe even with some special php serving script with appropriate caching headers. In theory the $PAGE->requires could be also hacked to support jquery loading via some extension mechanism or theme override.

Average of ratings: -

Permalink | Show parent | Reply

Thank you very much Petr for taking the time to write your detailed answers.

@"First you talk about performance, then you want to load two similar frameworks on each page, hmmm."

Please be careful - I do not want to load two Frameworks, I am forced to when I want to work with Moodle in a productive way. That is a big difference. Working with jQuery in many projects and being forced to learn YUI for Moodle work is expensive. Who do you think will be willing to pay for the extra time?

Have you ever spent a moment thinking about the fact that several well known Open Source projects have switched form any JavaScript to jQuery (Joomla, Wordpress, Drupal for example)? Or why several people in Moodle forums ask for jQuery?

jQuery is mainstream in the moment. The jQuery learning curve is much smaller than the YUI learning curve. You can get your job done in less time with jQuery than with YUI. There are lots of sources and books helping to solve jQuery tasks. Many people know how to work with jQuery and can get productive without an extra learning curve. That means for many people working with jQuery is less expensive than working with YUI.

Moodle's core JS framework is YUI - that's ok. What I have always been asking for is not to replace YUI by another framework but to be open and support elegantly incorporating other frameworks. The tendency among Moodle developers seams to be single minded and willing to exclude anything not part of the "Moodle way".

Moodle is not going to rule the competencies and preferences developers have - Moodle can either block out or integrate. From my point of view Moodle will suffer from blocking out and win with integrating.

Some examples about the success/failure with blocking/integrating strategies. Apple is winning by blocking. But they offer the best tools and support possible. Microsoft/Windows looses by trying to integrate anything. They have huge problems finding the right and easy way. UNIX/LINUX wins by integrating. The philosophy is open from the beginning. Not either blocking or integrating will be the right strategy by itself - but the way one or the other is handled and supported. Moodle will never be able to go the blocking "Apple way" - that's why I propose to go the integrating "UNIX way".

You have given some examples how handling jQuery integrating is possible like "2/ load it from $CFG->wwwroot/local/jquery/* local plugin (this is the right place for extra stuff in 2.0)" Ok. To get jQuery loaded with the dynamic loading (and blocking if possible) mechanisms of YUI loader would be much better than creating an extra solution. Do you have an idea how this could be done?

Average of ratings: -

Permalink | Show parent | Reply

Silly question: are you going to pay me to study and implement jQuery support in Moodle for you and convert all curent YUI code to jQuery?

If you want jQuery you have to make it work yourself, I do not have any time to work on that now, sorry.

I am not going to argue about jQuery any more, this is my last post with jQuery word in it before the 2.0 release, sorry. I am willing to discuss this and help you after the release.

Average of ratings: -

Permalink | Show parent | Reply

Hi,

I would just like to second the points Urs makes about jQuery being mainstream and productive. It would be a big help to theme developers such as myself if Moodle supported jQuery. It would help theme developers to more quickly and easily develop features and functionality.

I am not a backend programmer so I cannot comment on just how much of a technical challenge this would be. However, I can appreciate that there are perhaps significant technical challenges and overheads for the Moodle development team to do this. If at all possible though I would urge that Moodle be developed to facilitate the use of jQuery for the very clear reasons Urs has set out.

So my questions would be:

1) Just how much of a challenge would it be to allow Moodle theme developers the choice to use JQuery?

2) Beyond the technical overhead of achieving this, is there any other reason not to offer Moodle themers the choice to use jQuery?

~thomas

Average of ratings: -

Permalink | Show parent | Reply

@theme/image.php

How do we need to link to images?

Like "$OUTPUT->pix_url('favicon', 'theme')" for images within layout files?

The tab images called from CSS are linked with "url([[pix:theme|tab/right]])". What exactly do the two parts mean?

The second part "tab/right" looks like the path within the "theme/pix" folder and the image name without extension. Can we also set the extension explicitly? May be via a third optional part like "url([[pix:theme|tab/right|png]])"?

Average of ratings: -

Permalink | Show parent | Reply

Trying to fix the inline docs:

/**
* Return the moodle_url for an image.
* The exact image location and extension is determined
* automatically by searching for gif|png|jpg|jpeg, please
* note there can not be diferent images with the different
* extension. The imagename is for historical reasons
* a relative path name, it may be changed later for core
* images. It is recommended to not use subdirectories
* in plugin and theme pix directories.
*
* There are three types of images:
* 1/ theme images - stored in theme/mytheme/pix/,
* use component 'theme'
* 2/ core images - stored in /pix/,
* overridden via theme/mytheme/pix_core/
* 3/ plugin images - stored in mod/mymodule/pix,
* overridden via theme/mytheme/pix_plugins/mod/mymodule/,
* example: pix_url('comment', 'mod_glossary')
*
* @param string $imagename the pathname of the image
* @param string $component full plugin name (aka component) or 'theme'
* @return moodle_url
*/

Average of ratings: -

Permalink | Show parent | Reply

You write in the doc
* ... The imagename is for historical reasons
* a relative path name, it may be changed later for core
* images. It is recommended to not use subdirectories
* in plugin and theme pix directories.

For graphically rich designs we need many images. Throwing all images into one directory without subdirectories will end in a mess. Subdirectories within the pix folder need to be supported to get the images organized.

Please, please rethink the approach to remove subdirectory support and keep it.

Average of ratings: -

Permalink | Show parent | Reply

For individual plugins you do not need hundreds of images - I am not talking about core pix folder there! The same for theme CSS images - you need some backgrounds and corners in CSS, are there going to be hundreds of these CSS background images? I hope not, because themes would have to load hundreds of these tiny images, instead image loading in CSS is often optimised by making bigger tiles of images which means number of images in individual themes will be low

For core - yes there might be hundreds, and yes we need to organise them somehow, but the current subdirectory structure is confusing, we may use some virtual paths there, it might not reflect the real directory structure there. Also for core images we can not optimise them by joining images because they are displayed using IMG tag, not CSS.

Average of ratings: -

Permalink | Show parent | Reply

There probably won't be hundreds but maybe some tenth of images. I prefer to organize my data and put the images belonging to one area in one folder, images belonging to another area into another one.

Is there a technical demand to force everybody to throw all images into one folder? If not I hope for an insight to keep the subfolder option. It would be strange when developers just decide how people must organize their work without a strong demand.

Average of ratings: Useful (1)

Permalink | Show parent | Reply

Some questions:

Is there an easier/better way to get an overview of the variables and function calls available in the layout scripts than reading the code? I hope here is, because with $OUTPUT, $PAGE, $PAGE->theme etc. there is a lot of code to check in quite different places.

Average of ratings: -

Permalink | Show parent | Reply

Some questions:

When I get the role of $PAGE and $OUTPUT right, $PAGE holds information, $OUTPUT is used to render the information for output. Right?

In 'base/layout/frontpage.php' I see echo $OUTPUT->lang_menu(); and echo $PAGE->headingmenu; This looks inconsequent - I would expect the second statement to be echo $OUTPUT->heading_menu(); Why are the two menus output differently?

As I think it would be
1) easier to keep an overview when checking for content would be done via $PAGE and the output always rendered via $OUTPUT.
2) impossible to override the headingmenu output because it doesn't use a renderer.

Average of ratings: -

Permalink | Show parent | Reply

Sorry 2) may be not clear. It should read:

2) possible to override the headingmenu output when it is output via a renderer via $OUTPUT.

Average of ratings: -

Permalink | Show parent | Reply

$PAGE->headingmenu is "custom menu" set by script, originally the lang menu and login info was passed through this variable, but not any more. Themes may decide to put the langmenu and login info anywhere. Module authors may decide to add extra stuff into heading - like those various edit buttons.

1) and 2) no, $PAGE->headingmenu is custom content from plugin developer - we do not control it at all. Hopefully it will not be used from core much in 2.0, but we need to solve where to put those edit buttons (probably the new navigation stuff is better place).

I would instead propose to rename it to $PAGE->customheadingmenu

Average of ratings: -

Permalink | Show parent | Reply

My +1 to make functionality as clear as possible in the code. Renaming to "$PAGE->customheadingmenu" would help.

Average of ratings: -

Permalink | Show parent | Reply

Some questions:

How is a module supposed to set up and use module page renderers?

Tim mentioned that there will be at least one example module to show how modules may be build using renderers (the forum module for example). I would appreciate such an example to be close to Moodle core with module development.

Average of ratings: -

Permalink | Show parent | Reply

Workshop and lesson should be already using plugin renderers, the new webservice UI is using a core renderer subtype too.

In any case I would strongly discourage you to override plugin renderers in 2.0 because they will probably change a lot.

Average of ratings: -

Permalink | Show parent | Reply

Thanks Petr. I'll check the places you mentioned.

Average of ratings: -

Permalink | Show parent | Reply

Some questions:

Moodle 2.0 is prepared for the page layout "admin". Another type of administrational pages are the settings pages - like course settings.

Please add the page layout type "settings" to the page layout list.

With "admin" and "settings" pages clearly defined it will be easy to create page designs optimized for administrational tasks. The demands for administrational pages are quite different from course or module/resource pages.

Average of ratings: -

Permalink | Show parent | Reply

Some questions:

You wrote that the "standard" theme is dead. Standard is the only theme holding the "block_" and "mod_" csss files.

Where are block and mod CSS definitions supposed to be saved? Do you plan to store them

1) in the theme as the central place - easy for design because CSS files are all in one place :: how easy will be block or module installation with files in several places?
2) Clean up the CSS and save it in the blocks/modules folders - more difficult to design :: easy installation

Average of ratings: -

Permalink | Show parent | Reply

Plugin CSS - the current styles.php contain problematic CSS, it needs to be cleaned one by one, that is why I moved it into legacy standard theme. Unfortunately I did not start the transition yet, I am planning to do this this week.

3/ very basic plugin CSS is loaded first from plugin folder (file plugindir/styles.css), then stylesheets from theme/mytheme/ folder and at the end it will look again into the plugin folder and search for styles_mytheme.css (this step is not implemented yet I think).

This means that each plugin CSS consists from 2 or 3 parts. This 3rd part should finally allow contrib plugins to extend other contrib themes (optional now, something not possible before).

Average of ratings: -

Permalink | Show parent | Reply

Petr, there are many loose ends concerning theme design and I don't see a chance to seriously start working on theme design right now. In the moment I am experimenting to get an understanding of Moodle 2.0 basics.

Are you able to give a rough estimate when the CSS properties and files in Moodle 2.0 are set up and stable enough to start working on theme design without the need to change too often?

Will it be mid January, end of January, February?

Average of ratings: -

Permalink | Show parent | Reply

I'm just listening to Greg Lake's -

and wondering how Moodle 2.0 is shaping up!

Average of ratings: -

Permalink | Show parent | Reply

Dear all,

Thanks for the inclusion of pix_url - really useful, but can it be used with Course Formats too? http://docs.moodle.org/en/Development:Themes_2.0 hints at modules and other plugins, if so what would be the format of the parameters to the function please?

Say if I have an image stored in '/course/format/topcoll/pix'?

Thanks,

Gareth

Average of ratings: -

Permalink | Show parent | Reply

pix_url can be used with any sort of plugin, you just have to use the right name for the plugin you are referring to.

For your example, that would be 'format_topcoll', instead of 'theme'.

If you really want to understand how this works, you need to follow through the code which goes like this:

pix_url outputs a link pointing to theme/image.php
that scrip calls resolve_image_location in lib/outputlib.php to actually find the image file you are asking for.
that calls get_plugin_directory from lib/moodlelib.php to get the acutual path to use for the plugin ($component).
and that uses the list of plugin types defined in get_plugin_types (also in moodlelib).

Average of ratings: Useful (1)

Permalink | Show parent | Reply

Dear Tim,

Thank you, really helpful, I'll give that a bash. I tried to follow the call hierarchy using - http://phpdocs.moodle.org/HEAD/index.html - but ended up using the Eclipse IDE with the Community Edition of the Zend Debugger with its call hierarchy functionality, but did not get far - still new to PHP in a transition from Java.

What IDE setup do you use for development work?

Cheers,

Gareth

Average of ratings: -

Permalink | Show parent | Reply

I use Eclipse + PDT.

I don't use any sort of PHP debugger.

However, I have been hacking on the Moodle code for over 4 years now, so I know my way around it quite well. I tend to just read the code with the help of CTRL + click, and when I get stuck I use echo statements to find out what is happening.

Average of ratings: Useful (1)

Permalink | Show parent | Reply

Dear Tim,

Thanks

On a separate note but related to this thread, I'm also creating a theme so that my employer could update to Moodle 2.0. In creating it with the layout files I notice that there are lots of different layouts (bottom of http://docs.moodle.org/en/Development:Themes_2.0#The_different_layouts_as_of_March_29th.2C_2010) and as the current installation has a custom 'My Moodle' will there be an entry for My Moodle in this list so that a layout file can be provided for it?

Opps, just firebugged the page and noticed the 'pagelayout-mydashboard' css class on the body tag, so as I've not made the mental link on the documentation, could it be improved?

Cheers,

Gareth

Average of ratings: -

Permalink | Show parent | Reply

Talking of updating to Moodle 2.0, I hit on a problem last night and could not proceed with the install to latest version of Moodle 2.0 as I got this Fatal Error.

I would be interested if anyone could throw some light on the problem.

Mary

Average of ratings: -

Permalink | Show parent | Reply

Dear Mary,

Just updated using CVS to the latest version 20100603 and no problems, so is there a fault in your config.php file missing something like:

$CFG->dataroot = 'F:/moodledev/moodle2/moodledata';

??

Cheers,

Gareth

Average of ratings: -

Permalink | Show parent | Reply

I've had no problem with CVS on my local WAMP Server.

The problem I'm having at the moment is on my Host Server which is Linux/Zeus which Moodle 2.0 doesn't like! I have Moodle 1.9.8 on the same server, and that works OK...so I can't understand why Moodle 2.0 should choose not to work on this particular server configuration.

The reason I've got this fatal error is I tried to set up a Unix socket thinking that would work.

Mary

Average of ratings: -

Permalink | Show parent | Reply

Dear Mary,

I have a server configuration that works for 1.9 and 2.0 but not 1.8 even though it should support it, so it can happen even if the installation page says that everything is ok.

Have you tried a plain install without resorting to Unix sockets but just plain files and folders for the dataroot or normal unix path mapping (soft links I think they are called)?

BTW - I think this is now off topic and should be placed in the developers general forum?

Cheers,

Gareth

Average of ratings: -

Permalink | Show parent | Reply

Thanks Gareth,

I've already added a comment to an existing thread where a discussion is going on about various server platforms, as you so rightly suggest, as it is way off topic here.

Average of ratings: -

Permalink | Show parent | Reply