We now abstract the actual file generation to a new function.
We are then able to call this function from the other image generation
sources. This allows us to generate thumbnails in a more efficient manner.
* Stored files stay as stored files and are not temporarily re-written to
disk;
* Strings containing an image remain as a variable and are not temporarily
written to disk; and
* Arbitrary files are not captured to string.
touch should only work on temp and below
dir's. With path we get temp/.. and temp/.
So we were modfying moodledata dir as well
and it was failing because of permission issues.
This adds functionality to create individual request directories which can
be only be used for the current request. They are removed by a shutdown
handler.
While default value did not change from 7 days... there are subtle
differences between strtotime('-1 week') used in tests and
-(7*24**3600) used in implementation.
This just makes the unit test to follow the implementation by
using the new config setting.
Disclaimer: I've assigned this commit to MDL-47572 because it's
the issue where I've seen related changes.
Since a couple of days ago, both CI servers were failing. A couple
of days ago it was DST change in Europe/Madrid (that is the PHP
default TZ used by them).
Tests pass perfectly if the TZ is set to any other place not affected
by DST (Australia/Perth, for example).
Really the issue is a wrong mix of functions supporting DST and
functions not supporting them.
But, with current implementation (checking +-60 seconds around a time)
and with a DST change in the middle... this unit tests was going to be
failing for an entire week. And that's not acceptable for CIs.
So, I've changed the intervals, to be bigger than 1h (exactly 1h1s), so
they will be immune to the DST change/partial support.
Ideally all operations should be working in the same way (with or
without DST considered), but that's out from the scope of getting this
test stable enough and passing.
Browsers may not provide html content in the clipboard object event
though it will really be pasted as such. This includes Firefox on
Windows, Internet Explorer, and some niche cases in Safari.
Because of this, we need to scrub the entire editor anytime we can't
intercept a paste event.
In some magical day in the future when there is better cross browser
support, we can undo this.
