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.
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
We should be proactive in ensuring that the environment is clean when
running a task. We already ensure that we have a clean renderer and
other parts of the output chain, but we were not setting a clean user.
This change adds a call to setup the cron user before each task is
actually executed.
* CLI adhoc_task.php: new option --taskslimit
* CLI adhoc_task.php: --execute option is implied when other options are given
* core\task\manager::get_next_adhoc_task(): new param $number
for limiting number of tasks to run
* 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
Adding LIMIT to the primary auth type SQL statement does not play well
with Oracle. We can just remove the LIMIT clause from the SQL statement
and and pass IGNORE_MULTIPLE to the call to $DB->get_field_sql()
instead.
When fetching the list of tasks to run, we were using the _process_
start time as a base. The various task fetchers (adhoc and scheduled)
only fetch tasks which were due to run _before_ this time.
With the new keepalive setting, we need to pass both the process start
time, and the run start time. We need to use the process start time to
determine whether MUC caches have been cleared since the process
started. but the run start time to fetch recent runs.
The Assignment 2.2 activity module was disabled in 2012 but kept to
enable pre-2.2 backups to be restored and have the assignments
auto-converted to new assignments. After almost 10 years, it's time
to remove it from Moodle core.
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.
Jake Dallimore