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.
Previously the content of the stored file was extracted and stored in a
variable, passed around, and then submitted to MoodleNet. This results
in very high memory consumption when dealing with MoodleNet.
The stored_file should be passed around as a first-level param to
discourage this, and the content should _never_ be loaded into memory.
Instead file streams and resources should be used to allow Guzzle/Curl
to buffer the file from disk/other storage straight to MoodleNet.
We shouldn't invent fileareas with invalid values (specifically in
this case, the `itemid` overflowed maximum length of the field on
Oracle).
Given the generated file is transitory in nature, instead store it
in the users draft area.
This makes it possible to share a single activity to a MoodleNet
instance (which has been enabled for sharing in site admin).
This utilises the core\moodlenet\activity_packager to create an
activity backup, then sends it using the MoodleNet create resource
API specification.
Originally implemented as MDL-75932
This makes it possible to package a single activity as a Moodle backup
file, excluding user data so it is ready to be shared as a MoodleNet
resource.
Co-authored-by: Michael Hawkins <michaelh@moodle.com>
Originally implemented as MDL-75932
- Only resize if the H5P EmbedCommunicator is defined (otherwise, it was causing a
JS error)
- An unnecessary image has been removed from the greeting-card.h5p fixture package.
That way, the text will always be displayed (even if the iframe is still not
resized). Instead of replacing the original greeting-card-887.h5p file, I've
renamed it to greeting-card.h5p, to remove these ugly and unnecessary numbers
at the end of the file name).
When questions are filtered by tags in the question bank, the qtagids
params are passed in the array format. Though moodle_url handles this,
single_button::export_for_template cannot. Hence changes done in
weblib.php to provide params for export_for_template in the
suitable format.
Thanks Huong. I have added the Behat test you provided in the patch.
* CLI adhoc_task.php: new option --id
* cron::run_adhoc_task($taskid) for running tasks by id
* core\task\manager::get_adhoc_task($taskid) for retreival/locking
* The file file_remove_editor_orphaned_files should take into account URL that
have been embedded in a tag content instead of an attribute (like src attribute)
* This will fix issue with inserting H5P content in calendar events.
Add the DB type, count of courses with start or end dates set,
default site theme, and primary auth type statistics to those
collected as part of the site registration data.
