Skip to:
Content

BuddyPress.org

Opened 4 months ago

Last modified 4 hours ago

#9300 new defect (bug)

`is_home()` returns `true` on BuddyPress pages when checking early hooks

Reported by: r-a-y's profile r-a-y Owned by:
Milestone: 14.5.0 Priority: normal
Severity: normal Version: 12.0.0
Component: Route Parser Keywords: has-patch commit
Cc: emaralive

Description

If a developer is doing checks for is_home() on an early hook like 'pre_get_posts', is_home() will currently return true on any BuddyPress page (except if a BuddyPress component is set as the front page, in this case, is_home() will return false as expected).

BuddyPress pages should always have is_home set to false on these early hooks.

You can use this code snippet to verify the current behavior:

<?php
add_action(
    'pre_get_posts',
    function( $query ) {
        if ( ! $query->is_main_query() ) {
            return;
        }

        // This returns true on all BuddyPress pages at this juncture.
        // Except for when a BP component page is set as the front page, then this returns false.
        var_dump( $query->is_home() );
    }
);

// Runs later in the WP bootstrap.
add_action( 'wp', function() {
    // This returns false on all BuddyPress pages at this juncture.
    var_dump( is_home() );
} );

Here's the technical rundown as to why is_home() is returning true on BuddyPress pages on early hooks such as the 'pre_get_posts' hook:

BuddyPress rewrite pages are not correctly set as is_singular = true at this juncture: https://github.com/WordPress/WordPress/blob/817670fdedda7cab8d01ddbb3e3ca0f0d95db6de/wp-includes/class-wp-query.php#L1035.

This is because BuddyPress pages are not real pages (if we exclude directory pages), so WP's parse query block doesn't take this into account. See https://github.com/WordPress/WordPress/blob/817670fdedda7cab8d01ddbb3e3ca0f0d95db6de/wp-includes/class-wp-query.php#L881-L891 where WP actually sets is_page or is_single. BP rewrite rules do not use the query vars that WP is expecting such as 'pagename' or 'name'. So since is_singular is false when on a BP page, is_home is set to true at: https://github.com/WordPress/WordPress/blob/817670fdedda7cab8d01ddbb3e3ca0f0d95db6de/wp-includes/class-wp-query.php#L1044.

To address this, we can either set the query vars that WP is expecting such as 'pagename' or 'name' to all our BP rewrite rules or we manually set is_home to the correct value of false when on the 'parse_query' hook. I'm doing the latter since it's the easiest path.

Attachments (1)

9300.01.patch (570 bytes) - added by r-a-y 4 months ago.

Download all attachments as: .zip

Change History (7)

@r-a-y
4 months ago

#1 @emaralive
4 months ago

  • Cc emaralive added

#2 @johnjamesjacoby
4 months ago

  • Keywords commit added
  • Milestone changed from Awaiting Review to 14.4.0

Patch looks good to me. Thanks @r-a-y!

#3 @dcavins
4 months ago

@r-a-y Was this the underlying issue with the BP Docs ticket recently?

Thanks!

#4 @r-a-y
4 months ago

No, they are related, but not the underlying issue. The underlying issue with BP Docs was BP Docs's access protection leaking into other WP main queries. That one is a complicated one and both myself and Boone still don't quite understand it thoroughly.

#5 @espellcaste
4 hours ago

  • Milestone changed from 14.4.0 to Up Next

#6 @espellcaste
4 hours ago

  • Milestone changed from Up Next to 14.5.0
Note: See TracTickets for help on using tickets.