While the uses here were not causing too much problem with PHPUnit
execution in any OS, better have them explicitly closed to better
serve as reference for other, future uses anywhere in codebase.
Always that a stream is used, better we close it as soon as possible,
not relying on destructors, gc and friends.
And do it as soon as it's not needed any more. Else, only
_destruct() / shutdown / gc will, and that can be problematic
if many streams are open, or, under some environments like
Windows that consider the stream underlying files still busy,
because they have not been closed.
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.
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.
When an editor is renderer initially invisible to the browser, e.g.
the forum "Add discussion" form, it has a `clientHeight` value of
zero. We can approximate an alternative value based on the number
of rows in the textarea.
Co-authored-by: Andrew Nicols <andrew@nicols.co.uk>
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.
