This functionality was commented out in
78946b9bdb1299a21f00b88d81c73ad8700c951e 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
Moodle 3.2 and up will require PHP >= 5.6.5. Hopefully some day we'll
have this centralized with MDL-39007, just it's not done yet.
Thanks to Stephen Bourget for raising this!
There was a problem with core\update\code_manager::unzip_plugin_file()
if it was used to extract a plugin package into a non-empty target
directory and the plugin package root folder was being renamed at the
same time.
The problem was caused by the underlying helper method
rename_extracted_rootdir() that worked only for ZIPs extracted to an
empty temporary location. When the plugin was extracted to the actual
dirroot with other existing plugin folders present, the method failed
badly.
The solution in the patch is to always extract the ZIP into a temporary
empty location, perform the eventual root renaming there, and only then
move the extracted contents to the final destination. Additionally we
are changing the behaviour of the rename_extracted_rootdir() method so
that now it throws exception if the plugin package contains multiple
root folders (it should not happen in normal situations as such a plugin
would not pass the pre-install validation).
Unit tests did not catch this bug before because in the tests, the
target directory had been empty. Now we are adding a new directory
"aaa_another" to the target location to test in more realistic
environment. Tests for the new behaviour of the renaming method are
added, too.
p.s. I noticed that moodle_exception class was not imported into the
namespace and this is fixed now too (and covered with unit tests).
PostgreSQL 9.1 allows hex formating for binary which is handled better
by pg_query_params().
Getting bytea isn't required on connection, it can be used as pg_field_type()
when binary needs to be checked.
The changes in this commit should not be problematic, just:
- different whitespace.
- some docs.
- 1 variable to camelCase.
And then, less trivial, but safe enough IMO:
- a change to camelCase some identifiers and their calculation.
component, filearea and itemid are now optional parameters.
In some contexts those parameteres are not necessary because is not
required to do a file rewrite via file_rewrite_pluginfile_urls
useredit_update_picture as moved to user_update_picture
as it's more general. It was also moved to user/lib.php
so it can be used by both webservices and edit without more include files.
The original issue here was that each loop of the named values did not
check for prototypal properties. As a result, if there were input fields
with names such as 'sort', 'valueOf', 'constructor', etc. these would
return their prototypal functions instead of a falsy value, and be treated
as though they are array - hence the 'Cannot push to Function' type error.
Following on from this I discovered that the data stores were being created
as arrays, but used as objects. This can also cause issues with some form
input names -- e.g. if they are numeric.
These two issues were resolved together by correctly storing them in
objects, and checking that those objects had real properties
(hasOwnProperty). This itself has to use the prototypal function to cater
for the potential of a field name called 'hasOwnProperty'.
I also found that the instance value stores were being initialised in the
prototype (and therefore shared), which meant that there were numerous
issues if two forms were present on the same page, or one form replaced an
existing one (e.g. forms initialised in JS).
In addition, it also became apparant that several values were being used
outside of scope, or in the wrong scope. This caused further issues when
creating multiple forms on a page.
