I am going to commit first part of major theme changes today. It is relatively large patch touching many areas. I would like to ask for a bit of patience because there will be several regressions that will be fixed later this week.
This week we are going to work more on internal changes, such as YUI2+YUI3 integration, navigation refactoring, outputlib improvements, etc. I will have to update the docs site too.
I suppose sometime next week the HEAD should be ready for the actual development of new themes. I will keep you informed here.
You can watch progress in tracker, see MDL-20204 . Thanks for your patience, these theme changes may hurt a bit I am afraid
Do I need to work with a fresh 2.0 or is there a bug?
_ 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.
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.
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
Registered theme designers???
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
- and all changes are not yet even implemented...
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
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.
Could you please update Development:Theme_changes_proposal to Development:Theme_changes to document the actual state?
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.
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!
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.
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?
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.
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.
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.
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".
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...
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... :
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 got extra JS loaded the following way:
_ add the following setting to config.php
Ah - now I think I found the reason why I thought it might not work...
using the same method as you said here.
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.
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.
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?
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"...
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
It used to work when I originally implemented it, looks like a recent regression. Going to fix it today, sorrrry.
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? )
Happy New Year!
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.
Happy New Year to you all!
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...
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(
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.
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
I wish everybody a good new years night and a successful year 2010.
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.
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.
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...
@"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."
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."
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.
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.
Thanks for all your valuable feedback!!
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! 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:
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...
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)
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...
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.
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.
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?
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?
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.
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?
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]])"?
* 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
* ... 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.
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.
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.
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.
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
This looks inconsequent - I would expect the second statement to be
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.
2) possible to override the headingmenu output when it is output via a renderer via $OUTPUT.
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
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.
In any case I would strongly discourage you to override plugin renderers in 2.0 because they will probably change a lot.
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.
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
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).
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?
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'?
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).
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?
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.
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?
I would be interested if anyone could throw some light on the problem.
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';
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.
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?
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.