fatal error: bp_blogs_record_existing_blogs

[shanebp]

WP 4.4.2, BP 2.5.0, Single Site, No Other Plugins, No bp-custom.php

On activation:

Notice: Trying to get property of non-object in .../wp-content/plugins/buddypress.2.5.0/bp-core/admin/bp-core-admin-functions.php on line 237

WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1]
SELECT COUNT(*) FROM


Fatal error: Call to undefined function bp_blogs_record_existing_blogs() in .../wp-content/plugins/buddypress.2.5.0/bp-core/admin/bp-core-admin-functions.php on line 240

Tested with themes 2013 & 2012 - same error.

[imath]

@shanebp are you sure there's no custom code that is filtering bp_is_active() to force the blogs component to be active ?

I've just tested with the same config : WP 4.4.2, BP 2.5.0, Single Site, No Other Plugins but wasn't able to reproduce.

[shanebp]

Yes I am sure there is no custom code filtering bp_is_active.

I was able to duplicate the error on another site.

If I update BP, there is no error.
If I install from the Plugins > Add New, there is no error.
If I manually upload, that is when the error occurs.

I tried the manual method twice, from scratch, on different sites, just in case there was corruption on the upload.
The error occurred both times.

I suggest closing this ticket and let's see if anyone else reports the same scenario.

[r-a-y]

For the manual method, did you use buddypress as the plugin folder?

From your debug message, perhaps the issue is with the custom naming of the buddypress folder to wp-content/plugins/buddypress.2.5.0?

[shanebp]

Yes, that occurred to me.
I tried removing the '.2.5.0' - same error.
After both updating and installing from the repo, I renamed the folder to add the version number - no errors.

I have several versions of the BP plugin on a test install.
I rename both the folder and the Plugin Name in the loader so as to avoid confusion.
I've been using this method for releases since BP 2.0.
This is the first time I've seen this issue.

Let's call it operator error until and if somebody else reports it.
Sorry to bother you cores; busy day; great release btw.

[r-a-y]

I came across a similar problem today with bp_blogs_record_existing_blogs().

tl;dr - bp_blogs_record_existing_blogs() is not a very well-coded function when used on large sites.

---

The site in question is a single-site install with a rather large userbase.

The problem occurred when the site admin used the "Repopulate blog records" option on the "Tools > BuddyPress" page.

This calls bp_blogs_record_existing_blogs(), which wipes out the wp_bp_user_blogs table and attempts to repopulate the blog records.

On this install, the table is truncated, but the blog records are never repopulated because the get_users() call fails with a WSOD. (This is due to the size of the userbase.)

Now, here is the interesting part. BuddyPress tries to repopulate the blog records if it is empty whenever the admin dashboard is loaded via bp_core_activation_notice() of all places!

So on this site, the admin dashboard always gets a WSOD.

---

The problem here is two-fold:

1. Do not attempt to record existing users to the wp_bp_user_blogs table on a single-site install as it doesn't make much sense to do so.
2. Modify bp_blogs_record_existing_blogs() to check the user count on a single site install and use a check similar to wp_is_large_network( 'users' ). If the install is large, bail.

For other improvements to bp_blogs_record_existing_blogs(), also see #6370.

[r-a-y]

I'm going to close this in favor for #6370.

[r-a-y]

In 10815:

Blogs: Improve how bp_blogs_record_existing_blogs() operates.

When the "Repopulate blogs records" is used from the "Tools > BuddyPress"
page, on large site installs, this option isn't very effective.

This commit improves bp_blogs_record_existing_blogs() by:

• Recording an offset so the blog record repopulation can be resumed on failure.
• Only recording the root blog for the current user if run from single site. (See #6940.)
• Fixing issues with blog count caches.
• Giving each blog a better last activity timestamp by using the last_updated column from the wp_blogs DB table.
• Supporting passing selected blog IDs in case a dev wants to re-record specific blogs.

Fixes #6370.