The legacy M.core.event.BLOCK_CONTENT_UPDATED event has been replaced with a
new core_block/events::blockContentUpdated native DOM event.
The new event can be triggered using the `notifyBlockContentUpdated`
event, and by providing the HTMLElement that was updated, for example:
```
import {notifyBlockContentUpdated} from 'core_block/events';
const someHandler = e => {
// ...
const updatedBlock = e.target.closest('.block');
notifyBlockContentUpdated(updatedBlock);
};
```
The new event can be listened to at any point in the DOM using the
following syntax:
```
import {eventTypes} from 'core_block/events';
const handler = e => {
// The block that was updated.
e.target;
// The id of the updated block.
e.detail.instanceId;
};
document.addEventListener(eventTypes.blockContentUpdated, handler);
```
A backward-compatabibility layer is included to ensure that any legacy
YUI event listener is still called with the same arguments.
This legacy bridges will be removed after Moodle 4.3.
The legacy M.core.event.FORM_ERROR event has been replaced with a new
core_form/events::formError native DOM event.
The new event can be listened to at any point in the DOM using the
following syntax:
```
import {eventTypes} from 'core_form/events';
document.addEventListener(eventTypes.formError, handler);
```
A backward-compatabibility layer is included to ensure that any legacy
YUI event listener is still called with the same arguments.
This legacy bridges will be removed after Moodle 4.3.
The legacy M.core.event.FILTER_CONTENT_UPDATED event has been replaced with a
new core_filter/events::filterContentUpdated native DOM event.
The new event can be triggered using the `notifyFilterContentUpdated`
function, and by providing with an Array containing the HTMLElements
that were updated, for example:
```
import {notifyFilterContentUpdated} from 'core_filter/events';
const someHandler = e => {
// ...
const nodeList = Array.from(document.querySelectorAll('div'));
notifyFilterContentUpdated(nodeList);
};
```
The new event can be listened to at any point in the DOM using the
following syntax:
```
import {eventTypes} from 'core_filter/events';
const handler = e => {
// The list of HTMLElements in an Array.
e.detail.nodes;
};
document.addEventListener(eventTypes.filterContentUpdated, handler);
```
A backward-compatabibility layer is included to ensure that any legacy
YUI event listener, or jQuery event listener are still called with the
same arguments.
This legacy bridges will be removed after Moodle 4.3.
The legacy M.core.event.EDITOR_CONTENT_RESTORED event has been replaced
with a new core_editor/events::editorContentRestored native DOM event.
The new event can be listened to at any point in the DOM using the
following syntax:
```
import {eventTypes} from 'core_editor/events';
document.addEventListener(eventTypes.editorContentRestored, handler);
```
A backward-compatabibility layer is included to ensure that any legacy
jQuery event is still called with the same arguments.
This legacy bridge will be removed after Moodle 4.3.
The `types` object introduced in Moodle 3.11 has been replaced with the
`eventTypes` object which is used consistently across all CustomEvent
definitinos.
Likewise the trigger functions have been renamed from
`triggerUploadStarted` to `notifyUploadStarted` and from
`triggerUploadCompleted` to `notifyUploadCompleted`.
Backwards compatability is maintained.
The legacy core/event::FORM_FIELD_VALIDATION event has been replaced with a
new core_form/events::formFieldValidationFailed native DOM event.
The new event can be listened to at any point in the DOM using the
following syntax:
```
import {eventTypes} from 'core_form/events';
document.addEventListener(eventTypes.formFieldValidationFailed, handler);
```
A backward-compatabibility layer is included to ensure that any legacy
jQuery event is still called with the same arguments.
This legacy bridge will be removed after Moodle 4.3.
The legacy M.core.event.FORM_SUBMIT_AJAX ecent has been replaced with a
new core_form/events::formSubmittedByJavascript native DOM event.
The new event can be listened to at any point in the DOM using the
following syntax:
```
import {eventTypes} from 'core_form/events';
document.addEventListener(eventTypes.formSubmittedByJavascript, handler);
```
A backward-compatabibility layer is included to ensure that any
legacy YUI event triggered on a form is still respected and the new
native event is also fired.
A similar handler is also included to ensure that any legacy YUI event
listener is still called with the same arguments.
These legacy bridges will be removed after Moodle 4.3.
The `get_list_of_plugins()` function is used to fetch plugin-like files
or directories from a specified directory. A number of standard
exclusions are included but this list is not the same as the list in
`core_component`.
The list has been updated to include the `amd` directory, which is
regularly used in both components, and plugins.
With significant-digits presentation mode, NAN would be formatted as
'NAN' followed by zeroes, which looks silly, and +INF would cause an
execution timeout as Moodle tries to divide +∞ by 10 until it becomes
less than 1, which can happen in a divide-by-zero situation.
Note that the user can't answer NAN or INF to any question, but at this
at least now looks consistent and also doesn't break Moodle in the case
of +INF.
The step "And I wait until ".block_myoverview
[data-control='next']" "css_element" exists" is not correct
because this [data-control='next'] element exists before and
after the step so, in some cases, it might cause the following
step will start earlier than expected.
As pending JS has been added, this wait steps are not required
any more.
Activity modules may not have the associated grade_item created yet. It
used to throw fatal error in that case - even when trying to view the
course or edit the activity. So there was no easy way to recover from
this situation.
The patch is based on reasoning that an activity without grade item is
same as activity without any grades. And as such it is considered
incomplete.
A new unit test is added to cover this specific scenario. The existing
unit test is modified and it does not expect the exception any more.
There does not seem to be any good reason why this situation should be
exceptional.
