Starting in BuddyPress 7.0.0, community administrators will be able to assign more than one member type directly from the user’s WP-Admin/Extended profile page.
The regular select box of the Member Type metabox has been replaced by a multiple select box so that you can assign as many member types as you need to a single user.
Be aware of a change we made to the Member Types bulk actions behavior.
Community Administrators can bulk assign a member type to a list of users from the corresponding Administration screen by:
activating the corresponding checkboxes at the left of users avatars.
selecting the Member Type name from the Member Types dropdown list that is located over or under the users table.
clicking on the change button immediately at the right of this dropdown list.
This strictly means you are changing the existing member type(s) of a user to the selected member type. In other words, if the user nicknamed imath was selected, he would be reassigned to the Lead Developer member type only (and lose the Pizza lover one 🍕).
If you choose the “No Member Type” option, then all the assigned member types of the selected user(s) will be removed.
If you want to read about how this change was made and thank the contributors who made it happen, head over this trac ticket.
Since BuddyPress 2.0.0, the primary storage location for the user last_activity information is the activity DB table. For backward compatibility reasons, we used to mirror that data into the usermeta DB table.
This means you could get the last date the user was active on the community site in 2 ways:
The right one using the bp_get_user_last_activity( $user_id ) function.
The deprecated one using bp_get_user_meta( $user_id, 'last_activity', false ) function.
Please note, starting in BuddyPress 7.0.0, we will stop mirroring the last_activity user metadata, meaning the only way to get the last date the user was active is by using bp_get_user_last_activity( $user_id ).
If your development absolutely needs this piece of information to also be available into the usermeta DB table, then you’ll need to use the following filter to keep it there:
First, here’s a clarification regarding the context in which this meeting took place : @im4th thought we were a week before 7.0.0-beta1 release 😆 and urge BuddyPress contributors to review the remaining tickets scheduled for the 7.0.0 milestone! We’re now (October 3rd) 2 weeks away from this beta release 😇.
Due to lack of time, we’ve decided to work on the following features during the 8.0.0 development cycle:
* FYI: the BP Blocks plugin used to develop BP Blocks is also used to develop these two features. You can early play with the Block Based Activity post form and the activity scheduling feature, thanks to this plugin, on a testing site. Contributions are always welcome!
BP Types UI have been included into Core. It’s now possible to manage Group & Member types from the WordPress administration. More information about it here.
The BP REST API now includes a new endpoint to let logged in users to create new blogs (if the network settings allow it). See this GitHub PR.
There will be a new block to embed an activity into a post. During the dev chat we agreed it was important to add 2 more blocks : BP Members & BP Groups blocks. See #8369. (The members one has since been built!)
Some great code improvements has been added by @espellcaste into the BP Blocks plugin. He also suggested we start having regular meetings specific to BuddyPress blocks. So here’s a poll to see if you’re interested about it.
Here are some topics we could discuss about during these specific meetings:
How to attract WP Block developers to have fun with BP ones?
How to smoothly prepare the Block Based Activity post form merge into Core so that BuddyPress Plugins developer can start working on migrating the feature they add to the legacy post form into the block based one?
How BuddyPress could benefit from React, WP React components + BP REST API to improve the user experience?
What about a “Block ready” Template pack or a BuddyPress standalone theme?
7.0.0 release schedule
7.0.0-beta1: October 15 💆🏻
7.0.0 : December 1st
We’ve been discussing about how to improve the way we communicate towards contributors about features/code improvements added to upcoming BuddyPress releases. @im4th suggested to use this blog to post these kind of updates making sure to use the “Development notes” a sub-category of it for the version number. For instance you can quickly read important changes to expect in BuddyPress 7.0.0 from there: Development notes/7.0.
@IAmTheWebb asked us about how he could update some BP Codex pages. Regular contributors we trust like him can ping me @imath on WP Slack or request an access during our Core dev-chats to make this happen! We are very interested into welcoming new Documentation contributors 🙌 🤝.
It will happen on October 7 at 19:00 UTC and of course in #BuddyPress. If you have ideas or questions, feel free (and we are strongly encouraging you) to comment this summary to share them!
Here’s an important information for you: get ready to update a possible template override you’ve added to your active theme. We’ve just fixed an issue to avoid duplicate IDs into the nonce field we generate within the comment form (see #8004 for more information).
You are using the BP Nouveau template pack
Please check if your theme contains an activity/comment-form.php template. If so, make sure the second argument of the bp_nouveau_submit_button() function is bp_get_activity_id().
You are using the BP Legacy template pack
Please check if your theme contains an activity/entry.php template. If so, make sure the second argument of the wp_nonce_field() function is: