Skip to:
Content
Pages
Categories
Search
Top
Bottom

bp_core_catch_no_access no-caching member pages


  • Steve Taylor
    Participant

    @gyrus

    1 year, 8 months ago

    Our hosts have reported that all BP pages in the member directory are being set to no-cache, and are taking up a lot of processing power.

    There might be more than one issue here, but to focus on the caching… It seems that if I visit a member profile page, it’s got this response header:

    Cache-Control: no-cache, must-revalidate, max-age=0

    As far as I can tell, this is being set by bp_core_catch_no_access() which is calling bp_do_404(), which is setting the header. However, the browser inspector also says the page is returning a 200 (not 404) response code, and the page looks fine. It’s just that it’s not being cached.

    I’m digging further but I thought I’d check first with these details to see if anyone knows anything about this.

Viewing 1 replies (of 1 total)

  • Steve Taylor
    Participant

    @gyrus

    1 year, 8 months ago

    I’ve had no luck debugging this. It seems the no-cache response header is being set in two places:

    1. /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/)
    2. /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:

    1. /wp-content/plugins/buddypress/bp-core/bp-core-catchuri.php:521
    2. /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.

Viewing 1 replies (of 1 total)
  • You must be logged in to reply to this topic.

Topic Info

Topic Tags

Skip to toolbar