This mostly works now, but ...
* The UI needs further work. In particular we need a non-advanced mode.
* This only works for blocks that use a new edit_form.php to replace config_instance.html.
* .. and so far I have only implemented edit_form.php for the HTML block so far.
* Needs to be enabled (with no block-specific config) for blocks without instance config, so you can control their positioning.
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.
There is a new implementation of require_js in lib/deprecatedlib.php,
based on $PAGE->requires.
There were a few other recently introduced functions in lib/weblib.php,
namely print_js_call, print_delayed_js_call, print_js_config and
standard_js_config. These have been removed, since they were never in
a stable branch, and all the places that used them have been changed
to use the newer $PAGE->requires->... methods.
get_require_js_code is also gone, and the evil places that were calling
it, even though it is an internal function, have been fixed.
Also, I made some minor improvements to the code I committed yesterday
for MDL-16695.
All that remains is to update all the places in core code that are
still using require_js.
(This commit also fixes the problem where the admin tree would not
start with the right categories expanded.)
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
The block incorrectly links to site profile in the current pageid.
This doens't make sense in a number of different scenarios, but
most notably if the user who messaged isn't enrolled in the current
course. Instead link to the profile at site context like the messaging
popup does.
Fixes: MDL-18279 MDL-6890 MDL-5887
merged from MOODLE_19_STABLE
