BuddyPress 2.9 will require WordPress 4.4 or greater. See https://buddypress.trac.wordpress.org/ticket/7474 and https://codex.buddypress.org/getting-started/wordpress-version-compatibility/.
The intrepid Hugo Ashmore – better known as @hnla around these parts – will be the official release lead for BuddyPress 2.9. Hugo is a longtime member of the BP community, playing a key role in the forums, on the Codex, on our WP theme companion stylesheets, and generally keeping us honest. Thanks, Hugo!
BP 2.8.2 is now available, and is a security release for all versions: https://buddypress.org/2017/03/buddypress-2-8-2-security-release/
2.8.1 is now available https://buddypress.org/2017/02/buddypress-2-8-1-maintenance-release/
2.8.0 RC1 is now available: https://buddypress.org/2017/02/buddypress-2-8-0-release-candidate-1/
Slack log: https://wordpress.slack.com/archives/buddypress/p1482426116001568 (at the time I’m writing this, there seems to be a Slack bug that’s causing a 30-minute gap in the log)
Present: boone, codeart, chetansatasiya, chiragpatel, rekmla, ckchaudhary, espellcaste, offereins, modemlooper
I started with a couple discussion topics for moving toward our inital
- We decided that xprofile data will be available (and updateable) via the
/members/endpoints. So the
memberschema will have something like an
xprofile_dataproperty, which will be an array of fields and their data. For performance, we’ll explore having a parameter that allows the client to specify the xprofile fields that should be return in a request (or to disable them altogether).
/members/routes will have full CRUD endpoints, even when those endpoints are totally redundant with WP’s corresponding
usersendpoint. This is specifically the case with
- Avatar URLs will be available as part of the default member object. We’d like to explore the ability to create and update avatars via the API, but this will be a parallel project that shouldn’t block the
membersendpoints. (Avatar creation will require some discovery mechanism for clients to determine the proper size/aspect ratio, and will require the client to handle crop/resize, at least in the first implementation.)
codeart and chiragpatel will spend some time over the next few weeks collaborating on a first pass at the endpoint controller and the data schema. Our next meeting will probably be during the first week of January, depending on progress; a time will be announced next week.
We had a productive chat about the BP REST API today.
In attendance: offereins, boone, djpaul, espellcaste, mamaduka, chetansatasiya, shanebp, dimensionmedia, shitalmarakana, modemlooper (fashionably late)
We made some preliminary decisions about strategy and next steps:
- We’ll be starting with the Members endpoints, a rough list of which will be:
- create user
- update user
- delete user
- get user
- get users
This phase will also include support for XProfile data – fetching field data, setting field data, querying by field data – though it’s not yet determined whether these things will happen via separate endpoints or as query params passed to the endpoints described above.
- During the chat, we were leaning toward piggybacking on WP’s
/wp/v2/usersendpoint for BP member queries. modemlooper pointed out after the meeting that WP locks down the
get_items()users query to users with certain permissions levels, and also that security plugins have blocked the endpoint altogether. This pretty strongly suggests that we should go with our own
- We brainstormed a few early ways that we might take advantage of Members endpoints in BuddyPress itself:
- member widget AJAX
- @-mention AJAX
- user search when adding users to group in wp-admin
- I’ve started a Google Doc for sketching out the existing PHP CRUD interfaces for BP content. This’ll be a helpful starting point for understanding the conventions and syntax we should use across the REST API endpoints, as well as to understand how we can come up with a set of endpoints and routes that cover all our content types in a way that is non-redundant. Anyone should feel free to pitch in: https://docs.google.com/document/d/16Wah0MQRS_ktWQSJLGfiAlxHKXORtpo-QaX9JUGxXnA/edit?usp=sharing
- We’ll be continuing to work in the GitHub repository https://github.com/buddypress/bp-rest. Improvements should be sent via PR and peer reviewed before being merged. We’ll give people merge/push permissions after they’ve proved themselves with a couple good PRs.
- We’ll have our next meeting Thursday, December 22 at 1700 UTC. Then we’ll take a break for the holidays, and hold weekly meetings at this time starting in January.