1. Current context

When we upgrade Moodle or install or upgrade some plugin, we only have a record of the given upgrade to the Moodle database, on the upgrade_log table.

If we need to update some default setting or proceed with a specific post-process, and we don't own that plugin, we only are able to manually, on the web, go to the corresponding settings page and fix those settings or manually run some cli command.

1. The need

As shared in the Moodle Dev chat, it would be really interesting if, from Moodle core, we can implement some kind of API, from any kind of plugin, or even from Moodle core, to call any existing implementation of the specific API for post-upgrade processes.

1. Rationale

The same way we have the upgrade API, function xmldb_

_upgrade($oldversion), we could have some kind of similar API but for the post-upgrade case. And this implementation could live in any part of the Moodle.

1. Example of use case

Imagine we need to install a third-party plugin (we don't own) in our Moodle instance. The default settings will not work, since we need to adjunt them to our institution infrastructure.

We could have a plugin from our institution implementing this kind of API, so that when we detect that upgrade, from the specific plugin or Moodle core and version, if success, we would proceed with the setup of our settings for that third-party plugin.

The result? After the whole upgrade and post-upgrade, we would have our Moodle instance ready to use in all their parts.

1. Initial proposal

In the lib/upgradelib.php -> function print_ugprade_part_end($plugin, $installation, $verbose) we could have a call like to lib/moodlelib.php -> function component_class_callback($classname, 'post_ugprade', ..., ...); or component_callback($component, 'post_ugprade', ...., ...); for every plugin returned by get_plugin_list_with_function(...); or in a similar way.

As array of parameters to the component*_callback() we should pass the detail we pass to the upgrade_log() within print_upgrade_part_end();.