`bp_user_blogs` table improvements (or deletion)

[johnjamesjacoby]

I'd like to add a network_id column to the bp_user_blogs table to allow us to query for users of a specific network in a multi-network setup, which there is no way of doing in WordPress core. Right now the schema looks like:

CREATE TABLE `wp_bp_user_blogs` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) NOT NULL,
  `blog_id` bigint(20) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `user_id` (`user_id`),
  KEY `blog_id` (`blog_id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;

...which, by itself, is not really helpful beyond what get_users() is already capable of.

I'm going to add a filter on the minimum blog role used in bp_blogs_add_user_to_blog() today, to add some flexibility to the above functionality while we talk about it.

Let's also start a dialogue about what problems we ultimately want the Blogs component to solve, and whether or not we should instead concentrate efforts on improving WordPress multisite instead.

Right now it's not capable of much beyond listing what blogs a user is greater than a subscriber on, which (on sites with a persistent cache) WordPress is already capable of doing in a more performant way. What else could we do here? How can we go beyond WordPress core? Should we go beyond WordPress core? Is there value in sending ideas and improvements upstream and turn our code into wrapper functions for existing multisite functionalities?

I think there's a lot we can do with this component to either make it more purposeful, or have it absorbed into WordPress multisite/network enhancements, and I'm curious to hear your thoughts and opinions.

[boonebgorges]

bp-blogs also handles activity stream syncing with blog activity. But yes, I take your point about its limited utility.

I don't think that the point about persistent cache is an insignificant one. I'd have to look at the internals and run some benchmarks to be sure, but I'd wager that *without* a persistent cache, the core functions for getting user blog information are very, very slow when compared to BuddyPress's. Perhaps this alone doesn't make it worthwhile for BP to duplicate the information in wp_bp_user_blogs, but it does at least make blog listing feasible for (cacheless) sites where otherwise it simply would not be practical. And while I definitely like the idea of passing ideas upstream to WP where possible, it's unlikely that this problem could be solved in WP without moving all of the data out of wp_usermeta and into a separate table like wp_bp_user_blogs. I'm not holding my breath on that.

Let's definitely talk more about other improvements that could trickle into bp-blogs. Improved group-blog connections (see the bp-groupblog plugin) are one idea.

As for the network_id column: I dislike the idea of duplicating data that is stored elsewhere (in this case in wp_blogs) but I guess we're doing that already anyway. We just need to be sure to have the necessary logic in place to ensure that the value is updated when wp_blogs:site_id is updated, and vice versa. This will entail writing thorough unit tests.

[johnjamesjacoby]

In 8942:

Improvements to Blogs & capabilities:

• Introduce bp_blogs_get_allowed_roles() to act as a blog-role whitelist
• Introduce bp_get_current_blog_roles() to avoid including an admin-only file theme-side
• Use these functions to clean-up the add_user_to_blog process in several ways:

More accurately match the member-to-blog relationship specification
No-subscriber users remains functionality intact
Allow extending of existing user-to-blog behavior

See #5749, #5819.

[DJPaul]

WCSF update: Boone, John, and I discussed this. We need a new function and action in WordPress core that will let us keep this data in sync; once that is in, adding the column is fine.

[DJPaul]

Update: use update_blog_details().

[johnjamesjacoby]

And the refresh_blog_details action.

[r-a-y]

Just revisiting this, if a network_id DB column is added to the bp_user_blogs table, the column should also be added to the bp_user_blogs_blogmeta table as well.

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/