I’ve had no luck debugging this. It seems the no-cache response header is being set in two places:
/wp-includes/class-wp.php:760 > nocache_headers()
(this seems to be WP core not recognising the member profile URL path (e.g. /community/directory/john-smith/)
/wp-content/plugins/buddypress/bp-core/bp-core-catchuri.php:613 > bp_do_404() > nocache_headers()
(this seems to be BP baulking at $wp_query->queried_object
not being set)
If either are commented out, the header remains. If both are commented out, the header is no longer there.
So, early in processing, both WP and BP class the request as a 404. Somewhere along the line, clearly, BP recognises it as a member profile request, and includes the right template, and sets the response code as 200 – but doesn’t revert anything else set by the above.
I’ve used my own debugging function to dump the backtrace at the top of the profile-loop.php
template (where, by that point, the status code is 200):
[0] => biro_debug_custom_log
[1] => require('/themes/bureau-qnetwork/buddypress/members/single/profile/profile-loop.php')
[2] => load_template
[3] => bp_locate_template
[4] => bp_get_template_part
[5] => require('/themes/bureau-qnetwork/buddypress/members/single/profile.php')
[6] => load_template
[7] => bp_locate_template
[8] => bp_get_template_part
[9] => require('/themes/bureau-qnetwork/buddypress/members/single/home.php')
[10] => load_template
[11] => bp_locate_template
[12] => bp_get_template_part
[13] => bp_buffer_template_part
[14] => BP_Members_Theme_Compat->single_dummy_content
[15] => WP_Hook->apply_filters
[16] => apply_filters('bp_replace_the_content')
[17] => bp_replace_the_content
[18] => WP_Hook->apply_filters
[19] => apply_filters('the_content')
[20] => the_content
[21] => include('/themes/bureau-qnetwork/buddypress/buddypress.php')
[22] => require_once('wp-includes/template-loader.php')
[23] => require('wp-blog-header.php')
Not sure that helps, so I searched for places where the status code is set to 200. It appears to be being set in two places:
/wp-content/plugins/buddypress/bp-core/bp-core-catchuri.php:521
/wp-content/plugins/buddypress/bp-core/bp-core-theme-compatibility.php:654
Again, if either are commented out, the 200 remains. If both are, the response is 404.
I imagine I could hook custom code in to revert the no-cache header (and anything else) set by 404 calls to nocache_headers()
, if the status has since being changed to 200. But we’re keen to understand this properly rather than simply hack it.