Just thought I would let you all know how I was getting on. I just committed a big lot of changes to CVS.
This is basically a rewrite of print_header and print_footer, so that instead of using header.html and footer.html, it uses a single file layout.php. Also, if you wish, for certain pages you can have a different template. layout-home.php and layout-popup.php are the ones I am thinking of initially.
The layout.php file for the standard theme looks like http://cvs.moodle.org/moodle/theme/standardwhite/layout.php?view=markup
This is all very much work in progress. I have just spent several days untangling the mess that is the old print_header, and have got to the 'wow, you mean it actually seems to work!' stage. I am sure there are still bugs that need to be found and fixed. Also there is more cleaning up to do in related code.
However, becuase it is still very much in flux, this would be be a good time for people to have a look and give feedback, because it is not too late to change things if people have further good ideas.
(By the way, if you have a Moodle 1.9 theme with header.html and footer.html, but not layout.php, that will still work, becuase I wrote fall-back code.)
Wow! This is good.
Does it mean we always do buffered output? I'm somewhat confused how it works with our existing programming style. Unless you are reading the template into a string, splitting it / parsing it, and eval()/executing it from memory.
Does it mean we always do buffered output? I'm somewhat confused how it works with our existing programming style. Unless you are reading the template into a string, splitting it / parsing it, and eval()/executing it from memory.
print_header/footer were already doing buffered output in 1.9, so that aspect has not really changed.
The code is here: http://cvs.moodle.org/moodle/lib/outputlib.php?view=annotate#l836
layout.php is included in $OUTPUT->header. The result is then sliced in half, and the footer stashed away for later.
The trick is, of course, how you get dynamic information like performance info, and all the required links to JavaScript, which may change during the rendering of the page contents, into the footer. The answer is I put a couple of unique strings in the footer that are then str_replaced in $OUTPUT->footer.
Before you ask, I have not profiled this yet.
I am quite pleased that $OUTPUT->header fits on one screen. Rather better than the old print_header.
The code is here: http://cvs.moodle.org/moodle/lib/outputlib.php?view=annotate#l836
layout.php is included in $OUTPUT->header. The result is then sliced in half, and the footer stashed away for later.
The trick is, of course, how you get dynamic information like performance info, and all the required links to JavaScript, which may change during the rendering of the page contents, into the footer. The answer is I put a couple of unique strings in the footer that are then str_replaced in $OUTPUT->footer.
Before you ask, I have not profiled this yet.
I am quite pleased that $OUTPUT->header fits on one screen. Rather better than the old print_header.
print_header/footer were already doing buffered output in 1.9, so that aspect has not really changed.
They use OB internally, right. But they don't use it over the execution of the page which is what my unfounded fears were about.
The code is here...
Ah! I see what you're doing, makes sense. I pictured for a moment weird schemes that abuse OB and eval().
Hi Tim,
Is there an issue in the tracker for "officially" reporting bugs? I get the following error message when trying to open a chat window:
"Coding error detected, it must be fixed by a programmer: $PAGE->context accessed before it was known."
Cheers,
Frank
Is there an issue in the tracker for "officially" reporting bugs? I get the following error message when trying to open a chat window:
"Coding error detected, it must be fixed by a programmer: $PAGE->context accessed before it was known."
Cheers,
Frank
Just file new bugs and try to make sure they get assigned to me. If possible, turn on DEVELOPER Debugging and copy the full error message into the bug report, including the stack trace. That will probably save me some time.
The main bug for doing the changes is MDL-19077, so I suppose you could just add comments there, but really these are bugs, so should be reported.
The main bug for doing the changes is MDL-19077, so I suppose you could just add comments there, but really these are bugs, so should be reported.