[buddypress-trac] [BuddyPress Trac] #5819: `bp_user_blogs` table improvements (or deletion)

[buddypress-trac]

#5819: `bp_user_blogs` table improvements (or deletion)
-----------------------------+------------------
 Reporter:  johnjamesjacoby  |       Owner:
     Type:  enhancement      |      Status:  new
 Priority:  normal           |   Milestone:  2.2
Component:  Blogs            |     Version:  1.1
 Severity:  normal           |  Resolution:
 Keywords:  2nd-opinion      |
-----------------------------+------------------
Description changed by johnjamesjacoby:

Old description:

> 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_4_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=2 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.

New description:

 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.

--

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5819#comment:2>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac