* Refactor the block generator base class, to remove the amount
of duplication required in base classes.
* Change the defaults that are filled in to be a little more natural.
* Make the Behat step 'Given the following "block" exist:' work.
AMOS BEGIN
REM [interestslist_help,moodle] Commas are no longer required
REM [entertags,tag] Commas are no longer required
REM [othertags,tag] Commas are no longer required
AMOS END
Added course start date for the course generated by the course
generator in order to prevent incorrect date calculations
(i.e. in assignment due dates) when the generated course is reset.
Only change from 2.9 is the modification of the slasharguments
admin setting string to recommend always to keep the setting enabled
and fix the problem in the server, warning about the drawbacks
of disabling it.
Also, there is a little phpdoc note added to one custom check
to have clearly specified when we can get rid of it.
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 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).
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).
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.
