[John James Jacoby]

Thanks for the detailed report!

Both expensive query paths were fixed in bbPress 2.6.21.

Please update and hopefully reply deletion performs better now.

[John James Jacoby]

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

This release strengthens access control for private and password-protected forum content and includes fixes across feeds, search, BuddyPress, old-slug redirects, attachments, topic moves, forum freshness, route handling, moderation, and reply administration. It also adds ugc link relationships and refreshed administration icons.

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

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

[vgpmedia]

Is it expected behaviour that BBPress 2.6.20 would copy the forum content into the page excerpt? When I upgraded to 2.6.20 on my site, I now get two copies of the forum content, one at the top of the page in the excerpt, then the usual forum below. This happens when browsing the forums and even when making posts/replies.

Rolling back and things are displayed correctly. Is this expected behaviour or a bug, if it’s expected, how do I disable it?

site is https://videogameperfection.com/forums/ (now rolled back to 2.6.19). WP version 7.1.3. Theme is Flatsome – https://docs.uxthemes.com/

[sbask]

I’m not sure I know what that is? https://www.askwoody.com/
I use https://www.dev4press.com/bbpress-club/ with Quantum theme

[tinwho]

The breaking of preformatted text in tinyMCE visual editor when enabled in bbPress appears to be not a coding bug and more about a focus GUI pathway issue. We can take a defensive approach and patch the GUI pathway to offer a more robust option.

Rather than using TinyMCE’s normal paste and formatting behaviour inside a block, we:
– Isolates pasting in a plain-text textarea.
– Preserves whitespace and line breaks when reinserting the content.
– Escapes HTML characters to prevent pasted code from being interpreted as markup.
– Restricts formatting commands while editing inside a preformatted block.
– Allows through bbPress’s server-side filtering.

This also raises the question of whether the issue is actually a bug in bbPress or TinyMCE itself. The behaviour may arise from the way focus, clipboard events and GUI interactions are handled when working inside a preformatted block, rather than from a discrete coding defect.

There is a proof of concept addressing preformatted-text preservation issues in bbPress’s TinyMCE editor. It introduces a dedicated plain-text paste workflow and protective formatting controls to help preserve whitespace, line breaks and literal code content, while allowing preformatted blocks to survive server-side filtering.

You can find a code snippet release under GPL and ask an AI like ChatGPT to explain why this is a workaround.

https://github.com/TinWho/Gator-Gate-Pre/blob/main/Gator-Gate-Pre.php

[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.

[DigitalGdn]

Cause: bbPress::register_meta() registers the count meta (_bbp_topic_count, _bbp_reply_count, etc.) with register_meta( 'post', ... ) with no object_subtype. That attaches it to every post type. It also uses show_in_rest => true and `auth_callback => __return_false’.

That means every post’s REST response includes these keys. When anything in the editor changes meta (ACF’s _acf_changed, footnotes, and so on), the editor sends the whole meta object back. A normal post has no stored value for these keys, so core skips its “value unchanged” shortcut and runs the permission check.__return_false then refuses and the save fails with a 403.

Suggested fix: register the meta per bbPress post type with object_subtype (forum/topic/reply). Alternatively, don’t expose read-only meta in REST.

Workaround:

add_action( 'init', 'custom_scope_bbp_post_meta', 20 );
function custom_scope_bbp_post_meta() {
	if ( ! function_exists( 'bbp_get_forum_post_type' ) ) {
		return;
	}

	$post_types = array( bbp_get_forum_post_type(), bbp_get_topic_post_type(), bbp_get_reply_post_type() );

	foreach ( get_registered_meta_keys( 'post' ) as $meta_key => $args ) {
		if ( 0 !== strpos( $meta_key, '_bbp_' ) ) {
			continue;
		}

		unregister_meta_key( 'post', $meta_key );

		foreach ( $post_types as $post_type ) {
			register_post_meta( $post_type, $meta_key, $args );
		}
	}
}

[DigitalGdn]

Today a client reported being unable to save a regular post and was getting the error:

“Updating failed. Sorry, you are not allowed to edit the _bbp_topic_count custom field.”

We were on a recent release but not the latest. I updated to 2.6.20 and still saw the error myself when saving a draft post (unrelated to the forum on the site).

The issue seemed to disappear after a while and the post then saved. My concern is that saving a post should have no overlap with bbPress custom fields such as this.

When I start a new post and save draft, I get the same error.

WP 7.1.3.

[John James Jacoby]

Thanks @adampembs. I tested bbPress 2.6.14 and 2.6.20 with PHP 8.1 and PHP 8.3.

I reproduced the PHP 8.3 deprecation notices in 2.6.14, but not in 2.6.20. The 2.6.20 imports completed normally, including users and author relationships.

Please try bbPress 2.6.20 on PHP 8.3 and let me know if it still hangs. If it does, please include your phpBB version and the exact log message.

[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!

[adampembs]

bbpress 2.6.14 and I rolled php back from 8.3 to 8.1 (not 7 as I said above)
The debug log showed a PHP 8.3 dynamic-property deprecation issue in the bbPress importer.

[John James Jacoby]

@adampembs Which versions of bbPress and phpBB?

[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.

[Yevhen Chefranov]

Thank you! Check this https://bbpress.org/forums/topic/fatal-error-on-topic-edit-screen-when-a-topic-has-1000-replies/ please. I also faced with this on dashboard.

[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!

[Danishsard]

The bbPress forum looks bad on mobile phones; elements are misaligned, and the layout uses four columns, making everything feel cramped. The mobile view is odd—instead of information appearing on separate lines below the topic title, it is displayed in side columns, which causes the poor appearance.

The photos illustrate the difference between standard bbPress and bbPress with a style pack.

The issue lies in the bbPress architecture itself; it works well on PCs but is not suited for phones and mobile devices.

It looks exactly the same here on the bbPress support forum.

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

[Danishsard]

The pagination here on bbPress differs from the default installation, which looks very small and boxy. How can I manually customize its appearance? The “bbS Style Pack” plugin doesn’t seem to have settings for it (though it might have in the past).

Also, how can I make the subject input box more visible? In some themes, the border lines are barely noticeable, and the input field itself is almost invisible.

[sbask]

https://www.askwoody.com/forums/topic/unable-to-subscribe-to-any-askwoody-thread/

Subscribe to new topics button after the install of bbpress 2.6.19 is not working.
This may be a skin issue interaction with Dev4press’s bbpress theme?

[Robin W]

Shortcodes

and

dashboard>settings>bbp style pack>shortcodes

[Danishsard]

Is there a list of these commands somewhere? The bbPress shortcode page is incomplete, and it’s impossible to figure them out on one’s own.

Is it possible to configure the code to display the 10 most recent posts while also including pagination for the rest—essentially paginating the entire list of topics in sets of 10?

I currently have my forum sections set to display 25 items per list.