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.
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.
* Block authors no longer need to set $this->content_type
* If you want to make a "list" block, just derive from block_list
instead of block_base
* All switch() statements gone from library code
* Overloaded method is_empty() added to block classes for convenience
tjhunt