[buddypress-trac] [BuddyPress Trac] #6026: And if the Blogs component had Single items?

[buddypress-trac]

#6026: And if the Blogs component had Single items?
------------------------------------+------------------
 Reporter:  imath                   |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  2.3
Component:  Component - Blogs       |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |
------------------------------------+------------------

Comment (by imath):

 > fast & furious

 I think that could be my new nickname :) @mercime already used this in one
 of her great dev-chat summary.

 First many thanks to all for your feedbacks.

 To completely be honest, as soon as i came back on the work i've been
 doing into this part, i strongly felt we were too close to the first beta
 of 2.3 to have something completely ready (function names, strings...)
 with minimal risks. But as i kind of promised during last dev-chat i will
 work on it, then i put the accelerator on just to prove myself, even if i
 was getting old, i could still rush like when i was younger! When you
 rush, you need to quickly take decisions and i think the ones i took were
 the more consistent considering how we deal so far with `blog_public` /
 [wpdb_prefix]bp_user_blogs. But i'm not "Napoléon" and i strongly agree
 that the directions we'll take for the blogs component need more
 discussions and that we all agree on the future of this very important
 component.

 So '''no objections at all to move this ticket in 2.4'''. As
 @johnjamesjacoby suggested i will simply commit the unit tests about the
 navigation functions, so that there will be a little part of this work in
 2.3 :) Then i'll move it.

 I think we'll have the opportunity to discuss on the details later, but
 here's some of my convictions / replies :

 1. Blogs single items in a network of sites are really important. I have
 the opportunity to discuss with french freelances about the troubles they
 have with their clients. They usually solve it by tweaking the WordPress
 administration and capabilities so that their client don't acccidentaly
 break their sites. HappyTables worked on an interesting simplification of
 the WordPress administration. It looks like there's a need in which we can
 do a part of the path. I'm not saying we should complete it, but we should
 at least provide the "container" plugins would be able to extend to bring
 site's contributions into the front-end and in a more granular way than
 it's the case today natively with WordPress. Moreover, as i said earlier :

 > How a member can become a subscriber of a blog in a network ? He can't
 I agree with @boonebgorges that we need to better define how this new
 interactions should work. In 02.patch i did the minimal by adding a
 notification to the admin when a new subscription is done on one of his
 sites. But we can imagine invitations and requests... Although it think we
 should keep things very simple. Let's talk about
 [wpdb_prefix]bp_user_blogs : here i disagree with @r-a-y :) if this table
 was restricted to contributors, then we should actually make sure it's not
 possible to have subscribers in! And if i do that:

 {{{
 function imath_get_subscribers( $roles = array() ) {
         $roles[] = 'subscriber';
         return $roles;
 }
 add_filter( 'bp_blogs_get_allowed_roles', 'imath_get_subscribers', 10, 1
 );
 }}}

 i get the subscribers :)
 So i guess if we were to restrict this table with contributors, we should
 check a contributor's capability instead of using the role names. But then
 custom post types... Moreover "My" Sites is a bit confusing, it can be the
 sites i own or the sites i'm a part of, or the sites i contribute to. I
 choosed the second one as in this table we can have any users of the site
 :) And actually i'm not sure we should restrict this table.
 I think the right move is to edit the `BP_Blogs_Blog->populate( $blog_id,
 array( 'populate_extra' => true ) )` function i'm using in 01.patch or
 02.patch so that we get something like this :
 {{{
 // Is the current user someone who joined the blog
 $this->is_member = (int) bp_loggedin_user_id() === (int) $wpdb->get_var(
 $wpdb->prepare( "SELECT user_id FROM {$bp->blogs->table_name} WHERE
 blog_id = %d, $this->id ) );

 // Is the current user a contributor
 switch_to_blog( $this->id );
 $this->is_contributor = current_user_can( 'edit_posts' );
 // get admins...
 restore_current_blog();
 }}}

 Then, the Blogs Users Administration screen would not suffice, as it's
 very complex to inject members having no role on the blog into this
 screen. So we really need the Blogs single item manage members screen i've
 suggested to manage the subscriptions and eventually grant some users with
 more contributions power :)

 And unlike what i've done in the patches, subscribing would simply consist
 of being into the [wpdb_prefix]bp_user_blogs table without any role on the
 blog.

 2. '''BuddyPress navigation''': this part might need to live in its own
 ticket. I think the way it's built today really needs to be improved. It
 doesn't seem right to me to put a component's navigation into the user
 one. Because :
 - members != blogs != groups...,
 - you only have a subnav to manage the component's screens,
 - and you have conflicts see #5103.
 As @r-a-y said, by clearly separating things we transform these navigation
 functions into a powerfull API plugin can use to safely build their
 component's nav. So we really should work on it and the groups component
 should also use its own nav in the future.

 3. `blog_public` is annoying, it means "don't show my blog in search
 results" (WordPress adds this meta tag `<meta name="robots"
 content="noindex,follow">` if not public) and we're using it to publish or
 not activities. So in 01.patch and 02.patch i kind of avoid the trouble by
 disabling all features if `! blog_public` (no activity page, no
 subscriptions.. ). But i think the right thing should be to allow these
 blogs to post private activities that would only be displayed within the
 corresponding blogs single item making sure to add the noindex meta tag on
 each page of the item.

 4. Activities: we should allow discussions to happen into the blogs single
 item, i can imagine the interest for a group of contributors to use this
 feature to discuss about content into a "restricted blog" or for the admin
 of a "widely open" blog to share quick status with his subscribers or
 allow discussions about the blog in general and not only on a particular
 post or page like it's the case using WordPress comments.

 5. the mystery-blog :) Yes i agree just like we might need a mystery-group
 see #6372

 Again, many thanks to all, i'll commit the unit tests tonight and move the
 ticket to 2.4.

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