For clients that wish to consume the original value of the custom
field (e.g. timestamps for date fields), rather than the formatted
version, add a new "valueraw" property to the returned data.
When plugins are removed from disk, an exception is thrown when
calling component_callback_exists.
This exception should be catched here in order to load properly
the activity chooser (otherwise, the exception will be displayed
and no activity will appear).
Under parallel development, when something is worth being commented
in upgrade.txt notes, it will be applied to all the development branches
using the "earliest" one to be released. So, if something changes
in 3.10 (and also is applied to master), the upgrade.txt notes will
show 3.10 in both branches.
Of course, if something only goes to one dev branch (say master), then the
master version will be used in the notes (4.0 in this case).
1) Remove any floatval() casting. They are breaking / killing
.10 versions (converting them to .1). Since Moodle 2.0 all the
backup::RELEASE have been 100% numerical values.
2) Use version_compare() always to compare backup::RELEASE values.
They are always versions and the function is aware of versions
> .9, able to clean/ignore alpha chars... and everything else.
Note that I've also changed a couple of cases in formats (topics and
weeks) that were correct, but just added the same comment and used
the same version_compare() comparison parameters style, so all uses
in core are consistent (and safe to be copied out there).
version = 2021052500 release version
requires= 2021052500 same than version
Why 20210525? (25th May 2021) ?
Because master is going to be Moodle 4.0, to be released
on November 2021. And, until then, we are going to have
a couple of "intermediate" releases:
- Moodle 3.10 to be released 9th November 2020. (2020110900)
This version will be using versions from today to 2020110900
(once it's released the YYYYMMDD part stops advancing).
- Moodle 3.11 to be released 10th May 2021. (2021051000)
This version will be using versions from 3.10 release to 2021051000
(once it's released the YYYYMMDD part stops advancing).
That means that all versions from today to 2021051000 are going
to be used by those 2 "intermediate" releases (3.10 and 3.11).
And we cannot use them in master, because it's forbidden to have
any overlapping of versions between branches (or different upgrade
paths will fail).
So, get that 2021051000, let's add it a couple of weeks to cover
the on-sync period (or a 2 weeks delay max!) and, the first version
that master can "own" in exclusive (without any overlap) is, exactly,
25th May 2021, hence our 20210525.
version = 2021052500 release version
requires= 2021052500 same than version
Why 20210525? (25th May 2021) ?
Because master is going to be Moodle 4.0, to be released
on November 2021. And, until then, we are going to have
a couple of "intermediate" releases:
- Moodle 3.10 to be released 9th November 2020. (2020110900)
This version will be using versions from today to 2020110900
(once it's released the YYYYMMDD part stops advancing).
- Moodle 3.11 to be released 10th May 2021. (2021051000)
This version will be using versions from 3.10 release to 2021051000
(once it's released the YYYYMMDD part stops advancing).
That means that all versions from today to 2021051000 are going
to be used by those 2 "intermediate" releases (3.10 and 3.11).
And we cannot use them in mater, because it's forbidden to have
any overlapping of versions between branches (or different upgrade
paths will fail).
So, get that 2021051000, let's add it a couple of weeks to cover
the on-sync period (or a 2 weeks delay max!) and, the first version
that master can "own" in exclusive (without any overlap) is, exactly,
25th May 2021, hence our 20210525.
Before this change if a user used navigated to a resource activity
from another activity and then edited the settings it was likely
that using the cancel button would result in file downloading,
rather than being returned to their last page.
After this change the user will be back on the page they came from.
Padding nested course categories by space to make them render in a tree
structure does not really make a lot of sense as they are already being
rendered as full paths. It's simpler to show them without the
indentation.
Given this, there's not much point keeping make_categories_options().
So it's better to deprecate this function and call
core_course_category::make_categories_list() directly instead.
Adds filtering on the completion criteria form to ensure we are only
selecting actual course instances of this type. Prior to this change
we would also get NULL values from unrelated criteria types.
* Added aria-label for category single select element when on Courses
view mode.
* Fix correct labelling of custom control checkboxes. Instead of adding
aria-label in the label element, add an sr-only span within the label.
* Remove inappropriate 'group' role for the list of courses.
The list of courses is not being rendered as a tree structure
so adding a 'group' role to the list of courses is not really
necessary.
* Add aria-label for the search courses field.
* Add legend for the search courses fieldset.
* Use the primary colour for the category selection highlight instead
of the info colour.
* Changed the labels for the up/down icons using moveup/movedown
lang strings.
