BuddyPress 2.9 will require WordPress…

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

hnla and BP 2.9

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 security release

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/

BP 2.8.1

2.8.1 is now available https://buddypress.org/2017/02/buddypress-2-8-1-maintenance-release/

BP 2.8.0 RC1

2.8.0 RC1 is now available: https://buddypress.org/2017/02/buddypress-2-8-0-release-candidate-1/

#2-8, #rc

REST API chat summary – December 22, 2016

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 members endpoints:

  1. We decided that xprofile data will be available (and updateable) via the /members/ endpoints. So the member schema will have something like an xprofile_data property, 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).
  2. The /members/ routes will have full CRUD endpoints, even when those endpoints are totally redundant with WP’s corresponding users endpoint. This is specifically the case with DELETE.
  3. 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 members endpoints. (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.

REST API chat summary – December 13, 2016

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:

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

  2. During the chat, we were leaning toward piggybacking on WP’s /wp/v2/users endpoint 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 /bp/v1/members endpoint.
  3. 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
  4. 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
  5. 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.
  6. 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.