[Steve Taylor]

OK I discovered BP Classic.

[Steve Taylor]

Hi, I just woke up to find that one of our major client sites has auto-updated to BuddyPress 12 and this has completely broken groups functionality, which is a major part of the site. How can I quickly roll back to the previous version? It looks like more than just rolling back the plugin itself, it seems to have done loads of things to the data without my consent.

[Steve Taylor]

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.

[Steve Taylor]

Thanks I’ve worked out how to disable that email. I don’t think this solves my initial problem – in theory this email should be active so it’s sent when an admin turns the request down. However, I kind of agree with the view in https://buddypress.org/support/topic/membership-requests-email/ – that usually when an admin turns a request down, it will be because it’s deemed to be spam. And thus the email shouldn’t be sent. So I’m OK with deactivating the email completely I think.

[Steve Taylor]

Actually there’s an issue running the SQL on our live server, which I didn’t get locally. With the first ALTER TABLE statement I get:

‘Index column size too large. The maximum column size is 767 bytes.’

If I then run the next statement I get:

‘Incorrect table definition; there can be only one auto column and it must be defined as a key.’

Not sure if that’s separate, or a ‘cascade’ from the previous one giving an error. Doesn’t ring any bells for me – does it for you, or does it look like something I need to raise with my host?

[Steve Taylor]

Thanks, that does the trick. I’ll let you know if we hit any problems down the line with this, but the table is there now at least.

[Steve Taylor]

Yes, all tables have the prefix wp_, as set in the config file.

On the production site our hosts run a caching system, but I’m working locally on this, no caching. All minification etc. is done using Grunt build scripts – so nothing in plugins or otherwise as the site runs on the server.

The theme is quite a beefy custom theme, but I switched to Twenty Twenty-One, ran the BP tool, deactivated BP, reactivated, ran the BP tool again – no sign of the table.

Is there anything I can do to debug? It seems odd that the BP tool specifically designed to create the tables doesn’t do anything, even though it reports success.

[Steve Taylor]

Sorry, no joy. I deactivated BP, updated from 9.0.0 to 9.1.1, re-activated, and still couldn’t see wp_bp_optouts in the DB. I tried re-running the tool mentioned, still no opt-outs table.

[Steve Taylor]

Thanks, I hadn’t seen this tools page. However, even though running the last repair item reported as successful, I still don’t see the wp_bp_optouts table. And when I go to the ‘Manage Opt-Outs’ tab on the tools page, I get the same ‘table doesn’t exist’ error.

[Steve Taylor]

A note for anyone doing this. Sequential updating is probably best, at the very least if going through version 5.

I updated from 2.9.4 to 6.3.0 and got an error regarding a missing DB table (bp_invitations). This is new in BP 5.

Check bp-core-update.php, which contains functions for special actions updating to major versions. The one for versions higher than 2.9.4 is bp_update_to_5_0(), which creates the new invitations table. This seems to only be run if updating to 5 (not run if updating from < 5 to e.g. 6.

[Steve Taylor]

@shanebp Sure, we’ll be going through the process locally then on a staging space before applying to production.

If there’s no well-known red flags for updating through so many major versions at once, I’ll have a go with the all-at-once update and backtrack if we get stuck.

Thanks for the advice!

[Steve Taylor]

Thanks. It turns out bp_before_get_suggestions_parse_args was the filter I was looking for, applied to the bp_core_get_suggestions() function’s args. Since it’s called from AJAX, you need to parse $_SERVER[ 'HTTP_REFERER' ] to find out where it’s being called from, but then you can pass args through to BP_Members_Suggestions or BP_Groups_Member_Suggestions.

[Steve Taylor]

I was thinking of developer docs rather than guides to the user interface – but thanks anyway.

[Steve Taylor]

As I said, it’s too erratic to replicate easily. At the moment I can’t get it to do anything other than suggest group members, which is what I expected. But before I posted this it was sometimes the list missed group members, sometimes it included all site members. Sometimes it was different in updates compared to comments, sometimes not.

I’m hoping it won’t be something that results in disabling the feature completely being the preferred option (seems to be a common request out there due to members finding the feature confusing).

But for now all I can do is experiment with hacking mentions.js and seeing if I can find anything. I just wondered if any systematic approach to taming it had been found.

[Steve Taylor]

I’ve looked. I was looking for more information, and have searched to no avail. It’s not documented anywhere?

[Steve Taylor]

That’s crazy. Why are there loads of code samples out there, very close variations on what I’ve got, with no mention of this need to stick code into the main activity template? I assume you mean members/single/activity.php – it’s the one being displayed despite me specifying members/single/plugins in the subnav screen function callback. I’ll work with that for now but it seems like a clumsy hack for something that should be basic.

[Steve Taylor]

This hack works, though not sure why it’s necessary. Just inside the loop:

global members_template;
if ( empty( $members_template->member->user_id ) ) :
	$members_template->member->user_id = bp_get_member_user_id();
endif;

[Steve Taylor]

Thanks @henrywright. I’m discovering a few bits that are ‘utility’ styles that I’m copying over (e.g. screen reader text class). It’d be really useful if things like this were in a separate ‘core’ include for people who want to strip back to a minimum. Anyway, I’m ploughing ahead, I’ll keep an eye on the markup.

[Steve Taylor]

Thanks. I was wary because @danbp suggested otherwise: ‘Yes i understand (i’m also using a bootstrap theme), you can do like you want. But don’t claim after that that BP doesn’t work correctly.’ You’re saying that ‘doesn’t work correctly’ means ‘won’t be styled correctly’? There seems to be a confusion between functionality and presentation here.

[Steve Taylor]

Thanks. As far as I can see, the relevant section there that deals with the Members directory is looking at the ordering drop-down. It’s not what I would call a ‘filter’, i.e. filtering results by certain criteria to shown only a sub-section of members. I was thinking that the tabs (where currently there’s only ‘All Members’) would be the more suitable interface element to use. Is there are comparable way of tapping into that?

Or are you saying that there’s no way of tapping into the tabs, and I’ll have to compromise by using the ordering drop-down, i.e. to order by the ‘primary contact’ custom field, showing those with it checked first. The list would still include those who aren’t primary contacts, but they would see those who are grouped together at least. They would then lose the ability to order by something else, so not ideal – but is this the best I can do with BP?