Support use of a token for access to pluginfile.php when rewriting text
content.
This is primarily intended for notifications where the user is unlikely
to be logged into Moodle when receiving the notification.
Files that are oversized could have been uploaded by a user who
can ignore the file size limits. These files should not be deleted
in these situations.
Without this change, Moodle fails to provide any data when requesting a
thumbnail for a non-image file as its looking to provide a SVG file that
doesn't exist.
text areas can now specify $options['removeorphaneddrafts'] when saving
their data using file_postupdate_standard_editor(). If set to true,
this option clears all user drafts which are not referenced in the text
Even when course module is not available the intro text can still be visible on the
course page. In this case the availability restriction is displayed to the student
but link to the activity is not available
This introduces a new "controlled link" file type where the file is not
stored in Moodle - but Moodle will control the access permissions on the file.
Plugins can "freeze" a filearea which means Moodle will take ownership of all the remote
files of this type.
When accessing a file, if the "filebrowser" infomation indicates the current user can write to the file, they
will be granted temporary write access.
Part of MDL-58220
The function send_content_uncached() is meant to be used when serving
content which should not be cached by browsers/proxies. You will
use this in development mode, or when the request is malformed
but you need to return some fallback content which shouldn't be stored
under the URL it was requested from.
The function file_safe_save_content() should only be used for content
not stored in the file API. Good candidates for this are resource
which fit well in the localcache. The function tries to write the
content in the most atomic way as possible to prevent incomplete
writes or concurrent writes.
This functionality was commented out in
78946b9bdb for MDL-20204 back in 2009.
Since then it has been wasting cycles performing utterly pointless
preg_match and preg_replace calls.
The decision has been made to deprecate it in stables, and remove it in
3.2.
This was a complex change requiring three new functions:
file_merge_files_from_draft_area_into_filearea - To just add files from a draft area into a real one (just adding or updating, not deleting)
file_merge_draft_area_into_draft_area - To merge files from two draft areas, used by the latest for creating a draft area with all the original files plus the new ones.
file_overwrite_existing_draftfile - Required to update existing files not losing metadata or references.
The whole process is the following:
User uploads a file (upload.php)
Client gets a new draftid A containing the file only (return of upload.php)
Client requests to merge that draftid in the user's private files (core_user_add_user_private_files)
Server prepares a new UNUSED draftid B from existing area
Server merges A into B
Server saves the draft B into the final area
Andrew Nicols