A new communication plugin type added to core to implement
the communication provider features.
Original implemented as MDL-76699
Co-Authored-By: Huong Nguyen <huongnv13@gmail.com>
AMOS BEGIN
CPY [type_contentbank,core_plugin],[type_contenttype,core_plugin]
CPY [type_contentbank_plural,core_plugin],[type_contenttype_plural,core_plugin]
AMOS END
This commit implements the qbank api so that any plugin
can implement its own question bank. This api currently
works parallely with the moodle core classes and the
added qbank in the core, means the moment a plugin
is installed, that object is replaced with the object
from the plugin instead of core, which means the api
has flexibility till the plugins are integrated and the
plugins can be integrated in any order.
All the old classes are still there and not deprecated
as there is a different tracker for the changes to the
quiz and another tracker for class deprecation and
class renaming. Core question units tests are pointing
to the new api structure but the classes are pointing
to the location related to the plugin availability.
Co-Authored-By: Luca Bösch <luca.boesch@bfh.ch>
Co-Authored-By: Guillermo Gomez Arias <guillermogomez@catalyst-au.net>
one more array fix
This commit implements the qbank plugin type which
includes the boilerplate for the qbank plugin, the
qbank plugin management admin page and required core
code addition.
A new plugintype has been created for having more than one installed
third-party H5P libraries. Existing libraries have been moved from
lib/h5p to the new h5plib_v124 plugin.
* Plugins can now explicitly declare supported and incompatible Moodle
versions in version.php
- $plugin->supported[37,39];
supported takes an array of ascending numbers, that correspond to a
range of branch numbers of supported versions, inclusive. Moodle
versions that are outside of this range will produce a message
notifying at install time, but will allow for installation.
- $plugin->incompatible = 36;
incompatible takes a single int corresponding to the first incompatible
branch. Any Moodle versions including and below this will be prevented
from installing the plugin, and a message will be given when
attempting installation.
This commit is part of work on Custom fields API,
to minimize commit history in moodle core the work of a team of developers was split
into several commits with different authors but the authorship of individual
lines of code may be different from the commit author.
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 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.
The plugins check screen (displayed during core upgrade and/or plugins
upgrade) now supports installation of remote plugins. This includes
installation of missing dependencies (both single and bulk mode) and
installation of available updates (both single and bulk mode).
All the HTTP query parameters supported by admin/index.php are now
explicitly enlisted. Previously, the \core\update\deployer used
its own additional parameters (and was source of some serious problems
in the past).
The implementation uses the plugin manager as the controller and
provides an unified interface for installing any remote plugin or
plugins (be it available update or missing dependency).
As a side effect, we now validate available updates which was not
happening before.
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.
Provides a bit more compact layout. Finally cleans up the relevant LESS
files and makes available updates info boxes consistent across all
screens where they are displayed.
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.
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 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 intention here is to make the table a little bit more compact (using
less columns) and to make use of the bootstrap based label elements if
available.
Not directly related to the issue but spotted while developing it and it
is not worth of submitting in a separate issue.
At the Plugins check page, when the "Display the full list of installed
plugins" link was followed, the heading at the next page read something
like "Number of plugins requiring your attention: 357". That is
misleading as this is actually not the number of displayed plugins, not
the number of plugins requiring attention.
The plugins check page displays other plugins that the current one
depends on. Previously, we always displayed the other plugin as a link
to the plugins directory. This did not work well in two scenarios:
* The admin wants/needs to upload the other plugin from the ZIP file
(e.g. it is not available in the plugins directory),
* the other plugin is actually a standard plugin that is not supposed to
be registered with the plugins directory.
This patch displays the Install or Upload or Check for updates links
next to the required plugin instead, as appropriate.
We now call them all as just 'plugins' for consistency. There where we need to
explicitly distinguish the source of the plugin, we say they are 'additional
plugins' on contrary to 'standards plugins' coming with the core.
This commit defines the new /availability root folder, with
/availability/classes, /availability/tests, and
/availability/condition where the condition plugins will live.
Condition plugin prefix is availability_, e.g. availability_date.
Rationale for this organisation:
1. I was originally going to put this in /lib/availability but
it has been pointed out that putting even more junk in lib
is probably bad.
2. 'availability' and 'condition' are the two names used in code
to refer to this system ($CFG->enableavailability).
3. The prefix has to be short enough to allow database tables
(although in practice I assume that condition plugins will not
normally contain database tables).
The new API includes a Boolean tree structure that controls the
availability of an item.
AMOS BEGIN
CPY [availabilityconditions,core_condition],[restrictaccess,core_availability]
CPY [enableavailability,core_condition],[enableavailability,core_availability]
CPY [configenableavailability,core_condition],[enableavailability_desc,core_availability]
AMOS END
1) Moved the calendar types location to a sub-folder in the calendar directory.
2) Removed/moved language strings.
3) Removed calendar types that should be downloaded as plugins.
4) Removed a Non-English language pack for the Gregorian calendar type that
should be downloaded separately.
5) Removed custom files responsible for checking for updates and uninstalling
calendar types, which should be done by core.
6) Removed JS from the calendar_month block as there is no non-JS alternative
provided and the JS written does not make use of the YUI library to ensure
multiple browser support.
7) Removed code from the base class responsible for creating timestamps that
are saved in the DB.
8) Added PHPDocs.
Note: In the original patch we are editing core functions responsible for saving
time in the database in the calendar base class. This is very dangerous, we do
not want to touch these functions as it could cause a complete fubar of the
database. There are places we are forcing the use of the gregorian calendar as
we are passing dates generated by the PHP date function, where as sometimes
we pass dates from usergetdate (which was being overwritten to return the
date specific to the calendar). We can not expect third party modules to
change the calendar type depending on the format they pass to these functions.
Huong Nguyen