[buddypress-trac] [BuddyPress Trac] #9099: Heartbeat requests need better parsing

[buddypress-trac]

#9099: Heartbeat requests need better parsing
--------------------------+-----------------------------
 Reporter:  needle        |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Core          |    Version:  12.0.0
 Severity:  normal        |   Keywords:
--------------------------+-----------------------------
 I opened [https://github.com/johnbillion/query-monitor/pull/853 this
 ticket on Query Monitor] because I thought it was the source of PHP
 Warnings in my logs... however, it appears that it is BuddyPress that
 causes QM to throw the PHP Warning.

 When `heartbeat` was added to in
 [https://buddypress.trac.wordpress.org/changeset/13526 13526], BuddyPress
 resets the query during ''all'' heartbeat requests in
 [https://github.com/buddypress/buddypress/blob/e07c17d37c1a082a72f5f852d0bff2923436997a/src
 /bp-core/bp-core-catchuri.php#L21 bp_core_set_ajax_uri_globals()]. This
 results in `WP_Query->is_page = true` in `WP_Query->parse_query()` because
 `$qv['pagename']` is whatever the path component of
 `bp_get_referer_path()` is set to, e.g. `wp-admin/plugins.php`.

 This introduces an inconsistency shown by QM because `is_singular()`
 reports `true` yet `get_queried_object_id()` returns no ID. It seems to me
 that there needs to be more granularity in the checks in
 `bp_core_set_ajax_uri_globals` and that looking at
 `bp_ajax_action_is_registered` may not be enough to discern a BuddyPress
 `heartbeat` request from ones in which BuddyPress has no interest.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/9099>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac