[buddypress-trac] [BuddyPress Trac] #6026: Single items for the Blogs component.

[buddypress-trac]

#6026: Single items for the Blogs component.
------------------------------------+-----------------------
 Reporter:  imath                   |       Owner:  imath
     Type:  enhancement             |      Status:  assigned
 Priority:  normal                  |   Milestone:  2.7
Component:  Blogs                   |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |
------------------------------------+-----------------------

Comment (by imath):

 Hi @boonebgorges thanks a lot for your very interesting feedback.

 1/ `BP_Site_Query`
 The story of this class (which extends the very interesting WP_Site_Query)
 is actually very linked to the Site (Blogs single items) feature. After
 taking the time to analyse my previous patches, i thought i wasn't doing
 thing rights. Because i was using BP_Blogs_Blog::populate() to get a
 single site. But the real goal of this method is to get the blogs/user
 association. So i needed another tool to build my single site. After
 looking at BP_Blogs_Blog::get() i thought we could improve it and at the
 same time, was afraid to touch it too much :) Then i've found
 WP_Site_Query. So i've first started to try to use it instead of
 BP_Blogs_Blog::get() to to the same job. Once it was done, i was able to
 use it to easily get a single site out of a slug
 (site.url/sites/`bp_current_action()`)
 Since then i'm improving it at each steps of the patch i'm uploading (the
 *.smaller-steps.* ones).
 There is already some existing tests of BP_Blogs_Blog::get() in
 `tests/testcases/blogs/class-bp-blogs-blog.php`. So i've simply edited
 them so that if the function `get_sites()` introduced in 4.6 exists we're
 still testing the "legacy BP_Blogs_Blog::get()". I wanted to make sure
 everything was working the same using both ways. And it's the case.
 So i'm feeling pretty confident about it, and i'm fine with committing it
 in a new ticket if you think it's better.

 2/ Subscriptions.
 The story of this feature began at WCSF 2014 :)
 [[Image(https://cldup.com/ipRfw-jznQ.png)]]
 [https://bpdevel.wordpress.com/2014/11/12/at-wcsf-some-attendees-of/
 bpdevel post]
 So after looking at it, i've found that the idea was interesting. Having a
 button in the Site's community page header to subscribe to the site seemed
 interesting to me. Maybe i misunderstood a bit, or chose a wrong
 implementation.
 I've reacted to the fact, it's impossible today for a user to subscribe to
 a blog in a multisite config, although it's possible in a regular one ??
 In admin you can add existing users but you have to know the email address
 of this user... Anyways..
 I've chose to use the subscriber role, because i thought Admins would be
 able to promote subscribers very easily if needed. I've just finished my
 step 3 so i'll upload a new patch with some complementary informations
 about what i have in mind. I think if the Single Site has no
 subscription/join feature, it's going to be a very sad place, not a funny
 community place :).
 So if WordPress is not allowing on purpose to subscribe to blogs in a
 multisite config because the `get_blogs_of_user()` function would be too
 slow, i can understand your concern. It could be a good reason to drop
 what i've built so far, i agree :)

 The step 1 to 5 are correct :) The is_contributor column is always filled
 with `1` if user_can( 'edit_posts' ) or `0` if user_can( 'read' ) only. If
 i want to get the contributor i query for 1, if i want the subscribers i
 query for 0. If i want everyone i don't add a where is_contributor clause.
 I'm not using `get_blogs_of_user()` :)
 I don't need this to show the blogs in the directory, i need this to get
 all members of the blog in order to list them in the members templates of
 the Site's feature :)

 So each time a user subscribe to a blog, it's writing the 2 usermeta
 WordPress uses and + the blog association with a 0 value for the
 is_contributor field.
 BTW, it's already possible to have subscribers in the `bp_user_blogs`
 table. This is something i'm fixing in the one of the patches. When a user
 is demoted from any user_can( 'edit_posts' )  to subscriber, he stays in
 the table today.

 > in my experience the Subscriber role has almost no meaning

 I value a lot your experience and i think you're 100% right. And at the
 same time it's a bit sad. And precisely I thought we could try to improve
 this by adding new community features for subscribers:
 - Bulk mail news about the site
 - Guest posts
 - Publishing activity updates into the Site's community page...
 - etc..

 Discussing with some friends there's a real need to have a front-end
 interface to "manage" blogs in multisite. Something more easy for
 customers. So i guess people could extend the BuddyPress site's feature to
 add front-end posting, comments moderation, etc..

 Finally about unittests. I'm simply suggesting to add the multisite group
 to the excluded ones in the `phpunit.xml.dist` and take every tests we
 only run when it's a multisite and add the `@group multisite` tag. This
 way we can avoid the `if ( ! is_multisite() ) return;` thing we're adding
 before each of these tests.

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