The Wonderful Relations mother plugin broadcasts a small set of WordPress actions so child plugins (and unrelated extensions) can wire their boot order to the mother’s lifecycle without coupling to its internals.
Actions
wonderful_relations_plugin_loaded
Fires after the WR mother plugin has finished installing and is ready to be used. Child plugins extending AbstractChildPlugin listen to this hook automatically — that is when their Kernel boots modules and the admin menu.
do_action( 'wonderful_relations_plugin_loaded' );Use it from non-AbstractChildPlugin code that still needs WR to be
ready (for example a small companion mu-plugin):
add_action( 'wonderful_relations_plugin_loaded', function () {
// Safe to call Executor / Form / Template APIs from here.
} );wonderful_relations_plugin_deactivated
Fired by the mother when it is being deactivated, and also broadcast
when an update is pending so children put themselves into Safe Mode.
AbstractChildPlugin reacts by calling its own trigger_deactivation
to stop child modules from running against an inconsistent DB.
load_wr_plugins_locales
Fired during locale switching so every WR child plugin can re-register
its textdomain with the new locale. Kernel::load_textdomain() already
hooks into this — you only need to subscribe directly when you load
extra .mo files outside wp-content/plugins/<your-plugin>/languages.
Registration actions
These are the actions Wonderful Relations fires once during boot to let your subsystems self-register:
| Action | Used by | Subscribe via |
|---|---|---|
register_new_action_type | ActionType instances | Constructor of ActionType |
register_new_task | Task instances | Constructor of Task |
wr_register_new_worker | WR_Worker instances | Constructor of WR_Worker |
You do not normally call these directly. Instantiating an ActionType,
Task or WR_Worker once during your Modules\Init is enough — the
constructor hooks into the right action and the central store picks
the instance up.