Signature

apply_filters( 'mam_add_chat_to_detail', array $data_array, array $args );

$args keys:

Returns: array — the modified $data_array. You must return it.

The filter writes these keys onto $data_array:

Purpose

mam_add_chat_to_detail is the integration seam between any plugin that builds a detail-screen payload (a marketplace listing, a WooCommerce product, an order, a service) and the chat manager. Apply this filter to your payload, pass the participants, and the chat manager will write back the full set of mobile-client keys needed to render a working Message button.

The filter is convenience over correctness: it never creates a thread, only resolves a deterministic conversation_id token. The thread itself is created on the first message-send. This means you can apply this filter on every detail-screen request without producing junk thread CPTs for users who never click the Message button.

When it runs

The filter is registered by mam-chat-manager at default priority (10) with mam_chat_manager_endpoints::mam_add_chat_to_detail(). It is applied by integrating plugins from inside their detail-screen builders. There is no global pipeline that fires it automatically — if your plugin builds a detail and wants a Message button, you have to call apply_filters( 'mam_add_chat_to_detail', $data_array, $args ) yourself.

Inside the registered handler, the order of operations is:

1. Resolve post_id from $args['post_id'] or $args['id'], defaulting to 0.
2. Resolve participants — prefer explicit user_ids, fall back to legacy from_id + to_id.
3. Convert WP user IDs to app_user post IDs (creating an app_user CPT if one does not yet exist).
4. Build the conversation token via mam_get_thread_id_for_conversation with create=false.
5. Write has_chat, conversation_id, user_chat_name, chat_with_avatar, and the legacy chatRecipient onto $data_array.
6. Return the modified array.

Example: a one-on-one Message button on a listing detail

$data_array = apply_filters(
    'mam_add_chat_to_detail',
    $data_array,
    [
        'post_id' => $listing_post_id,
        'from_id' => get_current_user_id(),     // current viewer
        'to_id'   => $listing->post_author,     // listing owner
    ]
);

After the filter returns, $data_array carries everything the mobile client needs. The viewer’s app shows a Message button; tapping it opens a thread between the two users, scoped to this listing.

Example: a multi-participant button using a group

$staff_group_id = mam_chat_group_manager::get_or_create_group(
    $listing_post_id,
    'listing_staff'
);
mam_chat_group_manager::add_member( $staff_group_id, $owner_app_user_id );
mam_chat_group_manager::add_member( $staff_group_id, $assistant_app_user_id );

$data_array = apply_filters(
    'mam_add_chat_to_detail',
    $data_array,
    [
        'post_id'   => $listing_post_id,
        'user_ids'  => [ get_current_user_id() ],   // the viewer
        'group_ids' => [ $staff_group_id ],         // the staff side
        'chat_name' => 'Acme Real Estate',
        'to_avatar' => 'https://yoursite/wp-content/uploads/staff-logo.png',
    ]
);

A group on one side and an individual on the other is the most common shape for marketplace-style apps where multiple staff can answer on behalf of a single listing.

Example: with explicit display name and avatar

$data_array = apply_filters(
    'mam_add_chat_to_detail',
    $data_array,
    [
        'post_id'      => $product_id,
        'from_id'      => get_current_user_id(),
        'to_id'        => $vendor_wp_user_id,
        'to_chat_name' => $vendor_business_name,
        'to_avatar'    => $vendor_logo_url,
    ]
);

Useful when the participant’s “chat identity” differs from their WP profile — for instance, a vendor business name vs the WP user’s display name.

Gotchas

• Pass WP user IDs, not app_user IDs. The filter expects WP user IDs and converts internally. Passing app_user post IDs will round-trip them through get_app_user_id() and produce an incorrect conversation token.
• The token is built but the thread is not created. Calling this filter every detail render is cheap and safe. Threads are only persisted when someone sends the first message, when Hook: mam_chat_add_to_chat_thread runs, or when the admin-chat nav button creates one eagerly.
• Order of user_ids doesn’t matter. Conversation tokens sort and dedupe their participant lists, so [1, 2] and [2, 1] produce the same conversation_id. Pass them in whatever order is convenient.
• chat_with_avatar falls back through three sources. Explicit to_avatar → resolved via Hook: mam_chat_manager_get_user_avatar → empty string. If you want the empty-string fallback hidden, the mobile client renders the initials avatar (colored per Recipe: Style chat bubbles and behavior).
• has_chat is set to 'yes' even when the participant resolution failed. If from_id and to_id both resolve to 0, you’ll still get has_chat='yes' and a token built from []. Validate the participants before applying the filter.
• Legacy chatRecipient is kept on the response on purpose. Old mobile builds rely on it. Do not strip it from $data_array after the filter returns.

Verification

This article was last verified against:

• Plugin: mam-chat-manager v2.0.0
• Source: includes/mam_chat_manager_end_points.php (mam_add_chat_to_detail())
• Source: includes/mam_chat_manager_groups.php (group helpers)

Re-verify whenever the keys written by mam_add_chat_to_detail() change, the WP-user → app_user resolution path moves, the mam_get_thread_id_for_conversation chain is replaced, or the legacy from_id/to_id fallback is removed.

Related articles

• Plugin: mam-chat-manager
• Hook: mam_chat_add_to_chat_thread — post a server-generated message into the thread you just resolved
• Hook: mam_chat_set_chat_user_name — override the resolved display name globally
• Hook: mam_chat_manager_get_user_avatar — override the resolved avatar globally

Metadata