It seems to be better to check for required permission later, when the
button to install the update is actually being displayed. Credit goes to
Dan Poltawski for suggesting this.
This class represents the communication bridge from Moodle UI to the
(standalone) mdeploy.php utility. It consists of various helper methods
useful when dealing with user interface, update confirmation etc.
The class is implemented as a singleton. This allows us easily
transfer required data from top level scripts (like /admin/index.php)
into the rendering methods deep in the stack without the need to change
the API of many methods on the way.
The Notifications (admin/index.php) page has now information about
available updates for core and eventually plugins, too. Note that the
structure of the available updates array changed. This breaks backward
compatibility for eventual 3rd renderers out there (not expected
though).
This commit simplifies the logic, so that $CFG->undeletableblocks
applies to all blocks, not just ones on certain page types in the
system context.
It also makes the setting apply to adding blocks, so you cannot
accidentally add a block that you cannot delete.
Rather than overloading the $CFG->bloglevel setting which had a
confusing UI in the appearance subsystem.
In order to achieve this we modify take the defaults from the existing
bloglevel setting and set that for $CFG->enableblogs. Note that in order
to prevent a bad default settings from being set we also set
$CFG->bloglevel to a valid 'enabled' setting.
1. get_context_name should respect the $CFG->courselistshortnames
setting.
2. When $CFG->courselistshortnames is on, what to display should use a
language string, rather than string concatenation. This makes it
possible for people to configure the display. For example, they might
want 'My first course [M101]' instead of 'M101 My first course'.
This fixes WCAG 2.0 compliance because we were already using HTML5 markup.
The strict XML headers setting never worked for production servers, developers
used browser validators for compliance testing. XHTML 5 option is relatively
similar to this obsolete option, but still it can not be used on production servers.
XHTML Strict 1.x was a standardised dead end, HTML5 is the new de-facto-standard
supported by all major browsers including latest versions of IE.
Please note nothing changes in our coding style because HTML5 is a superset of
several previous standards, it is recommended to use only features that are
already implemented in all our supported browsers.
Helen Foster