[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.4
Component:  Component - Blogs             |     Version:
 Severity:  normal                        |  Resolution:
 Keywords:  dev-feedback has-patch early  |
------------------------------------------+------------------

Comment (by imath):

 I've been working on improving 02.patch trying to take in account
 everybody's feedback. Thanks a lot to all of you.

 Today i'm back on this ticket with a new version of the patch:
 6026.03.patch. It would be great if you could review it to make sure i'm
 on the right way with this feature and i haven't forgot anything.

 1. Reorganization of the patch. Since r-a-y's introduction of
 `bp_is_active( 'component', 'feature' )` in 2.3, i've centralized as much
 as i could the functions about the Blogs single item feature in a specific
 file (bp-blogs-blog.php). It only loads if the feature is enabled, which
 is by default the case. If network admins do not want it, they just need
 to do `add_filter( 'bp_is_blogs_blog_active', '__return_false' )`

 2. Single items navigation. boonebgorges and jjj was worried about me
 editing the `buddypress()->bp_nav` and `buddypress()->bp_options_nav` at
 the end of 2.3 dev-cycle. And i must admit i'm not feeling very
 comfortable in this area. So in this new version of the patch, i'm taking
 no risk at all about what's in place for the displayed user or Groups
 single item navigation. I'm convinced, as `buddypress()->bp_nav` is first
 designed to manage the displayed user nav, single items should not use it
 to:
 - avoid slug collisions
 - be able to use a main nav and a subnav and not only a subnav, like it's
 the case today for the Groups component.

 So I'm using a new class `BP_Single_Item_Navigation` to clearly put things
 apart and attach the generated navigation to the component's single item
 feature (eg: `buddypress()->blogs->nav`). It might be improvable, but it's
 already doing a nice job for Blogs single items :)

 3. Subscriptions. Bowe shared his worries about adding a role to the user
 on the subscribed blog and r-a-y about my use of the
 `$wpdb->base_prefix}->bp_user_blogs` reminding me this table was first
 designed to list each blog contributors. I really thought about these 2
 points and came to this conclusion: I think, by default, the
 subscription's feature should really mean to get the subscriber role on
 the blog to avoid any confusion because to me the goal of "subscribing" is
 to become a part of. Moreover i can see an interest of having the users
 visible from the WordPress Edit users Administration screen because it's
 then possible to promote a motivated subscriber to a contributor. But, i
 can also understand Network admins not thinking like me, so i've included
 a filter for them, they simply need to do `add_filter(
 'bp_blogs_blog_wp_subscriber_role', '__return_false' );` and the user
 won't get a role on the blog and will be able to follow the blog's
 activity from his profile or the activity directory thanks to new
 navigations. I've alse explored how the user / blog relationship was
 managed so far in the blogs component. And i think we should improve it.
 Let's say a user is added to the blog as a subscriber, he doesn't see the
 blog in his "My sites" profile nav, which is right. But let's imagine he's
 promoted as a contributor by the blog's administrator, he won't see the
 blog in his profile navigation. We then need to repair the user to blog
 association for all blogs. To come back to how to save a blog's
 subscription, i then thought the best was to introduce a new field into
 the `$wpdb->base_prefix}->bp_user_blogs`: 'is_contributor' which will be
 filled by a '1' if the user is at least a contributor or by a 0 if the
 user is a subscriber. Doing so we're able to separate the 2 kinds of blog
 users and add a new user's profile nav next to "My blogs": "My
 subscriptions". Then i've edited some blogs functions like
 `bp_blogs_record_existing_blogs()` or `BP_Blogs_Blog->populate()` so that
 existing subscriptions are not removed, but blog association is repaired
 by updating each row instead of truncating the table before adding rows.
 I've also edited the hooks the function `bp_blogs_add_user_to_blog()` was
 attached to in favor of 'set_user_role' so that when a user is edited from
 the Administration, his contribution level is also updated (eg: when a
 subscriber is promoted to a contributor) without the need to repopulate
 blogs records.

 4. Some other improvements:
 - a new WP Admin Bar menu when viewing a blogs single item so that the
 admin can easily access the manage screens of his blog or his WordPress
 Administration.
 - If the blog is using a theme that supports custom header, i set it as
 the background of the blogs single item's header.

 To conclude this quite long comment, here's a demo of the patch :)

 https://vimeo.com/130832800

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