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.
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().
The new method core_plugin_manager::install_remote_plugins() will serve
as a backend for all the ways of installing ZIP packages from the moodle
plugins directory, such as installing new plugins (by clicking the
Install button in the plugins directory), installing available updates
(single and bulk mode) and installing missing dependencies (single and
bulk mode).
The method should be used both for validation pre-check screen and,
after the confirmation, for actual installation. Note that we
intentionally repeat the whole procedure after confirmation. Unzipping
plugins is cheap and fast and the ZIPs themselves are already available
in the \core\update\code_manager's cache.
We will need to add support for archiving existing code to prevent
accidental data-loss.
This basically provides what mdeploy.php was doing, but better. We now
have consistent way of installing all remote ZIP packages, always
validate them and we can perform bulk operations, too.
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 mdeploy.php standalone script (used to download and unzip plugins
into the dirroot) and the \core\update\deployer class (as a
communication bridge between the core and the mdeploy.php) was
originally designed and implemented with the assumption that it would be
eventually used for updating the Moodle core itself, too. Therefore it
was written as standalone utility without dependency on the Moodle core
libraries.
However, it never happened and there is no real demand for that. So now
there is no need to have and maintain a completely parallel solution for
common things like fetching and unzipping plugin ZIPs.
Additional reasoning for mdeploy.php was that the core is not very
reliable during the core upgrade and we could run into various troubles.
This does not seem to be that bad. We rely on a lot of core
functionality (such as output rendering, DB access etc) and plugins
deployment seems to work well (and better) with common core libraries.
So long mdeploy, and thanks for all the hard work you did for us.
If the plugin was missing from disk, the required core version was
displayed as "Moodle {$a}" because the core dependency resolver always
returns an object.
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.
The plugins check screen now provides buttons to cancel installation of
a plugin. Available only for new installations (not upgrades) and for
additional plugins (not standard), given that the web server process has
write access to the plugin folder.
This has also been reported as MDL-48535.
As a part of the patch, there is improved processing of page URLs during
the upgrade. All this dancing around $reload URL is not needed once the
$PAGE->url is properly set to guide the admin on the correct page during
the upgrade process.
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 patch moves the resolving logic from the renderer (where it should
not really be) to the plugin manager (controller). This is needed
because we will need the very same logic to be used at other places.
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().
Plugin info objects are owned by the plugin manager (composition
pattern). Even if the plugin manager is a singleton, we need to keep
explicit reference to the plugin manager that owns the plugin info so
that we can mock up things in unit tests.
Therefore this patch introduces a new property of plugin info objects
that holds the reference to the instance of the plugin manager that made
(and hence owns) the given info instance.
The only trouble here is with static methods of plugin info classes such
as \core\plugininfo\base::get_enabled_plugins(). In these cases, the
code keeps using the core_plugin_manager singleton. The solution would
be to pass the plugin manager instance as a parameter but that is not
worth of change for now, IMHO.
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.
Before this patch, whenever core_plugin_manager::get_plugins() was
called, it always attached info about available updates. But this is
needed only in quite rare cases, such as when the admin is looking at
the Plugins overview and Plugins check screens. There is no need to load
this on other places and for non-admin users.
The patch removes the loading from the method
core_plugin_manager::get_plugins_of_type() and implements lazy loading
directly in the plugininfo classes so that it is loaded only when
\core\plugininfo\base::available_updates() is actually called.
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
This commit introduces support to the LTI module for LTI 2.0.
As well as the initial commit the following changes were made
and then squashed into the single commit for integration:
* Fixed bug in services
Fixed bug which limited characters allowed in values of template
variables (e.g. vendor ID) in service endpoints.
Changed language file to refer to tool registrations rather than
tool proxies.
* Refactored service classes
Moved classes relating to services into areas where Moodle will
autoload them
* Ran code through code checker
Removed all errors reported by the Code checker module
excluding third-party OAuth.php file.
* UI improvements
Mainly when adding an external tool to a course - fields which
should not be changed for a selected tool are either hidden or
disabled. Admin settings page now shows the Tool Registration
name against a tool rather than the launch URL, and the
registration URL replaces the GUID on the tool registrations
page.
* Updated tool proxy registration
Added check of tool proxy to ensure only offered capabilities
and services are included. Also check tool proxy when processing
a service request.
* Code review changes
Some fixes based on code review by Mark Nielsen and addition of
some PHPDocs comments.
* Updates from code/PHPdocs checks
Removed use of eval and corrected invalid PHPdocs for new
functions/classes
* Corrected namespace error and incorrect string terminator
* Updates based on forum feedback
Added dependencies and backup, restore and uninstall methods for
ltiservice subplugins.
Changed most uses of is_null to empty
* Updated custom parameters test
Updated test_split_custom_parameters to include new function
parameters.
Corrected PHPdoc entry for lti_split_custom_parameters
Fixed incorrect line separators in ltiservice.php
* Added require_capability to registrationreturn.php
* SQL and EOL updates
Moved PHP variable in SQL into a named parameter
Improved checks for end-of-line characters to include CR and LF
on their own or together
* Check for semicolon separators
Semicolon separators in custom parameters are changed to EOL
characters when upgrading to the 2014100100 version.
* Remove unused file
basiclti.js file not being used so removed.
* Adjust line lengths
Split long lines in upgrade.php
* Added savepoint to upgrade.php
savepoint omitted from earlier update to upgrade.php
* Updated namespaces and upgrade
Service and resource classes moved into .../local/...
Upgrade SQL moved into a function and unit test created
* Updated lti_tool_proxies table
Added indices and foreign keys to lti_tool_proxies table
* Fixed formatting and documentation issues
* ltiservice class moved into local
* Replaced lti_scale_used comments
Put back commented out code for lti_scale_used
* Removed redundant sesskey code
* Fixed namespace and path check
Updated ltiservice namespace for move into local
Added check for existence of $_SERVER['PATH_INFO']
* Updated upgrade code
Added indices and keys to lti_tool_settings table when upgrading
Fixed errors in upgradelib_test.php (thanks to jleyva)
Update SQL to use Moodle functions
* Use of empty with class method
PHP 5.4 does not like the use of empty with a class method so saved the
value to a variable first. PHP 5.5 seems to accept the use of a method
with empty.
* Removed redundant indices
Removed creation of indices for foreign keys on lti_tool_settings table
from install.xml and upgrade.php
* Fixes based on feedback
Minor changes and corrections based on review in JIRA
* Fixed bug in toolproxy service
Corrected bug which failed to respond properly to an invalid request
Also updated upgrade.txt file
* Improved admin navigation
Added the manage tool registrations page as a separate entry on the
admin menu (within a folder named LTI). Made this entry the current
position for the related pages.
* Updated PHPdocs with class names
Added class names with namespaces to PHPdocs to replace generic
references to "object"
* Changed object to iframe
Use of object tag in register.php changed to use an iframe tag in line
with the similar update made to view.php.
* Improved registration process
A message is now displayed if the registration page has not been loaded
in the iframe within 20 seconds. If a user is returned to Moodle
without a tool proxy being sent, the registration is moved back from
pending to configured.
* Fixes for integration
Removed comment - the template is the default path unless overridden, so
get_path and get_template should both be defined.
Added comment and intval to fix the issue with obtaining an error
reason.
Learnwise was an old LMS that no longer exists. (Last reference found on
Google from 2009.) So we are removing the ability to import questions in
that format.
Credit goes to PJ King. I was trying to add unit tests for this new
behaviour but it turned out there are many hard-coded dependencies and
it's not easy to make the whole machinery support alternative location
of testable (fake) plugins.
