Skip to:

Opened 9 years ago

Closed 6 years ago

#6026 closed enhancement (maybelater)

Single items for the Blogs component.

Reported by: imath's profile imath Owned by: imath's profile imath
Milestone: Priority: normal
Severity: normal Version:
Component: Blogs Keywords: dev-feedback, has-patch, trac-tidy-2018
Cc: hnla, egyptimhotep@…

Description (last modified by imath)

New areas to improve sites discoverability/Blogs component features.

  • Each sites of the network will get a new single area just like Members and Groups.
  • Members of the community will be able to subscribe to sites and follow their activities from their profile page.
  • Site Admins will be able to access to some BuddyPress specific settings for their sites (Visibility, subscriptions, custom post types tracked, avatars, cover images) and manage their subscribers.
  • in a future release, we could provide an API to add modules to this area to publish content for the sites for instance etc..

Attachments (11)

6026.01.patch (128.6 KB) - added by imath 9 years ago.
6026.02.patch (163.3 KB) - added by imath 9 years ago.
6026.03.patch (203.8 KB) - added by imath 9 years ago.
6026.split.01.patch (182.8 KB) - added by imath 9 years ago.
The navigation part has been moved to #6534
6026.split.02.patch (183.6 KB) - added by imath 9 years ago.
To be used with 6534.item_id.patch on #6534
6026.smaller-steps.01.patch (78.8 KB) - added by imath 8 years ago.
6026.smaller-steps.02.patch (81.3 KB) - added by imath 8 years ago.
6026.smaller-steps.03.patch (104.6 KB) - added by imath 8 years ago.
6026.smaller-steps.04.patch (83.5 KB) - added by imath 8 years ago.
6026.smaller-steps.all.patch (294.7 KB) - added by imath 8 years ago.
6026.smaller-steps.all.02.patch (295.8 KB) - added by imath 8 years ago.

Download all attachments as: .zip

Change History (61)

#1 follow-up: @r-a-y
9 years ago

Very neat, imath!

My only concern is the duplicate feature set of blogs vs. groups. Especially if we are talking about merging groupblog functionality into groups. That being said, I can definitely see a use-case for your plugin on specific BP installs!

I think if we are to allow a blog single item page, we should remove the activity post form as that will generate UX confusion. There also needs to be a link to the blog itself.

Love the trickery you did to get custom widgets working! My other concern here is that the concept of a custom BP homepage is unnecessary. However, I think the widget page would make an awesome "Profile" or "Info" tab page. In my opinion, the single item homepage should be the "Activity" tab by default so users can easily access blog content immediately as the main point is to funnel activity to the actual blog.

Also, thanks for noting your technical challenges with bp_nav() / bp_options_nav(). Good to know. I'm not sure what we're doing with groups at the moment, but those functions haven't aged well.

The "Manage" tab is also my favorite :)

#2 in reply to: ↑ 1 @imath
9 years ago

Replying to r-a-y:
Thanks a lot for your feedback r-a-y :)

My only concern is the duplicate feature set of blogs vs. groups. Especially if we are talking about merging groupblog functionality into groups. That being said, I can definitely see a use-case for your plugin on specific BP installs!

Yeah, i was afraid team was to merge Groupblog with core in order to manage Blogs features. Maybe i'm getting old, but the more i think about it, the more i think it might not be the best way for the Blogs component. If Blogs functionalities are in Groups, then what is the need of a sites directory ? In the groups directory we'll have bloggroups and regular groups, i find it a bit confusing. It looks like a dark destiny for this component if there's no new features. Finally blogs are blogs, groups are groups ;) But i'm ok with whatever team will choose. That's the reason i've built this plugin, to suggest an alternative.

I think if we are to allow a blog single item page, we should remove the activity post form as that will generate UX confusion. There also needs to be a link to the blog itself.

Actually i'm leaving the choice to the Blog administrator. He can restrict the post form to him in order to be the only one to inform his subscriber of quick updates ;) I've added the link to the blog itself in the header. Very good point, thank you.

By default, the home page is the activity one, if the activity component is not active, it's the members one. But if the Site's admin added widgets in the specific sidebar, then it's the custom widget front that is loaded. Activity and members are in tabs in this case.

#3 @imath
9 years ago

  • Description modified (diff)

This ticket was mentioned in Slack in #buddypress by imath. View the logs.

9 years ago

#5 @boonebgorges
9 years ago

Pretty cool, imath! I built something similar for a client once.

What you've created here is essentially a "profile" for WordPress sites. I like the idea of having a sort of heads-up view of each individual site that is formatted in an identical way: while the sites themselves may have very different themes and information architectures, the site profile pages will always look the same. (This is, in fact, the very problem that my client was trying to solve.) The flip side is that it creates an extra layer of abstraction, which means one more level of clicking for users who want to browse through and visit sites.

Regarding the groupblog stuff: I don't think what you've proposed here is in conflict with the groupblog suggestion. Group-blog connections would be optional, and blogs would still be standalone items. The group-blog connection would be used for things like sharing activity and membership.

I don't know what I think about including all of this in core. It's a pretty big change from what we currently have. I'm not positive that you have solved the problems you've laid out in the ticket description, but certainly this could be the framework for doing things like blog taxonomies that *would* enable better discoverability, etc. I hope you continue to work on the plugin, and maybe we can think about what it would look like as a core feature as you continue to build it out. Thanks for sharing!

#6 @Bowromir
9 years ago

I think this is a very interesting direction for the "Sites" component and I agree that making Sites more discoverable is something that would be important for lots of communities. The thing I'm not so sure of is giving each site it's own "Profile" by default. My reasoning is that I feel having something like this in core is a bit too much for a standard BuddyPress community and has the potential to make the already fairly complicated distinctions between components and streams of communication more complicated. Especially how "Sites" would be perceived very similar to "Groups" (Like R-A-Y said).

I do see the usefulness of giving certain "Sites" their own Group (or extended functionality). But imo this could be achieved by ticket #4017 which would open the possibility to create different Group Types and would let a site admin create something more akin to Facebook where you have "Discussion Groups" and "Sites/Pages". Then by integrating "Sites" more closely with "Groups" (as proposed) it would set the stage for this type of functionality without having to create a new component similar to Groups.

Of course this is quite far away, but I feel this would give site owners the choice to give Sites a lot more features by simply making it a Group Type and optionally link one of their "Sites" to a new group. In theory it could then work like this:

  • Group type "Sites" would have it's own directory page only listing groups with Group Type "Sites"
  • "Create Group" button would be turned into "Add My Site".
  • When you click "Add My Site" you see a radio button with your own created sites and you click the one you would want to link t a new Group.
  • The setup would skip a fair amount of Group Creation steps and would only present the Group Avatar and Invite screens.
  • Once the Site Group is created it would look very similar to Matthieu his screenshot (Activity / Members /
  • Using a filter you could turn "Join Group" into "Follow Site / Subscribe" to receive updates from this site.


  • You could open up the door to let a Site Admin enable additional Group extensions (forums, docs etc) for their site.
  • You could allow the possibility to add an RSS feed to an site to allow "External Sites". This could probably be added at the "Add My Site" creation step.

Like I said this is very very far away but it might make a lot of sense for communities that would like to create a community with a lot of focus on external and internal websites by their members. The point I'm making is that you could probably create something like this when the Group taxonomies (types) are working.

I have some ideas of what we could do with the "Sites" component to make it a bit better, but I'll post those ideas in a separate comment :-)

Last edited 9 years ago by Bowromir (previous) (diff)

#7 @DJPaul
9 years ago

  • Milestone changed from Awaiting Review to Future Release

I'm moving this ticket into the Future Release milestone so we can remember the idea and keep discussion open until what we decide to do with this in the future releases. I am trying to clear out the "awaiting review" milestone, and this ticket has. :)

This ticket was mentioned in Slack in #buddypress by r-a-y. View the logs.

9 years ago

#9 @johnjamesjacoby
9 years ago

This is incredibly awesome.

Giving Blogs a real BuddyPress "reference" has been a theoretical concept since before 1.0, and it's really, really great to see this much effort having gone into it on this ticket so far.

#10 @imath
9 years ago

  • Keywords has-patch added
  • Milestone changed from Future Release to 2.3

Thanks @jjj :)

Some explanations about 6026.01.patch :

1/ I needed to improve the BuddyPress nav so that it's possible to create a new nav/subnav for a component's single item. I've added a bunch of unittests to make sure there are no side effects with this improvement.

2/ Users can subscribe to a site and easily find their sites from the "My sites" scope

3/ Admins can manage some specific settings such as the 'blog_public' one or the 'disallow_subscription' one. This last setting is only available for the public blog in case they do not want to open subscriptions. For private one, the subscription feature and the activity nav are disabled.

4/ Site logos: at the beginning i was checking if the blog has an avatar to eventually fall back to the admin avatar. I changed my mind, because we are not really getting the admin ID but any member having a link with the blog. As a result when viewing my sites, my avatar was used as default for a blog i wasn't an admin of.

5/ Create a blog > when user/blog are registered i use a transient to eventually redirect the loggedin user after activation to welcome him inside his site's profile and allow him to set the site logo. When the user already exists and if he adds a new blog from the site's directory, i add a link once the blog is created under the confirmation.

6/ Added some filters and in particular one to completely disallow the blogs single item feature.
add_filter( 'bp_blogs_disable_single_items', '__return_true' );

7/ I've disabled the activity post form and for this first pass didn't include the widgets part because i think it would require a lot more testing.

If we want to have this in 2.3, i think it would be great to have an extra week to test/review it. I think about specific configs such as when BuddyPress is not network activated.

  • @r-a-y it would be great if you could check i'm doing the right thing in the cache area.
  • @johnjamesjacoby it would be great if you could have a look at the function names i've used, and actually a more global look on the patch :)

Anybody's feedback is welcome :)

More than the ability to set a site logo, this feature is bringing a new section where we can deal with some specific settings related to a blog thanks to the manage screen. It could potentially help us to have a site by site activity tracking preferences.

Here's a link to a video demo :

9 years ago

This ticket was mentioned in Slack in #buddypress by imath. View the logs.

9 years ago

#12 @Bowromir
9 years ago

I'm really excited to see this take shape.. Amazing work Mathieu! Some questions:

What does it mean for a user to be subscribed?
Would subscribing to a blog mean they would get the role of Subscriber as defined by WordPress? Would they receive emails for new posts? Or would they receive new blog items in their activity newsfeed? Or is it a admin defined mixture of any of these things? Or maybe they are just listed a Subscribers on the single Site page? So what I'm trying to say is.. How can we make it clear to the user what it means to subscribe to a site and which options should be provided for subscribers to be notified of new content. For example:

"By subscribing to this site you will be notified of new content published on this site."

User clicks on the "Subscribe" button
*Radio buttons appear with Javascript*

You are now subscribed to "JJJ his Amazing Site"! You will now see "JJJ" his new content appear in your Activity newsfeed.

More notification options:
[ ] Send me an email when "JJJ" publishes new content
[ ] Send me a Notification when "JJJ" publishes new content

Note: You can change the notification settings for any of your subscribed sites by going to your "My Subscribed Sites" page.

Groups vs Sites
I mentioned before that I think there's also a potential for people to get confused about Groups vs Sites if too much functionality is overlapping and the templates are pretty much identical. I can imagine that some communities would simply like to have a Site/Blog listing the way it currently stands.. Will this be possible?

Thanks so much for all the amazing progress you made on this ticket imath :-)

Last edited 9 years ago by Bowromir (previous) (diff)

#13 @imath
9 years ago

Thanks a lot Bowe for your feedback.

What gave birth to this patch ?
During last dev-chat we were looking for the best place to let people having a site on a network set a logo for their site using the new avatar UI. In #192, the user profiles is suggested, i was more thinking about a place in the WordPress administration like the general options where you have the site title, description.. But i like the idea of having a specific BuddyPress place to deal with that. Group & User avatars are mainly set on front end, why not doing the same for sites? Having this specific area can be interesting in the future to add specific BuddyPress settings for each blog for instance.

A subscriber is a subscriber. What does a subscriber get in WordPress, does he receive email notifications.. natively. No. But plugins can extend WordPress to add such features. I think about this blog single item feature like something that could be extended in the future. The idea is to provide the house first :)

But i agree, if we are to have this in, we could quickly provide new tabs in the user's activity or directory to filter the stream for the blog he subscribed to. All your suggestions are interesting.

How a member can become a subscriber of a blog in a network ? He can't, he needs to be added by a Super Admin. Even the regular blog admin cannot add a user to his site (he can remove some - it makes me think we should add a button to let the admin remove a user from his site from the front end...). I think it can be interesting to give the opportunity to users who like a blog to subscribe so that they show their interest. Once there, it seems a natural place to imagine plugins provide workflow / guest posting... / Posting on a given category.. all this from the front end :)

What is the future of Blogs component, now that we are progressively moving some tracking features into the Activity one ?
The patch is not adding all the features i imagined with the plugin i've started to work on. I've tried to do a little step. Providing a unique place where you can get all the site's activities. Simply seeing who's joined a site, displaying the members of this site on front end is something WordPress doesn't provide. If i see someone who joined a site in the activity stream it can give me the idea to discover the blog...
In a near future, we can imagine to open the activity post form so that subscribers and contributors can talk about the blog, give their general feedback... :)

It's not Groups Vs Sites, it's giving the user a lot more choices :)
1/ This feature is a network only one.
2/ As said in my previous comment, using this filter add_filter( 'bp_blogs_disable_single_items', '__return_true' ); you completely disable it. (if the filter is not user friendly, we can imagine an option..)
3/ On a network people can prefer to not activate the groups component, not activate the blogs one, activate both .. They're free to choose their way :)

Thanks you very much for your ideas and questions it gave me new ones and answers :)

Last edited 9 years ago by imath (previous) (diff)

#14 @imath
9 years ago

I had the opportunity to test 01.patch on some specific configs :

  • a network where WordPress is installed in a subdirectory
  • a network where BuddyPress is not installed network widely.

I've found some issues on the way i'm getting the blogs slugs. So 6026.02.patch is first fixing these.

Then, @bowromir's latest comment made me think of various possible improvements :

  1. Subscribing to a blog now also means to view all subscribed blog activities from the "My Sites" tab of the activity directory or the one in the member's profile (Many thanks to @r-a-y for the great improvement introduced in 2.2 about activity scopes!)
  2. To make things more user friendly, i'm now including a new setting to let admins completely disable the blogs single items from the BuddyPress Administration settings screen
  3. When a blog is removed, i remove the corresponding avatar (maybe we should also do that for groups)
  4. I've added a new manage screen in the single blog item so that the administrator is able to remove subscribed users directly from front end.
  5. Added a bunch of hooks at key places
  6. Finally i'm adding notifications/emails to administrators in case a member joins their blog.

9 years ago

#15 @johnjamesjacoby
9 years ago

Before any more updates come in, can we rename the blog_type functions to blog_status? Or whatever mirrors blog status functionality? I think that code was copied from the Groups component, which confusingly juggles "type|status|visibility" in a few places.

I had started editorializing a new patch version, not considering an updated patch was imminent. My fault; I should have asked and assumed you would be fast & furiously refining!

Last edited 9 years ago by johnjamesjacoby (previous) (diff)

#16 follow-up: @johnjamesjacoby
9 years ago

Are the new options navigation functions necessary? The extra layer of abstraction and unique use-case for only the Blogs component makes me a little nervous, and afraid it's too close to beta to be confident it's the correct approach.

#17 in reply to: ↑ 16 ; follow-up: @boonebgorges
9 years ago

Replying to johnjamesjacoby:

Are the new options navigation functions necessary? The extra layer of abstraction and unique use-case for only the Blogs component makes me a little nervous, and afraid it's too close to beta to be confident it's the correct approach.

imath - You have done some really great work on this issue, but I'm leaning toward agreeing with johnjamesjacoby here. It seems late to be rushing this into the release, given the changes to core stuff (like the bp-core-buddybar.php functions), not to mention the sheer scope of the improvements. I have lots of questions about how the user experience is going to be here - how blog_public interacts with this stuff, how the idea of "subscribing" to a blog interacts with blog membership, how we'll degrade gracefully with pre-theme-compat themes, etc - but I don't think there's adequate time for review and discussion before going to 2.3 beta. My recommendation is that we make this a headline feature for 2.4.

#18 in reply to: ↑ 17 @johnjamesjacoby
9 years ago

Replying to boonebgorges:

My recommendation is that we make this a headline feature for 2.4.


If there's no strong opposition, I motion we move this ticket to the 2.4 milestone by Wednesday so we can focus on polishing up 2.3, and commit this early in the 2.4 cycle. I absolutely think the efforts in this patch are incredible, and will make the Blogs component into something super sweet.

#19 follow-up: @r-a-y
9 years ago

Like everyone else has stated, nice work, imath!

This is definitely a step in the right direction.

Here are some of my comments:

  • "Activity > Sites" user subnav - We should have done this a long time ago. +1!
  • Perhaps we need a default blog icon so the mystery man isn't used when a blavatar hasn't been uploaded yet?
  • Subscriptions are currently recorded into the wp_bp_user_blogs table. However, this table is currently used to record users whose role is greater than 'subscriber'. If we share the table for both use-cases, it will be hard to distinguish between "My Sites" (sites that I am currently a contributor of) from "My Subscribed Sites". I think we should hold off on subscriptions, so we can better establish what we want to do here.
  • I do not think we need the "Manage > Members" screen at the moment. Perhaps a link to the sub-site's "Users" dashboard would suffice?
  • I like the addition of the 'single_subnav' (perhaps rename to 'subnav_id'?) parameter in bp_core_new_nav_item() and the mods to how the nav items are registered / outputted. `. It will help devs in generating subnav menus for their plugins.

#20 in reply to: ↑ 19 @johnjamesjacoby
9 years ago

Replying to r-a-y:

I do not think we need the "Manage > Members" screen at the moment. Perhaps a link to the sub-site's "Users" dashboard would suffice?

This was my favorite part! :)

#21 @johnjamesjacoby
9 years ago

Any objection to committing the unit tests for existing navigation functions for 2.3?

#22 @imath
9 years ago

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...

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.

  1. 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.

  1. 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.
  1. 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.
  1. 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.

#23 @imath
9 years ago

In 9818:

Add unit tests for BuddyPress navigation functions.

See #6026

#24 @imath
9 years ago

  • Keywords early added
  • Milestone changed from 2.3 to 2.4

#25 @imath
9 years ago

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' )
  1. 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 :)

  1. 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.
  1. 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 :)

9 years ago

#26 @DJPaul
9 years ago

Dropping into here because I think it's something we need to consider for the future.

#27 @imath
9 years ago

@DJPaul +1 using the customizer in blog's back end might be an interesting idea to manage the site's "profile photo". Will look at it and the WP site icon plugin available on github

This ticket was mentioned in Slack in #buddypress by imath. View the logs.

9 years ago

#29 follow-up: @DJPaul
9 years ago

This patch really needs to be split up into separate tickets/feature enhancements. Happy to walk through it with you and find where we can do this if you want.

200KB is alot of code. The more code you have, the worse any code review will be. :)

#30 in reply to: ↑ 29 @johnjamesjacoby
9 years ago

Replying to DJPaul:

This patch really needs to be split up into separate tickets/feature enhancements. Happy to walk through it with you and find where we can do this if you want.

200KB is alot of code. The more code you have, the worse any code review will be. :)

I'm pretty strongly opposed to forcing Imath to break this patch up. It doesn't matter if it's 1 patch or 25 small ones; the code changes are the same, and the review process is the same:

  • Apply patch
  • See changed files
  • Open a changed file
  • Review changes
  • Iterate if necessary
  • Do the same for all other files
  • Create an updated patch
  • Repeat

I would like to avoid having several of us stomping on each other's changes. In the case of massive feature development with Subversion, it makes the most sense to have:

  • One person does the architecting
  • Submit their patch
  • Pencil down and stop iterating
  • Second person reviews the patch
  • Iterates on the patch
  • Submits a new patch
  • Both individuals peer review each other until both agree it's ready for core commit
  • Once it's committed, we can all patch and iterate until 2.4.0 is released

Sound like a plan?

9 years ago

The navigation part has been moved to #6534

#31 @imath
9 years ago

As discussed, during yesterday's dev-chat, i will split the ticket in smaller parts. I'm beginning with the navigation part.

If you want to test 6026.split.01.patch, you'll need to also apply 6534.patch

9 years ago

To be used with 6534.item_id.patch on #6534

#32 @imath
9 years ago

  • Keywords needs-refresh added; early removed
  • Milestone changed from 2.4 to Future Release

#6534 is a blocker. We first need to improve the single items navigation before adding a new single item and taking the risk of more slug collisions.

We'll be back on this ticket later.

#33 @imath
8 years ago

  • Keywords needs-refresh removed
  • Milestone changed from Future Release to 2.7
  • Owner set to imath
  • Status changed from new to assigned

So i'm back on this ticket, and i'll do my best to have it fixed for the 2.7.0 milestone :)

This time, i'll try to work in smaller steps, so that reviews are easier. The first step 6026.smaller-steps.01.patch is about DB and files organisation.

  1. I'm adding a new field is_contributor to $wpdb->bp_user_blogs to prepare the site subscriptions feature. Contributors will have this field set to 1, and subscribers set to 0. I've also edited a bunch of methods in BP_Blogs_Blog to take this change in account.
  2. I'm adding a new Site settings section where it is possible to easily completely deactivate front-end site subscriptions. BTW a site subscription is a way to get the subscriber role for a site. When i'll build the step for the sites single items, i'll add a new single site options (using blogmetas) Site admins will be able to use to disable subscriptions for their specific site.
  3. WordPress 4.6 is introducing a very interesting class WP_Site_Query to query for sites. So i thought we should use it to progressively replace the way we are querying sites in BP_Blogs_Blog::get(). In the patch, you'll see that i check for the get_sites() function before using it, if the function is not available (WordPress is < 4.6) we fallback on BP_Blogs_Blog::legacy_get() which has improved a bit how we fetch sites and makes sure it can also handle single site queries.
  4. As the site subscriptions feature is optional, i thought we should load more "granuraly" the code for the site feature. In other words only load the needed code if active components or options allowes us to use it. So the bp-blogs/bp-blogs-site.php file only loads if bp_is_active( 'blogs', 'site' ) and inside it files are required only if components or the site subscription are active. Most of the files like bp-blogs/site/functions.php, bp-blogs/site/template.php... aren't finished yet as it's the first step of the patch :)
  5. I've edited the phpunit.xml.dist unit test configuration file, because it seems a bit weird to include multisite tests into regular tests. So i've added to it a group exclusion (multisite) which allowes me to only tests specific multisite tests when the multisite.xml configuration file is used (and avoids the ! is_multisite() return; we're currently using inside each multisite specific tests). I'm also adding a new configuration file subdomains-multisite.xml because it's pretty different when SUBDOMAIN_INSTALL is true to query for the site's slug. These are suggestions, we can adopt or not.
  6. I've edited some tests so that the legacy_get() function is still tested in WordPress 4.6+ and add a new one for the single site query.

Finally after applying this patch, the only difference you can see is how the $wpdb->bp_user_blogs is populated since the introduction of the is_contributor field. Depending on the site subscription settings, a subscriber will be added or not to this table. If a user_can( 'edit_posts' ) role is changed to a subscriber role, it will have his contributor field set to 0 (if subscriptions are enabled) or he will be removed from this table (if subscriptions are disabled). Today, he stays inside this table no matter the changes (till the site owner uses the repair tool).
I'm also introducing a new site_adminsblogmeta to store the list of admins. This way i'm making sure the user avatar is the one of an admin and not a contributor as it can be today. + this blogmeta will be usefull later for other needs.

This is it for this first step, feedbacks are very welcome. In the meantime, I'm moving to step 2 :)

#34 @DJPaul
8 years ago

Is the ticket description still accurate to what your patch does? It's very long, the ticket's two years old, I think it might be worth clarifying what the goals are.

#35 @imath
8 years ago

It's a first step, at the end (once all the needed steps completed) it will bring blogs single items.

But i'll recheck the description.

#36 @imath
8 years ago

  • Description modified (diff)
  • Summary changed from And if the Blogs component had Single items? to Single items for the Blogs component.

#37 @imath
8 years ago

Here comes the step 2 (6026.smaller-steps.02.patch). You'll need to apply the "step 1" patch (6026.smaller-steps.01.patch) before this one.

This patch first fix an issue i've missed in step 1 when a member has no site and improves the bp_blogs_get_site() also introduced in step 1.

Then, you'll begin to see the Site single item :) In this patch i mainly focused on the Single site's navigation. As you remember it was a blocker a few months ago.
I chose to leave the current bp_core_*_nav_item functions the way they were because i wasn't sure to understand what was done there and i was too afraid to break something in the User or Group's nav.
Actually, the more i've tried to understand, the more i thought we shouldn't manage the screens access inside the functions that are building the navs. So this patch is illustrating an alternative way of managing the screens access. Moreover as i've chosed to use a Nav and a Subnav for the Sites i think it's a good practice if one day we want to use a main nav and a sub nav for the Groups (currently it's a subnav only).

The key function is bp_blogs_set_site_screens(). I'm hooking bp_template_redirect before bp_redirect_canonical to be sure to be able to edit the canonical url just like we're doing in the two others single items. Then i manage the screens according to the URI and also set the current active nav and subnav. For this last point, i've introduced bp_core_edit_nav_item() to have a shortcut to buddypress()->blogs->nav->edit_nav().
I've also edited bp_core_create_nav_link() so that the link generated by it for the primary nav can be something else than the loggedin_user_domain (eg: the current group or site links).

The rest of the patch is about the single site screens and templates. I still need to take care of:

  • subscriptions, Site settings, avatar and cover image,
  • add a new user subnav to list the activities of the sites the user subscrived to, add another one inside the Activity directory,
  • add screen and email notifications.

This ticket was mentioned in Slack in #buddypress by mercime. View the logs.

8 years ago

#39 @hnla
8 years ago

  • Cc hnla added

#40 @boonebgorges
8 years ago

Hi @imath - Thanks for working on this!

WordPress 4.6 is introducing a very interesting class WP_Site_Query to query for sites. So i thought we should use it to progressively replace the way we are querying sites in BP_Blogs_Blog::get().

If there's decent test coverage, and you feel good about this change, you should commit it. It's a meaningful improvement, regardless of whether we implement single blog pages.

I am a bit confused about the Subscriber and Contributor stuff. Let me see if I can put it together:

  1. You're introducing the concept of Site Subscriptions
  2. You'll be using WP's Subscriber role to indicate a subscription.
  3. You want to store this data in a way that it can be easily accessed by BP. This suggests the bp_user_blogs table.
  4. But the bp_user_blogs table currently only stores user-blog relationships when the user is at least a Contributor.
  5. So, for backward compatibility with this functionality, you're introducing an is_contributor column.

Is that correct?

If so, it seems crazy :-D First, regarding (b), in my experience the Subscriber role has almost no meaning in WordPress. Using it to indicate a BP site subscription seems like it will have odd side effects. Think, for example, about how it will change the return value of get_blogs_of_user(). Second, is_contributor seems narrowly named. If I understand correctly, what it really means is "show this site in my directories". Currently, BP hardcodes this option: a site is shown in your directories if you're a Contributor or greater. But this seems kinda arbitrary, and something that we may want to change in the future. How about show_in_directories column, or something like that? Then directory queries would be something like SELECT ... WHERE ( show_in_directories = 1 OR is_subscribed = 1 ) ...

I've edited the phpunit.xml.dist unit test configuration file, because it seems a bit weird to include multisite tests into regular tests.

How does this relate to /tests/phpunit/multisite.xml? As with WP_Site_Query, if you figure out a configuration for multisite tests that makes sense, you should go ahead and commit it separately from this ticket, as it's an independent issue.

#41 @imath
8 years ago

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 :)
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.

#42 @imath
8 years ago

Here comes step 3!

In 6026.smaller-steps.03.patch:

  • I'm now using a mystery avatar as the default site's avatar. For now it's a SVG file, but i'm open to change it to whatever people like. So if anyone wants to contribute and design a great default avatar for sites, you're welcome!
  • I've added The Site Manage settings screen where the site admin can change the title, description, the "Public" property of his site (so it's now more easy to understand why Post types are not tracked), and Disable/enable site subscriptions.
  • Site admins can also manage their members, promote subscribers to contributor or demote contributors to subscribers, or remove members.

  • Members, depending on the availability of subscriptions (global settings + the one of the displayed blog) can subscribe to sites.

What they get?

They get a new Activity tab where they can follow the activity of their subscriptions for now. But i can imagine some future enhancements.

I'm also adding some new tabs:

  • My sites into the Activity Directory
  • My Subscriptions into the Blogs Directory.

As usual, feedbacks welcome :)

#43 @imath
8 years ago

Here comes step 4 and a first 'all steps' version of the patch.

In 6026.smaller-steps.04.patch i'm adding:

  • Local avatar management for sites,
  • Cover image management for sites,
  • Cache functions for bp_blogs_get_site()
  • some fixes to bugs i've found in previous steps.

There are 2 very important points:

  1. Avatars for site can be synchronized with the site icon feature:
A new nav item is available in the avatar UI to do so. If the site icon is removed, so will be the avatar, if the site icon is changed so will be the avatar.

  1. Spamming subscribers. I think WordPress is very severe. So i've suggested this patch on Core trac: #WP37538. What's the problem? It's get_blogs_of_user() :) The function is not checking for the user's impact on content, it just spams all sites the user is subscribed to. Which in the road i've took so far (using the subscriber role for subscriptions) is really annoying!

So i've been doing some tests with a user who was a subscriber of 6 sites and it appears BP_Site_Query can do the same job than get_blogs_of_user() but 3 times faster! I've "fixed" point 2 using BP_Site_Query to only get the sites the user has a contributive role on for WP >= 4.6 and for the older versions, i'm removing the sites the user has no contributive role on of what returns get_blogs_of_user().

To come back to @boonebgorges concern about using the subscriber role for subscriptions. I think we have 2 choices:

  1. Use it, and override get_blogs_of_user() so that only the sites the user has a contributive role on will be listed into the network users administration screen.
  2. Or simply use the bp_user_blogs table to store the subscription eg: is_contributor: 0 (that's what i'm doing when using the subscriber role anyway). In other words b. is a. minus the subscriber role.

The problem with b, and one of the reason why i think it's best to use the subscriber role, is that as soon as the Network admin will run the Blogs repair tool, every sites will loose their subscriptions.

There's still a step to add about notifications when a sites is subscribed. But i'll wait for your feedbacks about this alternative before working on it.

To ease testing, i'm attaching 6026.smaller-steps.all.patch. It includes steps 1 to 4.

#44 @imath
8 years ago

@mercime just tested with a "localhost" Ms Windows install, and i've found a few bugs so 6026.smaller-steps.all.02.patch should be ok for testing :)

#45 @egyptimhotep
8 years ago

  • Cc egyptimhotep@… added

#46 @DJPaul
8 years ago

Note: when this goes in, we can update #7120 with the same change for single item blog screens.

#47 @r-a-y
8 years ago

  • Milestone changed from 2.7 to Under Consideration

Let's look into implementing a simpler version of what is being recommended, hopefully for v2.8.

For now, I'm moving this to the "Under Consideration" milestone.

#48 @DJPaul
8 years ago

  • Milestone changed from Under Consideration to Future Release

I'm going to move it to Future Release, and if anyone wants to pick it up for 2.7, we can move it back.

#49 @DJPaul
6 years ago

  • Keywords trac-tidy-2018 added

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
or find us on Slack, in the #buddypress channel:

#50 @DJPaul
6 years ago

  • Milestone Awaiting Contributions deleted
  • Resolution set to maybelater
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.