even non-course and sticky blocks.
The parent context is block_instances.parentcontextid.
The block context should be used for checking permissions directly
related to the block, like moodle/block:view or moodle/site:manageblocks.
However, if the block is displaying information about the current page,
for example the participants block showing who 'here', then it may be
better to use the context of the page where the bloack is appearing -
in other words $this->page->context - to check permissions about the
user's ability to see participants here.
Or, if the block is displaying something stronly related to courses,
for example, a course meny block, the block should probably use the
context for $this->page->course to check permissions.
The code to print blocks in now in theme layout.php files. (Or in
moodle_core_renderer::handle_legacy_theme)
Code for printing blocks everywhere else has been stripped out.
(Total diffstat 1225 insertions, 2019 deletions)
The way the HTML for a block instance is generated has been cleaned
up a lot. Now, the block_instance generates a block_contents
object which gives a structured representation of the block,
and then $OUTPUT->block builds all the HTML from that.
How theme config.php files specify the layout template and block
regions by page general type has been changed to be even more flexible.
Further refinement for how the theme and block code gets initialised.
Ability for scrits to add 'pretend blocks' to the page. That is,
things that look like blocks, but are not normal block_instances.
(Like the add a new block UI.)
Things that are still broken:
* some pages in lesson, quiz and resource. I'm working on it.
* lots of developer debug notices pointing out things that
need to be updated.
Start calling $PAGE->set_url in all the places it will be necessary
Start of a stub implementation of $PAGE->blocks to stop other things breaking
Remove some of the special case methods in admin_page
* Rename filter base class from filter_base to moodle_text_filter
* Remove unnecessary explicit constructors in moodle_text_filter
subclasses
* New filter_manager class, rather than static methods in filter_base
* Move some logic out of weblib, and into filter_manager
* Count filtering ops when $CFG->perfdebug on, via
performance_measuring_filter_manager
* Kill unused filter_string function. Petr said it should have been
private to weblib
This is messy because the links are hidden in the configdata column, which is serialized and base64encoded. So we have to untangle that, then ask the block whether there are any bits of $config that need to be fixed, then re-encode it before backup up. And reverse that on restore. It needs to remain base64 encoded in the backup file, so that the file format is backwards compatible.
I disucssed this with Eloy before doing it.
Merged from MOODLE_19_STABLE.
