This function populates default message preferences for all existing providers
when the new message processor is added.
The change also includes update of message_set_default_message_preference to
make possible using it for particular message processor update.
install_populate_default_messaging_prefs() is no longer needed and depricted.
Signed-off-by: Ruslan Kabalin <ruslan.kabalin@luns.net.uk>
This makes the order of plugins returned by get_plugin_types not important as
all messaging defaults population is done at the end.
Signed-off-by: Ruslan Kabalin <ruslan.kabalin@luns.net.uk>
upgrade_core also attempts to populate the preferences, but since during the
first installation it is called before message outputs are set, we need to
force preferences setting at the end.
Signed-off-by: Ruslan Kabalin <ruslan.kabalin@luns.net.uk>
The new messaging default settings can be set in messages.php and deployed
during installation. This also ensures the removing of settings on plugin
uninstallation and contains the update script to populate current default
settings on the existing system when the new feature is introduced.
For security reason we have to avoid using library functions in upgrade
function, so we set defaults the blind way. At this point we do not expect
plugins to have individual messaging defaults presets anyway. The site
defaults are the same as were set for each user using
message_set_default_message_preferences function.
Signed-off-by: Ruslan Kabalin <ruslan.kabalin@luns.net.uk>
The patch introduces a new string to be displayed at admin notifications
page. The maturity level message for upgrade/install reworded as
requested in the tracker.
The patch also adds a new core call to purge all caches at the beginning
of the upgrade. This must be done before the upgrade starts so that the
strings are re-fetched from the updated source and not from the on-disk
cache.
This patch introduces new lib/pluginlib.php library that provides
unified access meta-information about all present plugin types. The
library defines plugin_manager singleton that in turn gathers
information about all present plugins and their status. The list of
plugins can be rendered either as plugins check table or plugins control
panel.
This makes print_plugins_table() function obsolete and because it is not
expected to be called by any contrib plugin, the function is removed.
CSS for the legacy table generated by print_plugins_table() is cleaned
up.
As Eloy Lafuente noticed in the tracker discussion, we display the
information about the current version in the browser window title but
not at the screen itself. The patch fixes that by displaying the
information in the page heading instead of the page title.
Eloy's original idea to put the information into the grey message box
would require a change of [upgradesure,core_admin] string because
unfortunately it does not expect $a as an object but as a plain string.
The commit introduces four new constants that can be used to declare a
maturity level of Moodle core and, in the future, of extension plugins.
If the administrator is about to install or upgrade Moodle to a version
that is not considered as production-ready yet, a warning is displayed
before any change in the database.
Scripts that do not want buffered output just define NO_OUTPUT_BUFFERING before including config.php.
The fileserving code now checks if the headers are already sent which detects misconfigured servers.
