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).
The problem with the previous implementation was that the table's
$this->prefs can contain valid non-empty value in its default state -
the default column to sort by. On resetting, we must not throw away
these default prefs.
This patch simplifies the TABLE_VAR_RESET interpretation. If such an
HTTP parameter is passed via the request, the table simply behaves as if
there were no previously stored preferences (does not matter if coming
from the current session, or from the persistent cross-session storage).
The logic that decides on whether or not the reset widget should be
displayed is put into a new method can_be_reset() with unit tests
attached.
Finally, the previously private method render_reset_button() is now
protected and the reset widget is given a new semantic CSS class.
The upgraded version of HTML2Text highlighted some bugs in our unit tests.
In the IOS test, the HTML content includes a couple of patches of
In the previous version of HTML2Text, these were being converted to
breaking spaces. In one of these cases, it was then removed due to a trim.
The expected texts have been converted to use the correct non-breaking spaces.
In the case of the trimmed one, it is no longer trimmed as non-breaking
spaces are not trimmed.
This gives a truer reflection of the actual text.
In the case of the Outlook test, this trailing whitespace is not present in
the source. It was likely caused by a bug in the previous version of
HTML2Text.
In the case of the weblib change, the test was just wrong. Both of the
actual characters are encodings for an HTML bullet (decimal and hex) and
should both be converted to the relevant UTF8 representation of this
bullet.
Previously, the validator was used for installation of the new plugins
only. We now validate every incoming plugin package. As a result, we
must no longer insists on the target location is empty. Instead, warning
is raised.
The previous version of the plugin manager's method
get_remote_plugin_info() was suitable for installing missing
dependencies only. To make use of for installing new plugins and/or
available updates, it must be clear that we are requesting information
for the particular plugin version only, not "given or higher" version.
This is not really new class. Originally, the validator was implemented
in the scope of the tool_installaddon plugin. But we need its features
in other parts at the core level (e.g. during the upgrade to validate
available missing dependencies or available updates). Looking back, it
was a mistake to have it implemented at the plugin level rather than the
core level.
So this patch moves the tool_installaddon_validator class to
\core\update\validator class, together with associated unit tests,
fixture files and strings. There were changes made in the
tool_installaddon to make use of this new class instead of the old one.
This is a great step towards the bright future, hopefully there won't be
many regressions.
AMOS BEGIN
MOV [validationmsg_componentmatch,tool_installaddon],[validationmsg_componentmatch,core_plugin]
MOV [validationmsg_componentmismatchname,tool_installaddon],[validationmsg_componentmismatchname,core_plugin]
MOV [validationmsg_componentmismatchname_help,tool_installaddon],[validationmsg_componentmismatchname_help,core_plugin]
MOV [validationmsg_componentmismatchname_info,tool_installaddon],[validationmsg_componentmismatchname_info,core_plugin]
MOV [validationmsg_componentmismatchtype,tool_installaddon],[validationmsg_componentmismatchtype,core_plugin]
MOV [validationmsg_componentmismatchtype_info,tool_installaddon],[validationmsg_componentmismatchtype_info,core_plugin]
MOV [validationmsg_filenotexists,tool_installaddon],[validationmsg_filenotexists,core_plugin]
MOV [validationmsg_filesnumber,tool_installaddon],[validationmsg_filesnumber,core_plugin]
MOV [validationmsg_filestatus,tool_installaddon],[validationmsg_filestatus,core_plugin]
MOV [validationmsg_filestatus_info,tool_installaddon],[validationmsg_filestatus_info,core_plugin]
MOV [validationmsg_foundlangfile,tool_installaddon],[validationmsg_foundlangfile,core_plugin]
MOV [validationmsg_maturity,tool_installaddon],[validationmsg_maturity,core_plugin]
MOV [validationmsg_maturity_help,tool_installaddon],[validationmsg_maturity_help,core_plugin]
MOV [validationmsg_missingcomponent,tool_installaddon],[validationmsg_missingcomponent,core_plugin]
MOV [validationmsg_missingcomponent_help,tool_installaddon],[validationmsg_missingcomponent_help,core_plugin]
MOV [validationmsg_missingcomponent_link,tool_installaddon],[validationmsg_missingcomponent_link,core_plugin]
MOV [validationmsg_missingexpectedlangenfile,tool_installaddon],[validationmsg_missingexpectedlangenfile,core_plugin]
MOV [validationmsg_missingexpectedlangenfile_info,tool_installaddon],[validationmsg_missingexpectedlangenfile_info,core_plugin]
MOV [validationmsg_missinglangenfile,tool_installaddon],[validationmsg_missinglangenfile,core_plugin]
MOV [validationmsg_missinglangenfolder,tool_installaddon],[validationmsg_missinglangenfolder,core_plugin]
MOV [validationmsg_missingversion,tool_installaddon],[validationmsg_missingversion,core_plugin]
MOV [validationmsg_missingversionphp,tool_installaddon],[validationmsg_missingversionphp,core_plugin]
MOV [validationmsg_multiplelangenfiles,tool_installaddon],[validationmsg_multiplelangenfiles,core_plugin]
MOV [validationmsg_onedir,tool_installaddon],[validationmsg_onedir,core_plugin]
MOV [validationmsg_onedir_help,tool_installaddon],[validationmsg_onedir_help,core_plugin]
MOV [validationmsg_pathwritable,tool_installaddon],[validationmsg_pathwritable,core_plugin]
MOV [validationmsg_pluginversion,tool_installaddon],[validationmsg_pluginversion,core_plugin]
MOV [validationmsg_release,tool_installaddon],[validationmsg_release,core_plugin]
MOV [validationmsg_requiresmoodle,tool_installaddon],[validationmsg_requiresmoodle,core_plugin]
MOV [validationmsg_rootdir,tool_installaddon],[validationmsg_rootdir,core_plugin]
MOV [validationmsg_rootdir_help,tool_installaddon],[validationmsg_rootdir_help,core_plugin]
MOV [validationmsg_rootdirinvalid,tool_installaddon],[validationmsg_rootdirinvalid,core_plugin]
MOV [validationmsg_rootdirinvalid_help,tool_installaddon],[validationmsg_rootdirinvalid_help,core_plugin]
MOV [validationmsg_targetexists,tool_installaddon],[validationmsg_targetexists,core_plugin]
MOV [validationmsg_targetexists_help,tool_installaddon],[validationmsg_targetexists_help,core_plugin]
MOV [validationmsg_unknowntype,tool_installaddon],[validationmsg_unknowntype,core_plugin]
MOV [validationmsg_versionphpsyntax,tool_installaddon],[validationmsg_versionphpsyntax,core_plugin]
MOV [validationmsglevel_debug,tool_installaddon],[validationmsglevel_debug,core_plugin]
MOV [validationmsglevel_error,tool_installaddon],[validationmsglevel_error,core_plugin]
MOV [validationmsglevel_info,tool_installaddon],[validationmsglevel_info,core_plugin]
MOV [validationmsglevel_warning,tool_installaddon],[validationmsglevel_warning,core_plugin]
AMOS END
The plan is to have a single tool looking after all operations with
plugin ZIP packages (downloading, unzipping, moving to the dirroot and
back). For legacy reasons, we have that logic currently duplicated in
mdeploy and tool_installaddon. I would like to unify and simplify the
whole machinery to use the same code for available updates, manual
installation and plugin dependencies.
The patch improves the dependencies resolution in the plugin manager so
that the information about availability of the missing dependency is
included and can be displayed at the Plugins check screen during the
upgrade.
The purpose of this class is to provide a general client for all APIs
available at https://download.moodle.org/api/ (e.g. available updates,
plugin info, plugins list etc). Currently, fetching data from this API
is done separately at several places. This leads to code duplication and
harder maintenance (I know it well).
Additionally, the existing client was implemented as
tool_installaddon_pluginfo_client in the admin/tool/installaddon/ scope.
I will soon need to use the same functionality in the
core_plugin_manager and it would hurt my karma if the core was depending
on a class provided by a admin tool plugin (even if it is standard one).
So, there is new \core\update\api client implementing the version 1.3 of
the pluginfo API. There is a TODO note left for remaining services.
The actual loading of available updates info objects is moved back to
the plugin manager class. As we can now mockup the manager in unit
tests, this allows us to bypass the real \core\update\checker and have
unit tests for \core\plugininfo\base::available_updates().
We can now override the plugin manager's methods in the testable
subclass while still keeping the singleton behaviour of it. The change
makes use of late static binding.
This patch replaces all homegrown timezone
stuff with standard PHP date/time code.
The main change is the introduction of core_date
class that returns normalised user and server
timezones. From now on nobody should be using
$CFG->timezone or $user->timezone directly!
Other new features and fixes:
* admins are prompted for timezone during install
* editing of other users is finally fixed
* timezones are displayed in user profile
* new $this->setTimezone() in phpunit
* time locale is now automatically reset in phpunit
* timezone is now automatically reset in phpunit
* phpunit has Australia/Perth as default timezone
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.