BuddyPress.org

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…[Read more]

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…[Read more]

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.

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…[Read more]

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.

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.

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…[Read more]

@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!

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_Sug…[Read more]

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

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…[Read more]

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

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…[Read more]

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;