#5820 closed enhancement (fixed)
Help Super Admin to populate their sites directory
Reported by: | imath | Owned by: | 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)
Change History (7)
#2
@
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
@
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.
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 (afterinit
, 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.