Summary

The notification-type registry is a filter-driven array. Every notification type — bundled or sibling-plugin — registers its definition by hooking mam_notification_list. The dispatcher looks up $message['message_type'] against this registry to:

• Resolve which channels to send through (per-channel opt-in option keys + the type’s default_on)
• Apply the type’s templates (subject, body) with replacement tokens
• Surface the type in Mobile App Manager → Notifications → Settings

Registration shape

add_filter( 'mam_notification_list', function ( array $data ): array {
    $data[] = array(
        'source'          => 'mam-my-plugin',
        'title'           => 'Order Shipped',
        'slug'            => 'mam-my-plugin-order_shipped',
        'replacements'    => array( 'order_id', 'tracking_number', 'user_login' ),
        'default_content' => 'Your order [order_id] has shipped. Track: [tracking_number]',
        'default_on'      => array( 'email', 'push' ),
        'description'     => 'Sent when an order is fulfilled.',
    );
    return $data;
} );

Field reference

Bundled core types

Registered by mam_notifications_list::mam_notification_list():

Per-channel opt-in option keys

For each registered slug <slug>, the dispatcher checks:

• tsl_notification_email_status_<slug> — email enabled?
• tsl_notification_text_status_<slug> — SMS enabled?
• tsl_notification_pn_status_<slug> — push enabled?

⚠️ The dispatcher reads the legacy tsl_* prefix even though Phase 3 documented these as renamed to mam_*. The migration framework’s option aliases handle both names — reading either returns the same value. The code uses the legacy prefix.

If neither the option nor the type’s default_on includes a channel, the dispatcher skips it.

Per-channel template option keys

For each registered slug:

• tsl_notification_subject_<slug> — email subject (and SMS preview)
• tsl_notification_email_text_<slug> — email body
• tsl_notification_pn_text_<slug> — push body
• tsl_notification_text_text_<slug> — SMS body

The admin UI writes these.

Common recipes

Register a type with both email and push enabled by default:

add_filter( 'mam_notification_list', function ( $data ) {
    $data[] = array(
        'source'       => 'mam-my-plugin',
        'title'        => 'New Reservation',
        'slug'         => 'mam-my-plugin-new_reservation',
        'replacements' => array( 'reservation_date', 'reservation_time', 'user_login' ),
        'default_on'   => array( 'email', 'push' ),
        'description'  => 'Sent when a new reservation is created.',
    );
    return $data;
} );

Fire a registered type:

do_action( 'mam_notification_send_message', array(
    'message_type' => 'mam-my-plugin-new_reservation',
    'recipient_id' => $owner_id,
    'replacements' => array(
        'reservation_date' => '2026-05-15',
        'reservation_time' => '7:30 PM',
        'user_login'       => $user->user_login,
    ),
) );

Gotchas

• Slug collisions are silently catastrophic — if two plugins register the same slug, the dispatcher uses whichever wins the filter ordering, and the other plugin’s templates are ignored. Always prefix with your plugin slug.
• Replacements without brackets in the registry; with brackets in templates ([user_login]).
• default_on is a default, not a force-on. Admins can toggle it off in the UI.
• The 4 bundled types can’t be unregistered safely — they’re load-bearing for the bundled login/registration/lost-password flows.
• 68+ subscribers — adding a type means it appears in the admin UI immediately; removing one mid-cycle leaves the per-channel option keys orphaned (but not harmful).

Related articles

• Notifications overview
• Notification channels: email, SMS, push
• Notification template replacements
• Recipe: Register a notification type
• Hook: mam_notification_list
• Hook: mam_notification_send_message

Metadata