[Yevhen Chefranov]

Deleting a single reply takes 30–45 s on a large forum (unindexable meta_value lookups)

Summary

On a board with ~573,000 replies, permanently deleting one reply from
wp-admin/edit.php?post_status=trash&post_type=reply takes 42 seconds, and the web server returns a 500 before the request finishes:

[fastcgi:error] FastCGI: comm with server ".../php8.3.0.fcgi" aborted: idle timeout (30 sec),
    referer: .../wp-admin/edit.php?post_status=trash&post_type=reply
[fastcgi:error] FastCGI: incomplete headers (0 bytes) received from server ".../php8.3.0.fcgi"

The delete itself does go through, so the admin is left with an error screen and no way to tell
whether it worked.

Two separate queries are responsible. Both filter wp_postmeta.meta_value, which has
no index in the WordPress schema, so both degrade linearly with the size of the board.

Environment

• bbPress 2.6.20
• WordPress 7.1.3
• PHP 8.3
• MySQL 5.7.39 (InnoDB)
• Content: 47 forums (1 hidden), 1,391 topics, 572,724 published replies
• wp_postmeta: 2,395,731 rows; 574,165 of them _bbp_forum_id, 574,117 _bbp_topic_id
• Object cache: none (database-backed transients only)

How to reproduce

1. Import or generate a board with a few hundred thousand replies.
2. Trash a reply, then delete it permanently from the trash list.
3. Watch the request time, or profile with SAVEQUERIES.

Measured with SAVEQUERIES around a bare wp_delete_post( $reply_id, true )
on the CLI, with no HTTP layer involved: 42.35 s, 183 queries.

Cause 1 — bbp_get_child_counts() scans every row of a meta key

In includes/common/functions.php, bbp_get_child_counts() (since 2.6.0,
r6827) runs:

SELECT p.post_type AS type, p.post_status AS status, COUNT( * ) AS count
FROM wp_posts AS p
  LEFT JOIN wp_postmeta AS pm
    ON p.ID = pm.post_id AND pm.meta_key = '_bbp_forum_id'
WHERE pm.meta_value = '154459'
GROUP BY p.post_status, p.post_type

Because the WHERE clause rejects NULLs, MySQL turns the LEFT JOIN into
an inner join and drives from wp_postmeta. The only usable index is
meta_key, so it walks every row of that key and checks
meta_value row by row:

EXPLAIN (without an extra index)
  table: pm   type: ref   key: meta_key   key_len: 767   ref: const
  rows: 1127050   filtered: 10.00   Extra: Using where; Using temporary; Using filesort

Deleting one reply calls this five times — once for the topic and once for each of the four
ancestor forums — at 3.2–4.9 s each:

_bbp_topic_id:155815    3.88 s
_bbp_forum_id:154457    3.63 s
_bbp_forum_id:154458    4.56 s
_bbp_forum_id:154459    4.86 s
_bbp_forum_id:154460    3.18 s

The cache inside the function does not help: its key contains
wp_cache_get_last_changed( 'bbpress_posts' ), and the delete keeps modifying posts, so
every call after the first invalidation is a fresh query.

Cause 2 — the hidden-forum exclusion adds a CAST() that no index can serve

bbp_forum_query_last_reply_id() builds a deliberately lean WP_Query
(suppress_filters => true, no meta query). But pre_get_posts still runs,
and bbp_pre_get_posts_normalize_forum_visibility() injects
bbp_exclude_forum_ids( 'meta_query' ) because the board has one hidden forum. The
result:

SELECT wp_posts.ID FROM wp_posts
INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
WHERE wp_posts.post_parent IN ( ...32 topic ids... )
  AND ( wp_postmeta.meta_key = '_bbp_forum_id'
        AND CAST( wp_postmeta.meta_value AS SIGNED ) NOT IN ('154499') )
  AND wp_posts.post_type = 'reply' AND wp_posts.post_status = 'publish'
GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC, wp_posts.ID DESC LIMIT 0, 1

The meta query is built with 'type' => 'NUMERIC' and
'compare' => 'NOT IN' (includes/forums/functions.php, around line 2806).
CAST( meta_value AS SIGNED ) makes the predicate non-sargable, so no index on
meta_value can ever be used, and NOT IN on a single hidden forum forces a
full join against the 574k _bbp_forum_id rows. Four of these run per delete,
0.7–2.8 s each.

Note the shape of the exclusion: it asks “is this reply not in the one
hidden forum”, which has to touch every reply, instead of “is this reply in one of the 46
visible forums” or, simpler, instead of filtering by the forum ids the caller already knows.

Workaround we are using

A composite index on wp_postmeta:

ALTER TABLE wp_postmeta ADD INDEX tq_key_value ( meta_key(32), meta_value(32) );

EXPLAIN (with the index)
  table: pm   type: ref   key: tq_key_value   key_len: 262   ref: const,const
  rows: 966   filtered: 100.00

Estimated rows for cause 1 drop from 1,127,050 to 966, the five child-count queries go from ~20 s
to 0.40 s in total, and the whole delete goes from 42.35 s to about
5 s — under the web server timeout, so the 500 is gone.

The index does nothing for cause 2: the CAST() still blocks it. Those queries are
what the remaining ~4.5 s is made of.

Suggested fixes

1. bbp_get_child_counts() should not filter on meta_value.
   The same numbers are available from indexed columns: replies of a topic are
   post_parent = <topic>, and topics of a forum are
   post_parent = <forum>, so a forum’s reply count is one join over
   post_parent (which is indexed) instead of a meta scan. If the meta lookup has
   to stay for sub-forum aggregation, bbPress could create its own index on
   (meta_key, meta_value) at activation, the way it already creates its other schema.
2. Drop the CAST() from bbp_exclude_forum_ids( 'meta_query' ).
   With 'type' => 'NUMERIC' removed — meta ids are stored as plain digit strings
   — the predicate becomes sargable and an index can serve it.
3. Prefer the positive form of the visibility filter.
   meta_value IN (<visible forum ids>) is selective;
   NOT IN (<hidden forum ids>) matches almost every row on the board.
4. Respect suppress_filters, or add an opt-out for the maintenance path.
   The recount queries run on ids bbPress already trusts; putting them through the public visibility
   normalisation is both slow and pointless.

Happy to test a patch against this dataset.

[John James Jacoby]

Hey everyone! bbPress 2.6.20 is out. This is a security and maintenance release, so please update your site when you can. 🙂

This release strengthens password handling, adds a site-wide Open, Closed, or Frozen Forum Status setting, and fixes issues across BuddyPress, moderation forms, subscriptions, notifications, converters, widgets, profiles, and topic and reply administration.

You can read more in the release announcement and upgrade notes. Download bbPress 2.6.20 from WordPress.org, or update right from your WordPress dashboard.

Thanks to everyone who reported issues, contributed patches, reviewed changes, and tested this release!

[John James Jacoby]

Fixed in r7845 for trunk and r7846 for the 2.6 branch.

@chefranov, thank you again for the excellent report, the clear diagnosis, and for being awesome. That makes three thank-yous, all well deserved! 🙌

[John James Jacoby]

Thanks again, @chefranov, for another detailed report and for the clear analysis and suggested fix. You were exactly right.

This is now fixed in trunk in https://bbpress.trac.wordpress.org/changeset/7841 and backported to the 2.6 branch in https://bbpress.trac.wordpress.org/changeset/7842, with regression coverage. The fix is targeted for bbPress 2.6.20 and 2.7.

I really appreciate your continued help finding and documenting these issues.

[John James Jacoby]

Hi @sbask,

I confirmed that this is a regression in bbPress 2.6.19. That release changed the nonce generated for subscription links. The bundled bbPress theme package accepts both formats, but third-party theme packages such as GD Quantum Theme can reject the new format.

I restored compatibility in trunk and the 2.6 maintenance branch, with regression coverage for both formats. The fix is scheduled for bbPress 2.6.20:

https://bbpress.trac.wordpress.org/ticket/3711

Please accept our sincere apologies for the mix-up, and for the extra work and delay this caused you. Thank you for reporting it and for following up.

[John James Jacoby]

Thanks for the detailed report, @chefranov. You were right: bbPress was sending Akismet the formatted post count, which was truncated when the count reached 1,000.

I’ve committed the fix to trunk (r7839) and the 2.6 maintenance branch (r7840), with regression tests for the count boundary and anonymous posts. It will be included in bbPress 2.6.20.

The ticket is https://bbpress.trac.wordpress.org/ticket/3709. Thanks again for catching this!

[Yevhen Chefranov]

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 );

[Yevhen Chefranov]

The Akismet integration reports the wrong post count for any author with 1,000 or more posts. The formatted count (for example '1,309') is cast to int, which gives 1. Akismet then receives an experienced member as someone with a single post.

Environment

• bbPress 2.6.19
• WordPress 7.1.2
• PHP 8.2

Where

BBP_Akismet::check_post() in includes/extend/akismet.php, line 115:

$user_data['total_posts'] = (int) bbp_get_user_post_count( $post_data['post_author'] );

The value is then sent to Akismet as comment_total (line 162).

Cause

Without the second argument ($integer = true), bbp_get_user_post_count() runs through the bbp_get_user_post_count filter. bbp_number_format is hooked to that filter in includes/core/filters.php (line 267), so the function returns a formatted string. Casting that string to int stops at the thousands separator:

(int) '1,309'  // 1
(int) '12,045' // 12

With a locale that uses a space or a non-breaking space as the separator, the result is the same.

Impact

Every new topic or reply from an author with 1,000+ posts is checked by Akismet with a post total of 1–999 instead of the real number. The real number is the part of the user history that most separates a long-standing member from a fresh spam account, so the most active members are the ones most likely to be judged worse than they should be. There is no error or notice; the value is just wrong.

Steps to reproduce

1. Activate Akismet, so bbPress loads its integration.
2. Use an account whose _bbp_reply_count + _bbp_topic_count user meta add up to 1,000 or more.
3. Post a reply and inspect the request sent to Akismet (for example via the bbp_akismet_check_post filter): comment_total is the digits before the first separator, not the real count.

Suggested fix

$user_data['total_posts'] = bbp_get_user_post_count( $post_data['post_author'], true );

The (int) cast is then unnecessary, since the _int filter path already returns an integer.

[Yevhen Chefranov]

Opening a topic for editing in wp-admin (post.php?post=ID&action=edit) fails with a fatal error if the topic has 1,000 or more replies. The “Replies” meta box does not render, and the rest of the edit screen is cut off at that point.

Environment

• bbPress 2.6.19
• WordPress 7.1.2
• PHP 8.2

Error

Uncaught TypeError: number_format(): Argument #1 ($num) must be of type int|float, string given
in wp-includes/functions.php:428

#0 number_format('2,503', 0, ',', ' ')                    wp-includes/functions.php:428
#1 number_format_i18n('2,503')                            wp-admin/includes/class-wp-list-table.php:1051
#2 WP_List_Table->pagination('top')                       bbpress/includes/admin/classes/class-bbp-topic-replies-list-table.php:314
#3 BBP_Topic_Replies_List_Table->display_tablenav('top')  ...:272
#4 BBP_Topic_Replies_List_Table->display()                bbpress/includes/admin/metaboxes.php:641
#5 bbp_topic_replies_metabox(WP_Post, array)

Cause

In BBP_Topic_Replies_List_Table::prepare_items() (includes/admin/classes/class-bbp-topic-replies-list-table.php, around line 237), the total is read without the $integer flag:

$total_items = bbp_get_topic_reply_count( $topic_id );

Without $integer = true, the value passes through the bbp_get_topic_reply_count filter. bbp_number_format is hooked to that filter in includes/core/filters.php, so it returns a formatted string such as '2,503'. That string then goes into set_pagination_args():

• WP_List_Table::pagination() calls number_format_i18n( $total_items ). On PHP 8 this throws a TypeError for a non-numeric string.
• ceil( $total_items / $per_page ) is also wrong. '2,503' / 5 is evaluated as 2 / 5, so total_pages would be 1 even on PHP 7.

Topics with fewer than 1,000 replies are not affected, because their counts have no thousands separator.

Steps to reproduce

1. On PHP 8.x, have a topic with 1,000 or more replies (_bbp_reply_count ≥ 1000).
2. Open that topic in wp-admin → Topics → Edit.
3. The “Replies” meta box shows the fatal error above.

Suggested fix

Request the integer count:

$total_items = bbp_get_topic_reply_count( $topic_id, true );

Workaround (until fixed; restricted to the topic edit screen):

add_action( 'load-post.php', function () {
    if ( ( $GLOBALS['typenow'] ?? '' ) !== bbp_get_topic_post_type() ) {
        return;
    }
    // Runs after bbp_number_format (priority 10) and strips the separator.
    add_filter( 'bbp_get_topic_reply_count', function ( $count ) {
        return (int) preg_replace( '/\D+/', '', (string) $count );
    }, 20 );
} );

[John James Jacoby]

Hey everyone! bbPress 2.6.19 is out. This is a security and maintenance release, so if you’re running bbPress, please update your site when you can. Sooner is better. 🙂

Much of the work in this release makes sure private and password-protected forum content stays where it belongs. We also tightened a few moderation and forum-role checks and fixed issues with BuddyPress, imports, emails, and reply positioning.

You can read more in the release announcement and upgrade notes. Download bbPress 2.6.19 from WordPress.org, or update right from your WordPress dashboard.

Thanks to thewindghost, ngonhuy, and moltenbit for responsibly reporting issues, and to everyone who helped review and test this release!

[Robin W]

I haven’t looked at this one for several years, so no idea if it works or is any good

Inline Image Upload for BBPress

[Danishsard]

I’ll test soon to see if it works—specifically, whether the password changes to the corresponding WordPress hash when someone logs in. Or does it work differently now?

[Robin W]

Have you looked at

bbp style pack

It has loads of features for bbpress.

[Danishsard]

I think bbPress has huge development potential; it is also the most deeply integrated with WordPress. It would be great to see it evolve—perhaps along the lines of other forum solutions that offer comprehensive feature bundles.

It’s a great forum platform, though highly underrated because the core package lacks extensive features. In my view, however, it holds the greatest potential to evolve into a fantastic tool for enriching WordPress sites.

[fabioplugins]

Tanks, feel free to use the free version : https://wordpress.org/plugins/fabio-ai-chatbot-lite/.

[specialworld83]

Introducing Aurora bbPress 1.0!

Aurora is a modern forum template plugin developed by CodeLinSoft to completely redesign the appearance and user experience of bbPress without replacing your existing WordPress theme.

Designed with a clean, elegant, and responsive interface, Aurora makes it easier to discover discussions, interact with other members, and build an engaging online community.

MAIN FEATURES

• Modern, responsive interface for desktop, tablet, and mobile.

• Redesigned homepage with forum categories, community statistics, and active members.

• Dedicated recent discussions page with search, filters, and topic previews.

• Modern topic layouts with author information, discussion statistics, and an interactive timeline.

• SCEditor WYSIWYG editor with XHTML support.

• Integrated image and file attachments.

• Customizable user profiles with avatars and cover images.

• Configurable discussion badges and member rankings.

• Automatic topic subscriptions and notifications with an unread counter and dropdown.

• Customization options available directly from WordPress Admin.

• Multilingual interface with 12 included languages.

COMPATIBILITY

Aurora works as an independent WordPress plugin, preserving the underlying bbPress discussion system and your existing WordPress theme.

Version: 1.0

WordPress: 6.4 or later

PHP: 7.4 or later

Requires: bbPress

License: CodeLinSoft Proprietary License

DISCOVER AURORA

Explore its features, view the interface previews, and get the plugin from the official website:

Aurora bbPress – Official Product Page

Feedback, suggestions, and feature requests are welcome!

Developed by CodeLinSoft.

[Robin W]

@jgasba Thanks for posting, the original thread was old, but exactly the right place for you to add your comments.

So the subscribe/unsubscribe features in profile refer to the user accessing the profile. So if you go into a users bbpress profile, then there is a subscriptions tab, but this is for you (as admin/keymaster in your case) to ‘also’ subscribe/unsubscribe, it does not allow you to subscribe/unsubscribe a user.

You can manage subscriptions using the bbp style pack additional plugin (which has lots of other stuff you can amend in bbpress)

so Install

bbp style pack

once activated go to

dashboard>settings>bbp style pack>Subscription Management
and activate, and follow the explanation there of how to manage subscitions for users, forums and topics

[Robin W]

Thanks for your support ticket in the style pack plugin.

I have done an update which should be live in a few hours – WordPress are now delaying releases so that moderators and security scanners can review changes before they reach users.

If anyone needs a release quicker, you can download from the WordPress site

bbp style pack

[John James Jacoby]

Sorry to hear about all of that.

I’ve fixed the phpBB importer, and I’m quickly auditing the other importers for similar problems.

See: https://bbpress.trac.wordpress.org/ticket/3683

2.6.18 will include these fixes.

[John James Jacoby]

bbPress 2.6.17 is a security and maintenance release that improves permissions, private content handling, subscription notifications, moderation workflows, and forum counts. Everyone running bbPress should update as soon as possible.

Read the release announcement and get bbPress 2.6.17 from WordPress.org.

[Robin W]

Install

bbp style pack

once activated go to

dashboard>settings>bbp style pack>Topic/Reply Display

and items 17, 18 & 19 will let you set what you want

[Peter]

Can you please help with an update to fix this security issue?
https://patchstack.com/database/wordpress/plugin/bbpress/vulnerability/wordpress-bbpress-plugin-2-6-14-broken-access-control-vulnerability

[stracy2]

Is someone working a patch or fix?

Wordfence gives alerts to this issue.

patchstack, credited with finding this CVE:

States “This security issue has a low severity impact and is unlikely to be exploited.” and has no vPatch. Here is that report.

[crzyhrse]

bbPress <= 2.6.14 – Missing Authorization
Wordfence Intelligence > Vulnerability Database > bbPress <= 2.6.14 – Missing Authorization
5.3
Missing Authorization
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
CVE CVE-2026-74010
CVSS 5.3 (Medium)
Publicly Published August 31, 2026
Last Updated September 1, 2026
Researcher Ananda Dhakal
Description
The bbPress plugin for WordPress is vulnerable to unauthorized access in all versions up to, and including, 2.6.14. This is due to a missing capability check on a function. This makes it possible for unauthenticated attackers to perform an unauthorized action.

References
vdp.patchstack.com

[nooreshaal]

Thanks for sharing this fix. While working on Instatroids, we’ve also encountered similar WordPress embed issues caused by plugin conflicts. This solution is simple and helpful.