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 value Etc/GMT-14 was added to the list of known timezones,
and Etc/GMT+13 & Etc/GMT+14 were removed as they are not valid.
Tests were added to ensure that legacy user timezones are mapped
to known timezones. Other tests were changed to reflect the changes
with regards to Etc/GMT+13 and +-14.
Also the get_property_definition() was created to get the property without retrieve the whole definition cache and
unit tests were created to tests those new methods.
This is required for when helpers include json-encoded variables as arguments.
As an example, imagine a template with content:
{{# str }} somekey, someidentifier, { "fullname": "{{ fullname }}" } {{/ str }}
If the fullname variable were to include the double-quote character (e.g.
John "Trevor" Doe) because of the way in which mustache renders content, it
would become:
{{# str }} somekey, someidentifier, { "fullname": "John "Trevor" Doe" } {{/ str }}
This results in an invalid JSON structure.
To work around this issue, the quote characters in the passed variable
must be escaped:
{{# str }} somekey, someidentifier, { "fullname": "John \"Trevor\" Doe" } {{/ str }}
Unfortunately, Mustache provides no way of doing so natively.
With this function, we can quote the text as appropriate:
{{# str }} somekey, someidentifier, { "fullname": {{# quote }}{{ fullname }}{{/ quote }} } {{/ str }}
This also handles the case where the quoted content includes the Mustache
delimeter ({{ or }}).
For example:
fullname = 'John "}}Trevor{{" Doe'
Ordinarily this would be rendered as:
{{# str }} somekey, someidentifier, { "fullname": "John "}}Trevor{{" Doe" } {{/ str }}
This rendering is both a JSON error, and also a mustache syntax error because of the mustache delimeters.
The quote helper also escapes these by wrapping them in change delimeter
tags:
{{# str }} somekey, someidentifier, { "fullname": "John "{{=<% %>=}}}}<%={{ }}=%>Trevor{{=<% %>=}}{{{{=<% %>=}}" Doe" } {{/ str }}
Due to imperfect validation of the user registration and profile forms,
we allowed for firstname and lastname be just a whitespace. On MySQL,
such a whitespace is not significant for VARCHAR comparison so these
otherwise valid accounts could be silently deleted.
The patch makes sure that at least one of the checked fields is a real
empty string before deleting such account.
The previous 2.9 implementation of is_web_crawler() used stripos() in
certain cases. The unit tests re-added in the previous commit revealed
that certain crawlers (such as BaiDuSpider) were not correctly detected
in the new refactored implementation.
It seems lesser evil and safe enough to use /i in the regex search even
though it is not 100% same logic as before - as stripos() was used in
some cases only, not always.
Norfolk Island's standard time (NFT) was on UTC+11:30 until 4 October
2015, when it was changed to UTC+11:00. So it's not suitable for 11.5
bad mapping replacement anymore.
It seems that there isn't any other location using such 11.5 timezone
so completely getting rid of it for conversions.
This commit covers all events outside of /mod/. It adds mapping info for restoring
events, or the default implementation which returns false if mapping is not required.
This is not really necessary as there is no actual change in the
behaviour of the updates API between 1.2 and 1.3. However, as we plan to
use the new \core\update\api client for this in the future, it makes
only sense to have these two synced already now. In other words, Moodle
3.0 site will use the same version 1.3 for all download.moodle.org/api
end points.
The admin setting updateautodeploy no longer exists. The two existing
config.php flags $CFG->disableupdateautodeploy and
$CFG->disableonclickaddoninstall merged into a single one.
If there is an available archived zip with the version of the plugin
currently installed, we can use it to cancel/abort the upgrade of the
plugin. This is internally handled as the installation of the archived
zip and goes through all the validation and confirmation.
Additionally, some other parts were improved. Most notably, renderer no
longer decides itself if some installation can be cancelled but it
always asks the controller (plugin manager).
The button for installation was moved to the left so there should be
first buttons to add things, and then buttons to cancel things (which is
common in normal forms).
The method move_plugin_directory() was a relict from previous 2.9
implementation within tool_installadon_installer and was originally
supposed to be used to move whole plugin folders. The archiving feature
has been finally implemented via using zip files (so that we do not have
actual PHP code present in the dataroot) and we do not need this method.
This should allow the admin to revert the upgrade of existing plugins,
such when the dependency chain leads to a dead-end. Additionally, we
archive (as a last-chance copy) the to-be-installed plugins when
cancelling their installation. This is mainly for developers who could
otherwise loose their code. For the same reason, plugins are being
archived upon uninstallation, too.
Do not attempt to read an unreadable directory because previously the generated
errors were hard to fathom.
Thanks to James McQuillan for the basis of the patch.
David Monllao