Module Settings and Data Hooks
The nine hooks over module settings, the API record, tool data and imports.
Overview
Module settings are saved from four separate places: the module’s own settings, add-on settings, the settings on a page the module opened, and fraud check settings. Each raises its own event.
Beside them sit three filters over data: tool data, the import archive and the transferable types. And one record fires after every outside call.
Reference
Following module settings being saved
Runs after the settings of a module are saved.
Hook::add('action:module.config_saved', 10, function ($type, $key) {
Acme::invalidateModuleCache($type, $key);
});Following add-on settings being saved
Runs after the settings of an add-on are saved.
Hook::add('action:module.addon_settings_saved', 10, function ($name, $config) {
// Do not carry the configuration itself.
Acme::notifyOps('add-on settings changed: ' . $name);
});Following module area settings being saved
Runs after settings on the module’s own management page are saved.
Hook::add('action:module.area_settings_saved', 10,
function ($module_type, $module_name, $values) {
// The array holds what was SENT, not the whole settings.
Acme::auditChange($module_name, array_keys($values));
});Following fraud module settings
Runs after the settings of a fraud check module are saved.
Hook::add('action:module.fraud_settings_saved', 10, function ($name, $config) {
Acme::notifyOps('fraud check settings changed: ' . $name);
});Following a module API record
Runs after a module talks to an outside service. It fires for every call, so this is a busy path.
Hook::add('action:module.api_logged', 10, function ($type, $module, $action, $log_data) {
// Do NOT copy the whole record: it carries secrets.
Acme::metric($type . '.' . $module . '.' . $action);
});Changing tool data
Runs after a server tool returns its data and before it reaches the screen: mailboxes, databases and their siblings.
Hook::add('filter:module.tool_data', 10, function ($tool, $action, &$data) {
// The hook fires for every tool.
if ($tool !== 'databases') return;
$data = Acme::hideSystemDatabases($data);
});Stopping an import
Runs before a transfer from another system begins. One of the modes wipes the existing data, which makes a check here worth the most.
clean wipes what is there, enrich adds to it.Hook::add('gate:module.import_run', 10, function ($platform, $type, $import_type) {
// 'clean' WIPES what is there: close it on live data.
if ($import_type === 'clean' && Acme::hasLiveData($type))
return 'A wiping import cannot run over live data.';
return null;
});Changing which archive is opened
Runs before an uploaded module archive is opened. Change the path and a different file is opened.
Hook::add('filter:module.import_archive', 10, function (&$theFile, $group) {
// Changing the path opens ANOTHER file: hand over one you built.
$theFile = Acme::repackage($theFile, $group);
});Changing which data types can transfer
Runs while the import wizard asks which data types it should offer.
Hook::add('filter:module.import_data_types', 10, function (&$data_types, $platform) {
// Dropping a required type starts the transfer short.
$data_types['acme-notes'] = [
'name' => 'Acme notes',
'description' => 'Notes attached to customer records',
'required' => false,
];
});Pitfalls
The record holds the request sent to the outside service and the response as they were: server passwords, API keys, customer data. Copying that array into your own store spreads those secrets to a second place. Pick the field you need; do not carry the whole thing.
One import mode deletes the data already there. The import gate is the only place you can keep that mode away from live data.
Related Articles
- Module Hooks
- System Event Hooks
- How Hooks Work
Thanks for your feedback!
Our support team is here around the clock for anything you can't find above.