Skip to:
Content

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#6940 closed defect (bug)

fatal error: bp_blogs_record_existing_blogs

Reported by: shanebp Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Core Keywords:
Cc: shane@…

Description

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.

Attachments (2)

6940.01-multisite-check.patch (650 bytes) - added by r-a-y 2 years ago.
6940.02-single-site-check-user-count.patch (1.2 KB) - added by r-a-y 2 years ago.

Download all attachments as: .zip

Change History (11)

#1 @imath
2 years ago

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

This ticket was mentioned in Slack in #buddypress by dcavins. View the logs.


2 years ago

#3 @shanebp
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

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.

#4 @r-a-y
2 years ago

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?

#5 @shanebp
2 years ago

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.

#6 @r-a-y
2 years ago

  • Keywords has-patch added
  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

Last edited 2 years ago by r-a-y (previous) (diff)

This ticket was mentioned in Slack in #buddypress by r-a-y. View the logs.


2 years ago

#8 @r-a-y
2 years ago

  • Keywords has-patch removed
  • Status changed from reopened to closed

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

#9 @r-a-y
2 years ago

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.

Note: See TracTickets for help on using tickets.