Although the screenshots in the failures for some of the scenarios in
filter/displayh5p/tests/behat/h5p_filter.feature, like "Render a local
H5P file as teacher" were displaying the expected result, there were
some javascript errors (probably due to behat is quicker and the
iframes were not always ready).
I've added one extra step before accessing the iframe to give more
time to the H5P player to load and confirm the page is displayed
properly.
* The object returned by update_question is alwasy a new clone
and the $question passed in will not be modified.
* The returned object has the fields like questionbankentryid and
the ones related to versionning, so it is more like the data
returned by question_bank::load_question_data.
The used the exist in Moodle up to 3.11, but then was removed with
insufficient thought in 4.0 (because we had grander long-term plans
which still have not happened). Until those plans happen, this
commit adds the simple link back on the preview screen.
When the two restore forms for searching courses and categories were
converted to core templates in eb9935c9 they lost the named submit
button, which broke searching.
The widgetbase module was intended to be a generic search widget,
despite its location in grade/amd/src. As such, other modules may
depend on this. This was modified in MDL-76246, which added new
requires params to the js, and changed the js to expect certain new
data attributes in the templates. This broke b/c for existing
dependents.
This patch makes sure the existing uses of the basewidget continue
to work by adding b/c code. See MDL-77991 which deals with deprecating
this search widget and replacing it with one that just implements the
desired combobox logic, without the b/c code. That issue should also
make it abundantly clear that this widget is for public consumption.
When we deprecate the use of a file, we often include tests which ensure
that the legacy behaviour is maintained. There are also legacy uses
in the community where people would like to use the deprecated API for a
period.
The issue that we face is that, if the deprecated file is included once,
then it will be included for all other, unrelated, tests. This means
that other tests may not detect cases where the deprecated file was
included.
We can solve these cases by running the test that performs the inclusion
in a deprecated process. This means that the inclusion is only performed
in that isolated process, and other unrelated tests do not include the
file.
However, we also then need to detect which files which are including the
file and which we do not know about.
This change introduces:
- an override to the TestCase::setInIsolation method to define a
constant when the test is running in isolation
- a new function that a file can call when it is included, to make sure
that the test process was isolated, where there is any test.
Move the fixed assignment removal upgrade code to the end of the upgrade
script as a new upgrade step. Already upgraded sites with mod_assignment
removed should just be able to rerun this without any issues.
