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.
We were previously using an ancient version of html2text from RoundCube
with many customisations.
This patchset moves to the version included in the latest version of
HTML2Text, and wraps the library in a moodle-provided class. This
moves all previous hacks away from that class.
Unfortunately, two hacks still remain - two of the functions in the
RoundCube class are private, and must be modified to protected in order to
use the class effectively.
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.
This was a regression of my recent improvement of rendering the "Check
for updates" button. There is now unified parameter ?fetchupdates=1 that
can be used on either admin/index.php or admin/plugins.php, so that we
can use a common UI widget for both locations (without the need to pass
the URL explicitly).
The admin setting updateautodeploy no longer exists. The two existing
config.php flags $CFG->disableupdateautodeploy and
$CFG->disableonclickaddoninstall merged into a single one.
General backup/restore does not need to handle external data sources natively - so
any changes needed to achieve this should be contained to the plugin that needs it.
Using standard subplugin support, this commits implements
the restore of logstore subplugins in general and the
standard logstore is particular. Notes:
- TODO: Decide about these 2 pending issues:
1) Some logs are already created (events fired) by the restore process itself. Every time
an API is used and it fires events... corresponding (and actual!)
logs are created. We need to prevent restore to duplicate them (or,
alternatively, stop firing events when restore is happening).
2) There are 2 pieces of information in the logs that, right now, can
not be restored, because the process does not know enough to be able
to remap that information to its new counterparts. We are talking
about objectid and other columns. So we need to specify, in some way
understandable by restore, to which existing mappings they correspond
to.
Using standard subplugin support, this commit implements
the backup of logstore subplugins in general and the
standard logstore in particular. Notes:
- Uses a custom final element (base64_encode_final_element) to
support the storage of serialized 'other' information in logs.
- Organization: Instead of directly extending backup_subplugin,
every logstore extends backup_tool_log_logstore_subplugin just
in case any shared code is needed in the future.
- Implements both course and activity logs, sharing the structure
completely (both are based in contextid to pick the target
information, from database or whatever other logstores use).
In order to implement the backup and restore of log stores, that
are created as subplugins of the tool_log plugin , we need to
extend subplugins support from activities to virtually any plugin.
Basically that implies moving the add_subplugin_structure() method from
its current, restricted, activity level to general restore_structure_step.
This commit implements the change in restore, covered with tests verifying
old, bc behavior and also new, general one.
In order to implement the backup and restore of log stores, that
are created as subplugins of the tool_log plugin , we need to
extend subplugins support from activities to virtually any plugin.
Basically that implies moving the add_subplugin_structure() method from
its current, restricted, activity level to general backup_structure_step.
This commit implements the change in backup, covered with tests verifying
old, bc behavior and also new, general 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.
$plugin was not being set before the version file was included.
This caused an E_WARNING: Creating default object from empty value
This change creates the plugin object before the version file sets its parameters.
Most of the functionality provided by this tool (typically the
validation and actual deployment of the plugin package) has been moved
to the core level. So this is becoming just a thin wrapper and user
interface for installing new plugins via the administration UI.
Also fixes MDL-49600 as we no longer keep the unzipped contents of the
packages in the persistent temp directories.
The plugin manager's method install_remote_plugins() has been changed to
install_plugins() and it is now able to install plugins from the
provided list of locally available ZIP files, too. This is used by the
Install plugins admin tool.
During the testing, I was experiencing weird behaviour - after a single
plugin updated was installed, I ended up on admin/index.php?cache=1. I
believe it was caused by the missing opcache_reset().
