Use core functions that are faster for test file creation.
To support large requests for hashes, the core hash function
must support large hashes without recursion. PHP has a default
recursion depth of 100 and long hashes don't support this.
Remove transactions as they create performance problems for larger
courses and doesn't introduce significant benefit for developers.
Performance changes meant the times were much faster, a reasonable
guess was taken on performance of an average machine.
1. getMock()
2. setExpectedException()
3. checkForUnintentionallyCoveredCode renamed to beStrictAboutCoversAnnotation
4. beStrictAboutTestSize renamed to enforceTimeLimit
5. UnitTestCase class is now fully removed.
Final deprecation of the following methods:
- course_modinfo::build_section_cache()
- cm_info::get_deprecated_group_members_only()
- cm_info::is_user_access_restricted_by_group()
Plus throw coding exception for direct calls of the following:
- cm_info::get_url()
- cm_info::get_content()
- cm_info::get_extra_classes()
- cm_info::get_on_click()
- cm_info::get_custom_data()
- cm_info::get_after_link()
- cm_info::get_after_edit_icons()
- cm_info::obtain_dynamic_data()
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
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).
