Skip to:
Content

BuddyPress.org

Opened 5 weeks ago

Closed 3 weeks ago

Last modified 3 weeks ago

#9309 closed enhancement (fixed)

Support for WordPress 6.9

Reported by: espellcaste's profile espellcaste Owned by: espellcaste's profile espellcaste
Milestone: 14.5.0 Priority: normal
Severity: normal Version:
Component: Core Keywords: has-patch
Cc: emaralive

Description

Let's test the latest version of BuddyPress (currently 14.0.0) with WordPress 6.9.

There is already a possible conflict here: ​https://wordpress.slack.com/archives/C02RQBYUG/p1764555595435079

Attachments (4)

test-block-styles.zip​ (5.6 KB) - added by espellcaste 5 weeks ago.
This is the plugin with a simple block for testing purposes.
proof-terminal.png​ (188.4 KB) - added by vapvarun 3 weeks ago.
CleanShot 2025-12-29 at 12.44.52@2x.png​ (177.8 KB) - added by espellcaste 3 weeks ago.
CleanShot 2025-12-29 at 12.45.16@2x.png​ (310.9 KB) - added by espellcaste 3 weeks ago.

Download all attachments as: .zip

Change History (27)

#1 @espellcaste
5 weeks ago

  • Milestone changed from Awaiting Review to 14.5.0

#2 @emaralive
5 weeks ago

  • Cc emaralive added

This ticket was mentioned in ​PR #424 on ​buddypress/buddypress by ​renatonascalves.
5 weeks ago #3

  • Keywords has-patch added

Trac ticket: ​https://buddypress.trac.wordpress.org/ticket/9309

#4 @espellcaste
5 weeks ago

In 14145:

seems_utf8 is deprecated in WordPress 6.9, let us use its replacement, wp_is_valid_utf8, instead.

Instances where seems_utf8 was used were updated to use wp_is_valid_utf8 instead,
if available (WordPress 6.9).

Props espellcaste.

Closes ​https://github.com/buddypress/buddypress/pull/424/
See #9309 (trunk)

#5 @espellcaste
5 weeks ago

In 14146:

seems_utf8 is deprecated in WordPress 6.9, let us use its replacement, wp_is_valid_utf8, instead.

Instances where seems_utf8 was used were updated to use wp_is_valid_utf8 instead, if available (WordPress 6.9).

Props espellcaste.

See #9309 (14.0)

#6 @espellcaste
5 weeks ago

  • Type changed from defect (bug) to enhancement

I was trying to replicate the issue reported at ​here by @dd32, but I could not.

Here are the steps I used to try to replicate it:

  1. I set up a BuddyPress (trunk) site with WordPress 6.9.
    1. Using Template Pack: BP Legacy.
  2. PHP 8.3.
  3. Activated the twentyfourteen theme.
  4. I created a test plugin with a block (see zip file in attachments) that enqueues a stylesheet.
  5. Added <?php echo do_blocks( '<!-- wp:test-block-styles/notice /-->' ); ?> in the header.php template of the theme.
  6. Visited a few BuddyPress pages:
    1. ​https://bp.test/members/renato/profile/, ​https://bp.test/activity, and ​https://bp.test/members.

However, I was not able to see the reported issue happening. :(

If I comment ​this line, the hosting is correctly stopped and the asset is loaded in the footer. Otherwise, the block assets is moved to the <head> as per ​https://core.trac.wordpress.org/ticket/64099.

I also can't confirm the following feedback:

Basically, template_redirect at priority 10 is taken over by BuddyPress, anything that operates at priority 11 or higher (Well, 10+ after the BuddyPress handler...), or that is fired within template-loader.php never happens :)

Using a classic theme, I can see the template-loader.php being used. I'm not sure if there is something custom in that setup. Or if there are some hooks or settings that I should use instead for better testing. 🤔

Last edited 5 weeks ago by espellcaste (previous) (diff)

@espellcaste
5 weeks ago

This is the plugin with a simple block for testing purposes.

This ticket was mentioned in ​Slack in #buddypress by espellcaste. ​View the logs.
5 weeks ago

This ticket was mentioned in ​Slack in #buddypress by espellcaste. ​View the logs.
3 weeks ago

#9 @vapvarun
3 weeks ago

Spent some time trying to reproduce the template_redirect issue on WP 6.9 + BP trunk.

Tested with BuddyX, Twenty Twenty-Five (block theme), both Nouveau and Legacy packs. Set up a test plugin that hooks template_redirect at priority 11, template_include, and the new wp_before_include_template action.

All hooks fire fine on BP pages. Block assets load correctly in the head. The exit() in bp_core_load_template() doesn't seem to cause issues because:

  • Most themes use theme compat mode (exit path never hit)
  • Block themes go through locate_block_template() → template-canvas.php
  • Themes with full BP templates call get_header() before exit anyway

Couldn't get it to break. Maybe the original issue was a specific plugin/theme combo?

The seems_utf8 fix looks good - confirmed wp_is_valid_utf8() is being used.

If there are specific repro steps for the template takeover issue, happy to dig deeper.

#10 @espellcaste
3 weeks ago

@vapvarun Just a note that if you are trying to replicate the issue reported above, the theme used should not be a block theme, but a classic one instead.

#11 @vapvarun
3 weeks ago

Found the root cause via ​https://github.com/WordPress/wporg-mu-plugins/issues/715

@dd32 tracked this down on profiles.wordpress.org - block styles were ending up in the footer causing FOUC. The issue is that BP bypasses template-loader.php when loading templates directly, so wp_before_include_template (new in WP 6.9) never fires.

That hook sets up output buffering to hoist footer styles into <head>. Without it, styles enqueued during block rendering just stay in the footer.

Fix:

$template_to_load = apply_filters( 'bp_load_template', $located_template );

do_action( 'wp_before_include_template', $template_to_load );

load_template( $template_to_load );

Tested with:

  • BuddyX + Nouveau on WP 6.9
  • Hook fires correctly on members, activity, groups
  • Block CSS ends up in <head> as expected

Note: wporg sites are using add_filter( 'should_load_separate_core_block_assets', '__return_false' ) as a workaround. This fix should let them drop that.

Last edited 3 weeks ago by vapvarun (previous) (diff)

#12 @vapvarun
3 weeks ago

Pushed the fix to a branch for review:

​https://github.com/vapvarun/BuddyPress/tree/fix/ticket-9309-block-style-hoisting-wp69

Did deeper analysis to confirm this single fix covers all BP pages. Found 64 screen functions across 57 files that all funnel through bp_core_load_template():

bp-members/screens/*.php  ──┐
bp-activity/screens/*.php ──┼──→ bp_core_load_template() ← FIX HERE
bp-groups/screens/*.php   ──┤
... (64 total)            ──┘

The 9 other direct load_template() calls are either within the template context (already inside the buffer) or AJAX handlers returning fragments (no <head> to hoist to).

Also tested with TwentyTwentyFive and TwentyTwentyFour - hook fires correctly. Backward compatible with pre-WP 6.9 (action fires but no callbacks registered).

#13 @espellcaste
3 weeks ago

@vapvarun Could you share any proof that you can replicate the reported issue? Without your fix. Your reply seems more AI generated but without taking into account the context where I mentioned that I can't replicate this issue. :/

Last edited 3 weeks ago by espellcaste (previous) (diff)

#14 @vapvarun
3 weeks ago

@espellcaste Thanks for pushing back on this - you're right that proof matters!

I spent some time digging into the reproduction steps and here's what I found:

Why you couldn't reproduce with TwentyFourteen:
TwentyFourteen doesn't have BP templates, so BP falls back to theme compat mode.

How to actually reproduce:
The issue only shows up with direct template loading. I set this up locally:

  1. Added members/index.php to the theme (triggers direct loading)
  2. Used add_filter('bp_use_theme_compat_with_current_theme', '__return_false')
  3. Used your test block plugin that enqueues CSS during render

Results on master (direct loading):

$ curl ... | grep -n "bp-fouc-test-style\|</head>"
302:</head>
431:<link rel='stylesheet' id='bp-fouc-test-style-css'...

Style ends up on line 431, after </head> at 302 - that's inside <body>, causing FOUC.

With the fix:

314:<link rel='stylesheet' id='bp-fouc-test-style-css'...
315:</head>

Style hoisted to line 314, properly inside <head>.

This matches what dd32 tracked down on profiles.wordpress.org:
​https://github.com/WordPress/wporg-mu-plugins/issues/715#issuecomment-3594242641

(I'm using AI to help clean up my writing, but the testing and debugging was done locally first!)

@vapvarun
3 weeks ago

#15 @espellcaste
3 weeks ago

@vapvarun Sorry, but I still can't replicate this issue. :(

I'd love more info on what you setup looks like. Let me share mine based on your comment here and ​in Slack.

  • WordPress 6.9
  • PHP 8.3
  • Themes: ​BuddyX and ​Astra
  • The theme has a wp-content/themes/buddyx/buddypress/members/members-loop.php
  • Added wp-content/themes/buddyx/buddypress/members/index.php copied from BuddyPress core
  • Template pack: BP Nouveau
  • Added this in the plugin: 
    add_action( 'bp_before_directory_members_content', function() {
    echo do_blocks( '<!-- wp:test-block-styles/notice /-->' );
});
  • mu-plugin with: add_filter( 'bp_use_theme_compat_with_current_theme', '__return_false' );. This one doesn't seem to be doing what I expect. See the screenshots below from the Astra theme and BuddyX (your theme). There is no content being used. From BuddyPress or otherwise.

I'm not 100% familiar with this feature, so it is possible you have something hooked up, that I don't. 🤔 Based on ​the code here, the theme compact is being used but you are disabling it.

However, even including custom theme templates and loading the block in those templates, I still can't the replicate the reported issue.

@espellcaste
3 weeks ago

@espellcaste
3 weeks ago

This ticket was mentioned in ​Slack in #buddypress by espellcaste. ​View the logs.
3 weeks ago

#18 @espellcaste
3 weeks ago

Thanks to @vapvarun I was able to replicate it.

Here is my proposal to fix this: ​https://github.com/buddypress/buddypress/pull/430

#19 @vapvarun
3 weeks ago

Tested the PR 430 locally and it's working for me.

I think your approach is nicer than what I had - hooking wp_start_template_enhancement_output_buffer to the existing bp_core_pre_load_template action makes more sense than adding another do_action() call. Less intrusive.

Thanks for taking a look at this!

#20 @espellcaste
3 weeks ago

In 14188:

Load block styles on demand in classic themes.

WordPress 6.9 introduced the wp_before_include_template hook as part of template-loader.php template to enable output buffering for block style hoisting.

Since BuddyPress bypasses template-loader.php when loading templates, we need to integrate this optimization, by hooking it directly.

Developed in ​https://github.com/buddypress/buddypress/pull/430

Props vapvarun.

See #9309 (14.0)

#21 @espellcaste
3 weeks ago

  • Owner set to espellcaste
  • Resolution set to fixed
  • Status changed from new to closed

In 14189:

Load block styles on demand in classic themes.

WordPress 6.9 introduced the wp_before_include_template hook as part of template-loader.php template to enable output buffering for block style hoisting.

Since BuddyPress bypasses template-loader.php when loading templates, we need to integrate this optimization, by hooking it directly.

Props vapvarun.

Closes ​https://github.com/buddypress/buddypress/pull/430
Fixes #9309 (trunk)

#22 @espellcaste
3 weeks ago

In 14190:

Bump "Tested up to" in the readme.txt to 6.9.

See #9309 (14.0)

#23 @espellcaste
3 weeks ago

In 14191:

Bump "Tested up to" in the readme.txt to 6.9.

Fixes #9310
See #9309 (trunk)

Note: See TracTickets for help on using tickets.