While doing this, I found various bugs in the manages question types admin page, and so fixed them, and updated the code
there to use $OUTPUT and html_writer.
AMOS BEGIN
MOV [cannotdeletemissingqtype,admin],[cannotdeletemissingqtype,question]
MOV [cannotdeleteqtypeinuse,admin],[cannotdeleteqtypeinuse,question]
MOV [cannotdeleteqtypeneeded,admin],[cannotdeleteqtypeneeded,question]
MOV [deleteqtypeareyousure,admin],[deleteqtypeareyousure,question]
MOV [deleteqtypeareyousuremessage,admin],[deleteqtypeareyousuremessage,question]
MOV [deletingqtype,admin],[deletingqtype,question]
MOV [numquestions,admin],[numquestions,question]
MOV [numquestionsandhidden,admin],[numquestionsandhidden,question]
MOV [qtypedeletefiles,admin],[qtypedeletefiles,question]
MOV [uninstallqtype,admin],[uninstallqtype,question]
AMOS END
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>
This introduces the new page where admin may change the permissions and
defaults for particular combination of message processors and providers.
Signed-off-by: Ruslan Kabalin <ruslan.kabalin@luns.net.uk>
Initial checkout of strings into the translator table may take a long time. The
maximum execution time is increased to one hour and a progress bar is
displayed so the user is informed on what is going on.
allowed turning off the http HEAD request timeout calculation with zero (or negative) bitrate
This was added in to allow servers that have a problem with
HEAD requests to carry on with the given timeout without re-calculations.
See PULL-651 for the discussion.
the optional argument to force recalculation of timeout has been forced within scorm/locallib.php
timeout re-calculation only increments timeout.
This fixes issue with uppercase and non-ascii profile fields and closes the iterator properly when field not found. Please note that profile fields with upper case letters must be specified exactly in CSV file headers. includes improved docs and parameter typo fix (credit for the parameter typo discovery goes to Aparup Banerjee)
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.
Frontpage role selection now allows only guest and frontpage roles. Default forntpage role is selected duuring install. Unused nodefaultuserrolelists option was removed completely. Coding style improvements.
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.
This allows profiling to be started earlier in the
setup.php execution, by configuring everything in
the config.php file. That way some interesting code
is also profiled, like DB connections, load of config records...
100% compatible with normal profiling and enabled via
special setting $CFG->earlyprofilingenabled
Example (to be put on config.php):
$CFG->earlyprofilingenabled = true;
$CFG->profilingautofrec = 3;
$CFG->profilingincluded = '/*';
$CFG->profilingallowme = true;
(to enable early profiling for 1/3 of any requests while also
allowing to use the PROFILEME PGC)
