BP 2.2-beta1 is now available:…

BP #2.2 Beta 1 is now available: https://buddypress.org/2015/01/buddypress-2-2-beta-1/

It was actually released a few days ago, so apologies for not cross-posting here as well 🙂

Member Type API

BuddyPress 2.2 will introduce the basics of a Member Type API. The primary goal of the API is to provide a common framework for the storage and retrieval of arbitrary member types, a common task on BuddyPress sites. See #6006 for more background.

The new Member Types page on the BP Codex outlines the details of the API, so that developers can get acquainted with the new tools.

In BuddyPress 2.2, BP will provide native support for a number of features beyond the mere fetching/storage of member type data. When BP detects that member types have been registered by a plugin/theme, the following items will be exposed:

• Member queries (bp_has_members() and BP_User_Query) can be filtered by 'member_type'. This allows developers to filter member lists in directories and elsewhere.
• A Member Type metabox will appear on each user’s Community Profile page in Dashboard > Users. Admins can use this metabox to view and change the member type for the current user.

We think that these tools will serve as the foundation for various new features in plugins, themes, and in future versions of BP itself. See, for example, #5192 (show different xprofile fields to different types of members) and #6060 (on Dashboard > Users, display member types and allow filtering by member type). Developers: as you start using this framework, we hope you’ll provide us with feedback and ideas for improving it in future releases.

#2-2, #5192, #6006, #6060, #member-types

About Post Types and BuddyPress Activities

Today, the Blogs component includes a set of functions and hooks to manage the tracking of publicly published posts and comments into the Activity stream.

The Core Team has been working on ways to build a more general solution so that an activity could be generated as soon as a new content is created by any of the registered post types. Most of our interesting discussions about it are available on the #3460 ticket.

3460 is a huge ticket which addresses many aspects of the work required to design this generic solution, such as how to catch the post types, their comments, or provide a management interface etc.

During the 2.1 dev-cycle we’ve decided to split this ticket into smaller tasks and use a more gradual approach.

This update is about the first step of it: ease the implementation of tracking the published post type items into the Activity stream (#5669).

Ease is the keyword, as today you can already add an activity when a content is created by a post type: see examples in this codex page. Plugins can use some hooks and some amount of lines of code to build their tracking feature and there’s a also a popular filter ('bp_blogs_record_post_post_types') people can use to include post types when the Blogs component is active.

In our next major release, BuddyPress 2.2, we are centralizing the majority of the tracking code into the Activity component. A new set of functions and hooks has been created to catch public post types supporting the feature 'buddypress-activity',  to generate an activity when a new item is publicly published and to insert a new option into the Activity dropdown filters used in the Activity Administration screens and in front-end.

This means the Blogs component, when activated, will automatically add the 'buddypress-activity' support to the “post” post type, this also means that any post type can support this feature. To do so, you only need one single line of code!

add_post_type_support( 'book', 'buddypress-activity' );

So using the above line of code will make sure an activity is posted each time an item of the supported post type is published, and will automatically create a new entry into the Activity dropdowns to filter the stream. The created activities will use, by default, very generic strings. If you need more control about the activity attributes, this codex page is explaining the extra code you’ll need to include using the new BuddyPress function bp_activity_set_post_type_tracking_args() or the WordPress function register_post_type().

These improvements have been committed to trunk recently. If you are a developer or an “eager tester”, you can download the trunk version as explained in the “Development” section of the BuddyPress.org download page (make sure to use it on a dev/local/testing environment).

#2-2, #3460, #5669

The way the Group’s manage subnav is generated has been improved

In BuddyPress 2.2, The Group Extension API will use the core function bp_core_new_subnav_item() to generate the sub navigation of the Group’s manage tab. This subnav is populated by core tools to manage the group (such as the details, the photo, the members of the group etc.) and by the Group extension edit_screen() method plugins/themes/customizations are using to build their great manage tools. Here’s an example of this sub navigation.

The Group’s Manage tabs

In most cases, this improvement won’t change anything to your beautiful BuddyPress powered community. But if a plugin/theme/customization is direclty using the hook do_action( 'groups_admin_tabs' ) to insert a new subnav item, a notice will be displayed (when WP_DEBUG mode is on) to invite you to use the Group Extension API instead. Here’s an example of what you could see, having the WP_DEBUG mode on :

You should use the BP Group extension API to generate Manage tabs

As you can see the new subnav will still be generated for back compatibility reasons. If you’re a theme designer, a plugin author, or a customization artist, and you are directly using this hook, we would be very thankful if you could stop doing it in favor of the use of the Group extension API.

If you’re not familiar with this great tool, you can learn more about it in the BuddyPress codex.
If you’re curious and want to read the full story of this enhancement, you can check this ticket #5994.

Thanks in advance for your comprehension and help.

#2-2, #5994, #development

I just wanted to drop…

I just wanted to drop a quick note to mention that in yesterday’s dev chat, we’ve agreed that the BuddyPress #2.2 release cycle will formally start on Oct 25 2014, with the release expected on 28 Jan 2015.

This is gives us more time to explore alternative technical solutions for some of the changes that we’re hoping to include in 2.2. We’re aiming to confirm the major features of the release by around Oct 15 (just about two weeks away).

Another reason for choosing the end of October as a starting point is to coincide with WordCamp San Francisco (WCSF), which some of the BuddyPress team will be attending. Our release cycle often serendipitously syncs up with WCSF; 1.6 was released at 2012’s event, and 1.8 was released about a week before 2013’s event. If you’re also going to WCSF, we’d love to meet you and find out how you’re using BuddyPress. 🙂

More details to come in #2.2 in a couple of weeks, and we’ll be sure to make it clear how new contributors can get involved.