Skip to:
Content

BuddyPress.org

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#5820 closed enhancement (fixed)

Help Super Admin to populate their sites directory

Reported by: imath's profile imath Owned by: boonebgorges's profile boonebgorges
Milestone: 2.1 Priority: normal
Severity: normal Version:
Component: Blogs Keywords: has-patch
Cc:

Description

Since r8592, bp_blogs_record_existing_blogs() is no more used inside bp_core_activation_notice(). I understood the function was too taxing to run during that step.

I've read, it will be relocated elsewhere, but in the meantime, if a user activates the blogs component on a fresh multisite + BuddyPress 2.1 config, then he can be surprised (like i've been) to see that no existing blogs are listed in the Sites Directory.

As there's a repair tool available to fix this, i suggest to add a new notice, if the root blog id is not yet recorded. This way the Super Admin will understand quickier where he can act to record existing blogs.

I think it also has the benefit to show him the repair tool, and if in the future for any reason one of the blogs is not listed, he will remember where he can fix it.

As r8592 has been introduced in 2.1, i think we should think about this way or another one for 2.1.

Attachments (1)

5820.patch (1.6 KB) - added by imath 10 years ago.

Download all attachments as: .zip

Change History (7)

@imath
10 years ago

#1 @DJPaul
10 years ago

I don't think adding yet another admin notification is a good way to fix this. If we don't want to revert r8592 (which I am kind of tempted about doing), then I think we need to move the bp_blogs_record_existing_blogs call somewhere else. We don't appear to have any methods inside the component class that are triggered after the component has been fully set up (after init, I imagine), but that's where I would put it.

https://gist.github.com/paulgibbs/d4d8f8a98e5ec70cedb2 is the logic we need to re-implement; we weren't setting the action before which we need to do.

#2 @boonebgorges
10 years ago

IMO we should revert r8592 so that we have more time to discuss this properly. Aside from the problem that johnjamesjacoby reports in his commit message, I do not recall ever hearing complaints about the overhead of running the blog setup on activation. For 2.1, let's revert, and have a discussion about whether and how to improve for a future version.

#3 @r-a-y
10 years ago

FWIW, I actually don't mind the admin notice apart from one problem. Some BP installs might have blocked the root blog ID from being recorded via the 'bp_blogs_is_blog_recordable' filter. Might be better to check if the user blogs table is empty or not.

DJPaul's solution is good as well. I'd go with either the admin notice or the populating blogs on first install (or if a DB marker exists).

In a future release, I think we need a dedicated upgrader screen. Stuff like the move from 'last_activity' user meta to the BP activity table and the wp_signups table abstraction could have been helpful here.

#4 @DJPaul
10 years ago

I agree with Boone that a revert would be best here.

#5 @boonebgorges
10 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

In 8946:

Reintroduce bp_blogs_record_existing_blogs() to bp_core_activation_notice()

It was originally removed in r8592 because it was taxing to resources, but

Fixes #5820. See #5825

#6 @boonebgorges
10 years ago

Thanks, everyone. I've opened a new ticket #5825 to discuss improving the routine for 2.2.

Note: See TracTickets for help on using tickets.