bbPress.org

bbp_get_reply_class() passes the boolean true as the topic ID when it asks for the reply position. It only works because bbp_get_topic_id() ignores a non-numeric value and falls back to the topic of the current loop. Outside a topic’s own reply loop, that fallback can be a different topic, and the position is looked up in the wrong one.

Environment

• bbPress 2.6.19
• WordPress 7.1.2
• PHP 8.2

Where

includes/replies/template.php, line 2365:

$reply_pos = bbp_get_reply_position( $reply_id, true );

The signature is bbp_get_reply_position( $reply_id = 0, $topic_id = 0 ). Two lines above, the function already has the correct value:

$topic_id  = bbp_get_reply_topic_id( $reply_id );

What happens

For a reply whose menu_order is still 0 (position never stored), bbp_get_reply_position() calls bbp_get_topic_id( true ). true is not numeric, so bbp_get_topic_id() goes through its fallbacks: the topic loop, the search loop, the current single topic, and so on.

• In a topic’s own reply loop this happens to be the right topic, so the bug is hidden.
• When replies of one topic are listed while another topic is the current one, for example a list of replies rendered on a single topic page, the position is computed with bbp_get_reply_position_raw() against the wrong topic. The reply is not among that topic’s children, so the position is 0. It is not stored, and the same query runs again on the next call.

The visible result is a wrong bbp-reply-position-N class, plus a wasted child-ID query, which on a large topic loads every reply ID of that topic.

Suggested fix

$reply_pos = bbp_get_reply_position( $reply_id, $topic_id );