The patch fixes missing space around elements and some other minor
visual issues detected. This was a good opportunity to get rid of custom
CSS rules and use the native bootstrap classes and utilities.
The patch makes the available update information elements more
distinguishable, the Download button more prominent, and the Check for
available update button better aligned. It reduces the space between
multiple available Moodle updates, too.
Passing parameters to implode() in reverse order is deprecated, use
implode($glue, $parts) instead of implode($parts, $glue).
This commit corresponds to phpunit and manual detections, core files.
* 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 is an update of the site registration admin page and some relevant
backend code to remove the mentions of moodle.net.
AMOS BEGIN
CPY [registerwithmoodleorg,core_admin],[registerwithmoodleorg,core_hub]
AMOS END
The minimum required Moodle version specified in the plugin's
version.php file is not a mandatory field. If it is not declared, do not
display "Moodle {$a}".
There is an existing warning if cron doesn't run at all (hasn't run
for 24 hours). This commit adds a warning if cron hasn't run for 3
minutes, based on the recommendation that cron should run every
minute.
We can't really control the direct web access to directories in dirroot,
that is part of the server setup. So we at least warn admins as they may
not realize the risks of having directories like vendor or node_modules
exposed.
Credit goes to Petr Škoda for mentioning the PHPUnit issue CVE-2017-9841
to me.
* Use Bootstrap label classes for the text under the status column.
* theme_bootstrapbase:
- Cleanup unnecessary classes and make .error styles consistent
with .warn styles
* theme_boost:
- Set font color appropriate for success, warning and error strings.
* Enclose report text in div so that the feedback texts will be
displayed right below it.
This is:
a) To help avoid devs going on a wild goose chase to find a perf issue
when it's caused by css building
b) To make it clearer that this should never be enabled on production
sites (we already have a warning in the performance report, but who
looks at that)
Now that boost is the default theme and builds css itself, it's more
critical.
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).
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 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.
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 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.
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.
