CUNY Academic Commons

Two times in the last three days I've gotten emails from my long-running-request tool that indicate some sort of problem related to the combination of the BPGES asynchronous emailing routine and the Tribe Events Calendar plugin. The queries look like this:

[15] => Array
       (
           [0] => SELECT * FROM wp_1165_posts WHERE ID = 51110 LIMIT 1
           [1] => 0.0021059513092041
           [2] => do_action('wp_ajax_wp_bpges_send_queue'), WP_Hook->do_action, WP_Hook->apply_filters, WP_Async_Request->maybe_handle, BPGES_Async_Request_Send_Queue->handle, BPGES_Async_Request_Send_Queue->handle_immediate_queue, bpges_generate_notification, ass_send_email, bp_send_email, do_action_ref_array, WP_Hook->do_action, WP_Hook->apply_filters, BuddyPress->{closure}, BP_Email->get, apply_filters('bp_email_get_property'), WP_Hook->apply_filters, bp_core_deprecated_email_filters, BP_Email->get, apply_filters('bp_email_get_tokens'), WP_Hook->apply_filters, bp_email_set_default_tokens, get_post_meta, get_metadata, apply_filters('get_post_metadata'), WP_Hook->apply_filters, Tribe__Meta__Chunker->filter_get_metadata, Tribe__Meta__Chunker->applies, Tribe__Meta__Chunker->is_supported_post_type, get_post, WP_Post::get_instance
       )

and there are hundreds of them - by my reckoning, one for each email sent in a batch.

The problem here appears to be that:
a. The BPGES routine is being triggered from a secondary site
b. When BP fetches the email object, it's not switching to the root blog to do it, so WP_Post::get_instance() request is returning null
c. Neither the Tribe tools, nor WordPress, nor the object cache, are smart enough to bail out of querying over and over again

I'm going to investigate to see whether this needs to be fixed in BPGES (ie by ensuring we're switched to the main blog for at least part of each send-batch; though this will be problematic because it could change the "From" address etc) and/or in BP (the API should always be looking for email objects on the root blog).