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.
Hey, remember REST API endpoints? Let’s build some for BuddyPress.
We’ll be holding a one-hour discussion to reignite the BP REST API project, at 1900 UTC on Tuesday, December 13, in #buddypress on Making WordPress Slack. A rough agenda for the meeting is as follows:
- What work has already been done on building endpoints? See eg https://github.com/buddypress/BP-REST
- Assuming that we can’t build every endpoint at once, how should we prioritize? Some possible topics for discussion:
- Which component is most representative of BP content, such that we should use it as a blueprint for other component endpoints?
- Do we start with read only, vs read-write? How does the authentication problem affect this question?
- Where can we start using the API in BuddyPress itself? bp-nouveau? The Dashboard?
- What are some other projects that might serve as prototypes for the API in progress?
- What kind of architectural planning needs to happen before we can start building? Things to think about:
- Certain actions, such as the CRUD actions, are common to various BP content types. BP core functions are not always consistent in naming conventions about them (‘insert’ vs ‘create’, etc). Here we have a chance to standardize.
- We should strive for a consistent parameter vocabulary across components. For example, if you pass a
bp_has_groups(), you get a list of groups of which the user is a member. But if you pass a
bp_has_activities(), you get a list of activity items created by the user. What concepts are shared across the components?
- What kind of model for development and integration into BP core should we pursue? How much do we try to develop as a plugin before merging?
- Who’s in? 🙂
This is more than we can solve in a single session, but it should give you some ideas of the questions we ought to think about before we dive into crushing code.
See you next Tuesday!