BuddyBoss @mention notifications via WP-CLI — investigation and fix

The problem

When forum topics or replies are inserted via WP-CLI on practice.baseworks.com (using wp post create + bbPress meta + bbp_update_reply_walker), the @mention HTML renders correctly on the live post but the mentioned users do NOT receive a bb_new_mention notification. This breaks the workflow where Claude Code drafts and posts forum content on behalf of Patrick or Asia.

Manual posting through the BuddyBoss UI works correctly — mention notifications fire. So the issue is specific to programmatic insertion.

Resolution — 2026-05-09

Three root causes were found and fixed during the 2026-05-09 session:

Root cause 1: BuddyBoss Platform feed settings disabled

bp-feed-platform-bbp_reply_create and bp-feed-platform-bbp_topic_create were both set to 0 in the WordPress options table. The filter bp_activity_remove_platform_updates (registered on bp_activity_before_save at priority 999 in bp-activity/bp-activity-filters.php) was clearing $activity_object->type to false for any forum activity type when the corresponding feed option was disabled, causing BP_Activity_Activity::save() to bail. This silently blocked ALL bp_activity_add() calls for forum content.

Fix applied (2026-05-09):

wp option update bp-feed-platform-bbp_reply_create 1
wp option update bp-feed-platform-bbp_topic_create 1

Root cause 2: bbp_insert_reply() does not fire bbp_new_reply

bbp_insert_reply() is a low-level insertion function that does NOT fire do_action('bbp_new_reply', ...). That action is only fired by the form handler bbp_new_reply_handler(). Without this action:

• BBP_BuddyPress_Activity::reply_create() never runs → no activity record
• bbp_notify_topic_subscribers() never runs → no subscription notifications
• bbp_buddypress_add_notification() never runs → no @mention notifications

Fix applied (2026-05-09): The post-to-group skill template was updated to fire this action explicitly after bbp_insert_reply():

do_action( 'bbp_new_reply', $reply_id, $topic_id, $forum_id, array(), $author_id, false, 0 );

Root cause 3: Forum subscriptions vs topic subscriptions

Patrick (user_id=8) and Asia (user_id=2) have forum subscriptions (type=forum) to forum 20019. BuddyBoss forum subscriptions only trigger bb_forums_subscribed_discussion notifications (new topics), NOT bb_forums_subscribed_reply notifications (new replies). Reply notifications require topic subscriptions (type=topic).

Fix applied (2026-05-09): Patrick and Asia were subscribed to the two existing Primer Community topics (22252, 22256) via direct insert into areb_bb_notifications_subscriptions. Future topics require the same when created. See guidelines for the subscription insert pattern.

Remaining open item: @mention notifications for CLI-posted replies

@mention notifications (bb_new_mention) still do not fire when a reply is posted via CLI even after the above fixes. The mention scanner runs inside bbp_buddypress_add_notification() (hooked to bbp_new_reply at priority 9999), which reads buddypress()->forums->mentioned_users. That property is set by bbp_convert_mentions(), a filter on bbp_get_reply_content. When posting via CLI, this filter does not run because WP is not in a theme/request context, so mentioned_users is empty when the notification function fires.

The manual-UI-edit workaround from 2026-04-27 still applies for @mention notifications. Subscription notifications (Patrick, Asia, and topic subscribers) now work correctly via the do_action('bbp_new_reply', ...) fix.

---

Verified state (2026-04-27)

Tested on Session 4 Summary topic (22238) and James Murray plank reply (22240):

• <span class="atwho-inserted"> markup with data-bb-hp-profile attribute correctly stored in DB and rendered as a clickable @-link in the post body. Visual rendering works.
• areb_bp_notifications shows zero bb_new_mention rows for these posts. Notifications do not fire.
• Firing do_action('bbp_new_reply', $reply_id, $topic_id, $forum_id, false, $author_id) after the insert triggers bbPress’s own subscription/topic-author notifications (the bbp_new_reply and bb_forums_subscribed_discussion action rows do appear) but does NOT trigger the activity bridge.
• Calling BBP_BuddyPress_Activity::reply_create() directly on the loaded class instance: no error, but _bbp_activity_id post meta never gets set on the reply, indicating the activity record was not created.
• Calling bp_activity_add() directly with all required args: returns false. Some bp_activity_before_save filter or capability check is rejecting server-side activity creation.
• Patrick manually edited the published post via the BuddyBoss UI (delete a character, re-add it, save). No new bb_new_mention rows fired. Edits don’t re-trigger the mention scan — only fresh activity creation does.

Why this matters

The BB Platform mention pipeline scans activity content at the moment an activity record is created. Forum replies/topics are bridged to activity records via BBP_BuddyPress_Activity::reply_create (hooked at bbp_new_reply priority 10) and topic_create (at bbp_new_topic priority 10). When bp_activity_add silently returns false during these bridges, no activity record exists, so the mention scanner never runs. Once that window has passed for a given post, no later edit revives it.

Investigation leads (to try next)

In rough priority order, cheapest first:

1. Set the current user before firing the action

wp_set_current_user(8);  // Patrick
do_action('bbp_new_reply', $reply_id, $topic_id, $forum_id, false, 8);

Many BB Platform filters check bp_loggedin_user_id() or is_user_logged_in() and bail when no user is set. WP-CLI runs without a logged-in user by default. This is the most likely root cause and the easiest fix.

2. Identify the specific filter blocking bp_activity_add

Hook into bp_activity_before_save and dump return values:

add_filter('bp_activity_before_save', function($activity) {
    error_log('bp_activity_before_save fired, type='.$activity->type.', user_id='.$activity->user_id);
    return $activity;
});

Also enable WP_DEBUG_LOG and check wp-content/debug.log for warnings during the test insert. The blocker may be a third-party plugin (BuddyBoss subscriptions, bbPress modifications, custom mu-plugins). Check /Users/vboy/Documents/baseworks-changelog/sites/practice.baseworks.com/mu-plugins/ and code-snippets/ for relevant filters.

3. Emulate the request context fully

The bbPress form-handler path (bbp_new_reply_handler) builds $_POST, runs nonce + capability checks, and fires bbp_new_reply from inside that context. Replicating this is fragile but might work:

$_POST = array(
    'bbp_topic_id' => $topic_id,
    'bbp_forum_id' => $forum_id,
    'bbp_reply_content' => $content,
    'bbp_reply_to' => 0,
    // nonce, etc.
);
wp_set_current_user($author_id);
bbp_new_reply_handler('bbp-new-reply');

This is the “high-fidelity simulation” approach and is the last resort because it depends on bbPress’s request-handling internals that may change between versions.

4. Manual mention notification insertion

If 1–3 don’t pan out, bypass the activity bridge entirely: scan the inserted post content for @username patterns, look up each user’s ID, and insert bp_notifications rows directly with component_action='bb_new_mention'. Mimic the schema used by the working manual-UI path. This is the most brittle option (skips email side-effects, may miss UI-side notification rendering quirks) but is the most direct workaround if the activity bridge stays blocked.

5. Hybrid: post via WP-CLI, trigger UI-equivalent edit programmatically

A custom mu-plugin endpoint (or WP-CLI command) that loads the post, calls wp_update_post with the same content, and ensures the BB activity bridge runs in that update path. Worth checking whether reply_update (hooked to edit_post) is more amenable to server-side calls than reply_create.

Acceptance criteria

The fix is complete when:

• A wp post create insertion with <span class="atwho-inserted"> markup for one or more @username mentions produces a bb_new_mention row in areb_bp_notifications for each mentioned user.
• The mentioned user sees the notification badge in the BuddyBoss UI on next page load.
• The mentioned user receives the email (if their email preferences allow @mentions).
• Verified end-to-end against at least one test topic and one test reply, in both the Primer Community group and a study-group cohort group.

Documentation to update once fixed

• .claude/skills/draft-response/SKILL.md — replace the “open issue” section with the working method and remove the manual-UI-edit fallback.
• memory/feedback-bbpress-mention-insert-broken.md — mark fully superseded with a pointer to the new method.
• memory/MEMORY.md — index entry updates.
• ~/Documents/baseworks-changelog/CHANGELOG.md — entry describing the fix and any plugin/snippet additions.

Manual-UI-edit fallback (current state)

Until this is solved, the workflow for any forum content that includes @mentions:

1. Post the content via WP-CLI (covers the body, links, atwho-inserted markup, tags).
2. Patrick or Asia opens the post in the BuddyBoss UI and either:
   • For fresh activity: deletes the post and re-creates it through the UI (preserves mention notification firing). Heavy for long-form posts.
   • For lighter touch: edit-and-save is NOT sufficient — confirmed 2026-04-27 that edits don’t re-trigger the mention scanner.

For posts where the mention notification matters (e.g., session summaries with multiple participants tagged), the delete-and-recreate-through-UI path is the only confirmed way until the WP-CLI route is fixed.

Related

• Draft Response skill — Posting forum replies directly
• BB Platform plugin: wp-content/plugins/buddyboss-platform/bp-forums/activity.php (the BBP_BuddyPress_Activity class)
• bbPress core: wp-content/plugins/buddyboss-platform/bp-forums/core/actions.php (action registrations)
• Memory: feedback-bbpress-mention-insert-broken.md