This only applied when themedesignermode was disabled, because the
first chunk is 0, but 0 is resolved to false. We needed to compare
$chunk with null in order to know if it was set.
Includes theme and renderer changes required for the new feature.
There are two parts: style required for the display as part of the
course page (when showing the list of conditions for an activity),
and style required for the settings form.
This change supports both the bootstrapbase theme (which was the
main theme used during development) and the old base theme.
There is a new theme property 'blockrendermethod' that can be set by the
theme in its config.php and tells Moodle what method it is using to render
blocks in the layout files.
Either blocks, or blocks_for_region.
Then when adding custom block regions to a page content we ensure we use
the same method the theme is using elsewhere.
This is really a hack becuase we (I) didn't properly deprecate
blocks_for_region when I added the blocks method.
This responsive image behaviour prevents setting of image sizes in text editors,
as well as a string of pix icon bugs / profile image bugs across Moodle.
We are switching to Bootstrap 3 syntax where you need img-responsive class to images
that want this behaviour.
In order for a chooser dialogue to be able to fall back to it's non-JS
equivalent, we need to use a different set of styles.
This change makes the chooser dialogue preparation function add a new class
to the body which is utilised in the CSS to accomplish this. When the class
is not present, the dialogue content is displayed inline.
There are a few reasons why I am cleaning up the calendar.less file.
1/ The variables were too specific, and unlikely to be overridden. If
you are going to change the colour of the background, surely you will
change the border to match the background. And if you want to do
more advanced things, you will override the selectors anyway.
2/ If you wanted to re-use the color of the event, but not as a
background or border, you would have to use a variable that
was specific to the background or the border, a generic
variable for the event colour seems required.
3/ The colour @redDarker should not be defined there, and its purpose
is so limited that I do not think we need it at all. Also,
this variable is unlikely to be re-used ever, better not
introducing it.
4/ I removed the calendarHeadingsColor because those headings should
really match the rest of the headings throughout the site. I
removed it from the overlay, but used the standard Bootstrap
one for the one in the page.
There are still a few things that would need improvement, like the
usage of @white for the background of the event, which will not really
look good on a dark background.
The rules or selectors removed appeared either not to be used any more
or were enforcing a rule that was not adequate and should not be
replaced by a variable. Basically, the focus was to simplify our
usage of the colours and variables to use LESS more efficiently.
