This check-in removes about 400 lines of code. I hope I have not screwed anything up. I would be grateful if people could review this change, and keep an eye on the navigation bar in modules.
Any navigation bar bugs you find in the near future, feel free to file them in the tracker and assign them to me. Thanks.
If not to many problems are found, I think I would like to backport this to 1.9 stable, but I am not sure that is a good idea. Opinions to the General Developer Forum please. I am about to start a thread there.
With this patch we preload the child contexts for the course
and hold on to them. This means that in one DB query we have all the contexts
we are going to need.
The checks for user_allowed_editing() move from weblib:update_icon() to
user_allowed_editing(), where we cache the result, and in the process save
50% of the cap checks by testing separately blocks from modules (doh!).
Still, the cap checks here are very inefficient...
With the last 3 patches, a course page with default blocks and 9 modinstances
goes from 157 to 86 db queries when logged in as a non-editing user (guest,
student). As admin it drops from 88 to 81.
Conflicts:
lib/pagelib.php
- Removed $course parameter from build_navigation()
- Updated all calls to build_navigation()
Author: Matt Clarkson <mattc@catalyst.net.nz>
Committer: Matt Clarkson <mattc@catalyst.net.nz>
- Modified page class to use build_navigation for creating breadcrumbs.
- Added print_header method to page_generic_activity to make derived
classes print the page headers the correct way.
Author: Matt Clarkson <mattc@catalyst.net.nz>
Committer: Matt Clarkson <mattc@catalyst.net.nz>
Fix for bug 3637:
Certain obscure cases of using PHP accelerators (probably has to do with
OS and PHP version as well, but it's not certain) caused an error to be
displayed when importing data from "local pagelib" files with "debug" turned
on. The error was bogus, but error() stopped the page from being displayed.
Thanks to James P. Dugal the from University of Louisiana at Lafayette for
identifying and helping to solve the problem!
meant to do all this time (keep Moodle working for people who had already
upgraded to early versions of 1.5).
This fixes bug 2965, thanks Penny for reminding!
page_generic_activity. Then we can inherit almost all of the desired
behavior and just override a couple of functions to get going with page
support in a new activity.
The format for each page is now the same as the id attribute of the
BODY tag, which in turn is a simple function of the script's relative path:
The format for e.g. a quiz view page is "mod-quiz-view". The format for the
site index is "site-index". Exception: the format for courses is not just
"course-view", but "course-view-weeks" etc.
Obviously the applicable_formats() override for each block should now take
this into account. The matching rules now are:
* You can specify the full format, e.g. "mod-quiz-view" => true
will allow the block to be added in quizzes
* Prefixes match the full page format, e.g. "mod" matches ALL activities
* You can use "*" as a wildcard, e.g. "mod-*-view" matches just the view.php
page of all activities
* These rules interoperate, thus "mod-*" is the same as "mod"
* "all" remains as a catch-all situation
Not everything is quite right now, a few details (e.g. correct breadcrumbs)
have been ignored but most of the functionality is there.
Blocks in quizzes, here we come!
The new constant is PAGE_COURSE_VIEW, and it's more streamlined with the
new CSS-related ids for 1.5. There are great possibilities for the future
here, so we 're getting ready.
On the other hand, this has to be the ugliest hack I 've ever inflicted
on any program (look at pagelib.php). Thankfully it will only stay for just
a little while.
