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

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

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

[Robin W]

Shortcodes

and

dashboard>settings>bbp style pack>shortcodes

[Danishsard]

Forum buttons are misaligned (not in a straight line)

Hi, I’m having an issue while using the BBCode Style Pack: the “Subscribe” and “Favorite” buttons aren’t aligned with each other.

Also, the “New Topic” and “Subscribe” buttons aren’t in a straight line—they are centered instead of being aligned to the left or right.

Is there a way to fix this?

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

[Robin W]

[bsp-display-topic-index show='10' template='short' ]

[Danishsard]

I am using these two shortcodes:

[bbp-forum-index]

[bsp-display-topic-index show=”10″ search=”false” breadcrumb=”false”]

I want the forum to display, followed by a list of the 10 most recent topics, but without the search bar or breadcrumbs. However, even when I use this code, they still appear (search and breadcrumbs). Does anyone know how to fix this?

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

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

Note sure if this issue is covered in this article

phpBB

[Robin W]

I have emailed the developers, but as I am not privy to the exact code at fault, I cannot give any reassurance as to exactly what the issue is.

[Robin W]

You can use shortcodes instead

Shortcodes

There are also additional ones with filters in

bbp style pack

once activated go to

dashboard>settings>bbp style pack>shortcodes

[pentatonicfunk]

FILE: /bbpress/includes/common/formatting.php
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 2 WARNINGS AFFECTING 2 LINES
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 810 | WARNING | seems_utf8() has been deprecated since WordPress version 6.9.0. Use wp_is_valid_utf8() instead. (WordPress.WP.DeprecatedFunctions.seems_utf8Found)
 811 | WARNING | Function utf8_encode() is deprecated since PHP 8.2; Use mb_convert_encoding(), UConverter::transcode() or iconv instead (PHPCompatibility.FunctionUse.RemovedFunctions.utf8_encodeDeprecated)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

[pentatonicfunk]

FILE: /bbpress/includes/admin/tools/repair.php
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 372 | ERROR | The parameter "array( 'hide_empty' => false )" at position #2 of get_terms() has been deprecated since WordPress version 4.5.0. Instead do not pass the parameter. (WordPress.WP.DeprecatedParameters.Get_termsParam2Found)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

FILE: /bbpress/includes/common/functions.php
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 532 | ERROR | The parameter "array( 'hide_empty' => true )" at position #2 of wp_count_terms() has been deprecated since WordPress version 5.6.0. Instead do not pass the parameter.
     |       | (WordPress.WP.DeprecatedParameters.Wp_count_termsParam2Found)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

PHP 8.5
WP 7.0.1
bbpress 2.6.14

[laptoplife]

Thank you so much for your post and the suggestions.

Using the suggestions I have determined that this problem doesn’t occur if I use one of these options. All of the options don’t have to be used, just picking one gets rid of the issue.

1) Don’t use the closed threads option at all.
2) Deactivate the plugin Turnkey bbPress by WeaverTheme
3) Change the theme. The lock shows normally without the code being there.

But this doesn’t really solve it because I want to keep the theme and the plugin.

I assumed that there is an issue with the way the dashicons were being processed.

I added this to functions.php. It did not change anything.

I feel like perhaps there is an issue with the title formatting.

If I go to the post and click on Edit Topic, it doesn’t show any extra code in the title section. Yet I see that this <span> is being inserted into the title of the forum post (as shown above) and I think WordPress may be stripping out the code which is why it shows. I could be wrong in this, but where would I look to see how to change this.

[laptoplife]

If I close a topic, it’s nice that it shows a lock icon in the link, but when one clicks on the thread, it shows the code at the top of the page.

How do I remove this code from the title while still keeping the threads locked?

Thank you.

Wordpress 7.0
BBPress Version 2.6.14

[flamuren]

Hi,

I want to use these widgets when bulding my websites forum page: https://codex.bbpress.org/features/widgets/

I see Buddypress widgets, but bbpress is not showing. However I see them when editing sidebar widgets.

Is it possible to use them on normal pages also somehow?

My goal is to display the latest forum posts.

Best regards,
Flamuren

[Kayako Saeki]

This would require writing separate code; would that be possible?

[jgasba]

Thanks a bunch for taking the time to detail all that.

About translations I am trying to contribute to the official community translations for the plugin in French. I found the culprit strings and added translations for them. https://translate.wordpress.org/projects/wp-plugins/bbp-style-pack/stable/fr/default/?filters%5Bterm%5D=Moderation+Flag&filters%5Bterm_scope%5D=scope_any&filters%5Bstatus%5D=current_or_waiting_or_fuzzy_or_untranslated&filters%5Buser_login%5D=&filter=Apply+Filters&sort%5Bby%5D=priority&sort%5Bhow%5D=desc
Then of course it will only merge when 90+% is translated (and validated), is that correct?

I struggled to find it in the codebase at first because I thought it was in bbpress, my bad. It was then helpful to use the translation website. For further reference it was at the time of writing at modtools/bbpress.php#L215 (in bbp style pack plugin of course)

The most frustrating thing with plugins like bbpress/Buddypress ecosystem is undocumented features/hooks and config parameters and the difficulty it puts on users wanting to work with it or even contribute to understand everything and how each piece comes together with the rest of wordpress in a 15 year old codebase… but thanks to people like you we can go further is making those better 👍

Thanks again for the quick answers

[Robin W]

If you want to hide it completely, then add this to the custom css tab of my style pack plugin

.moderationlinks-flag {
    display: none ;
}	

[Robin W]

Hi,

I am the author of bbp-style-pack.

This part of the code is from a moderation plugin that I rescued from being closed, and i did enough to get it working in my plugin, so I do not have full knowledge of every feature.

Can you tell me exactly where and when you see this text?