Fix `bp_is_site_home()` to ignore query strings

[indigetal]

The Bug

bp_is_site_home() (introduced in 12.1.0) performs an exact string comparison of the full requested URL against home_url( '/' ):

function bp_is_site_home() {
    $requested_url = bp_get_requested_url();
    $home_url      = home_url( '/' );
    // ...
    return $home_url === $requested_url;
}

bp_get_requested_url() includes the query string from $_SERVER['REQUEST_URI'], but home_url( '/' ) does not. This means any query parameter on the homepage URL causes bp_is_site_home() to return false:

• https://example.com/ → true ✓
• https://example.com/?custom_param=value → false ✗

Impact

This breaks component directory detection when a BuddyPress directory page is set as the WordPress static front page (page_on_front). Every component's parse_query() method relies on this check:

// From BP_Activity_Component::parse_query()
if ( bp_is_site_home() && bp_is_directory_homepage( $this->id ) ) {
    $query->set( $this->rewrite_ids['directory'], 1 );
}

When bp_is_site_home() returns false, the directory flag is never set, so:

1. $bp->current_component is never assigned
2. $wp_query->queried_object is never set to the directory page
3. is_buddypress() returns false — BuddyPress template loading does not kick in
4. The theme falls through to WordPress's default page rendering, which displays empty content or a "page not found" for the BuddyPress directory page

This affects any plugin that adds query parameters to a BuddyPress directory homepage — not just custom parameters. For example, a plugin adding topic filtering (?bp-topic=slug), search refinement, or pagination parameters to the activity directory would trigger this when the activity page is the front page.

When the directory is NOT the front page (e.g., /activity/?param=value), this issue does not occur because WordPress's rewrite rules match the path and set the directory query var directly, bypassing the bp_is_site_home() check entirely.

Steps to Reproduce

1. Set up BuddyPress with the Activity component enabled
2. Go to Settings → Reading → set "Your homepage displays" to "A static page"
3. Set "Homepage" to the Activity directory page
4. Visit https://example.com/ — activity directory loads correctly ✓
5. Visit https://example.com/?anything=value — page not found / empty page ✗

Proposed Fix

Compare URL paths only, ignoring query strings. This matches how WordPress's own redirect_canonical() handles URL comparison (it strips query args before comparing):

function bp_is_site_home() {
    $requested_url = bp_get_requested_url();
    $home_url      = home_url( '/' );

    if ( is_customize_preview() && ! bp_is_email_customizer() ) {
        $requested_url = wp_parse_url( $requested_url, PHP_URL_PATH );
        $home_url      = wp_parse_url( $home_url, PHP_URL_PATH );
    }

    // Compare paths only — query strings should not affect homepage detection.
    $requested_path = wp_parse_url( $requested_url, PHP_URL_PATH );
    $home_path      = wp_parse_url( $home_url, PHP_URL_PATH );

    return trailingslashit( (string) $requested_path ) === trailingslashit( (string) $home_path );
}

Scope

• 2 lines of functional code changed in one function in bp-core-template.php
• Zero behavioral change for URLs without query strings (the trailingslashit path comparison produces the same result as the current exact comparison for bare homepage URLs)
• Fixes directory homepage detection for all components (Activity, Members, Groups, etc.) when query parameters are present
• The is_customize_preview() branch already uses wp_parse_url( ..., PHP_URL_PATH ) — the fix extends this approach to the general case

Workaround

Plugins can work around this by filtering bp_get_requested_url to strip their custom query parameters:

add_filter( 'bp_get_requested_url', function ( $url ) {
    if ( isset( $_GET['custom-param'] ) ) {
        $url = remove_query_arg( 'custom-param', $url );
    }
    return $url;
}, 5 );

This is fragile because every plugin must independently strip its own parameters. The core fix is preferable.

I'm happy to submit a patch for this change.

[indigetal]

Set component to Core. The fix is in bp-core-template.php and applies to any directory used as the static front page.

Many BuddyPress communities set a directory (Activity, Members, Groups, etc.) as the WordPress homepage. That is a supported, common setup. However, once the homepage URL carries *any* query string, such as a filter, pagination, campaign tracking, or a shared link like /?ref=newsletter — bp_is_site_home() can return false and BuddyPress never treats the request as the directory front page. Members see a broken or empty homepage instead of the community feed they expect.

The ticket describes the technical cause, but the actual community impact is much broader: query args are a normal part of the web, not an edge case. Extensions that add directory filtering, search refinements, or deep links should not each ship a bp_get_requested_url workaround to strip their own parameters. That does not scale when several plugins are active, and it is easy to miss a parameter and still break routing.

9330.patch compares URL paths only (the same path-only approach already used in the Customizer preview branch). No change for plain https://example.com/ requests; fixes homepage-as-directory for all components when query args are present.

That fix would help the ecosystem in practical ways:

• Reliable community homepages when site owners use a BuddyPress directory as the front page
• Shared and bookmarked links that include query parameters (filters, topics, tracking) still load the directory
• Extensions can add homepage directory features without fighting core URL detection

Core behavior stays the same for sites that do not use a directory as the homepage. The patch is attached whenever review fits your schedule.

Thanks for considering it.

[emaralive]

@indigetal,

The submitted patch (9330.patch) needs additional work. It appears that you didn't notice that it breaks "BP Email" customization, which is just one layer of "peeling the onion".

[indigetal]

Thanks for the review. I refreshed the patch as 9330.2.patch to address the BP Email Customizer regression from the earlier approach.

The updated patch keeps the existing BP Email Customizer protection intact: requests with bp_customizer=email are not reduced to a path-only site-home comparison. For ordinary site-home detection, it now ignores only query strings and fragments while preserving scheme, host, and path semantics. I also updated the Sites/Blogs front-page check to use the same helper.

Added focused coverage for:

• Activity directory assigned as the homepage with query args.
• Sites directory assigned as the homepage with query args on multisite.
• bp_is_site_home() behavior for plain home URLs, query/fragment noise, BP Email Customizer previews, non-email Customizer previews, host/scheme differences, and subdirectory paths.

Tests run:

• npm run test-php:group -- routing
• npm run test-php:group -- core
• npm run test-php-multisite:group -- routing
• php -l on all touched PHP files

I also ran a narrow PHPCS check against touched files. The generic BuddyPress ruleset reports existing/convention-level noise in legacy source/test files, so I treated that as a limited check rather than a fully clean result.

[indigetal]

Refresh patch preserving BP Email Customizer behavior and adding focused tests

[tusharaddweb]

Testing 9330.2.patch

Test Results

• Patch applies cleanly
• Plain homepage loads Activity directory
• Homepage with query params (?utm_source=newsletter) works
• Multiple query params work correctly
• Unit tests pass (routing, core)
• No regressions with BP Email Customizer

Patch resolves the issue without breaking existing functionality.