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!
For the 2.8 dev cycle, we’re pleased to announce that three contributors will be joining us as guest committers:
- Slava Abakumov (slaFFik) is the BP 2.8 release lead. He’s a longtime contributor to the BuddyPress project, where’s he’s had an especially notable impact on improving internationalization and extensibility.
- Stephen Edgar (netweb) will be joining the team to focus on build/test tools. He is a member of the bbPress team, and plays an extensive role maintaining build tools for bbPress, BP, and WP.
- Laurens Offereins (Offereins) has been contributing to BuddyPress since 2014. He’s been key in building out the Member Type and Group Type features over the last few releases, bringing a keen eye for spotting nasty bugs.
Congratulations to Slava, Stephen, and Laurens!
BuddyPress 2.7 will introduce a number of major changes to the code that underlies group queries – specifically,
BP_Groups_Group::get(). Most of these changes will be invisible to users and developers, but anyone using filters to modify the underlying SQL may experience backward compatibility breaks in certain cases.
The main motivator for the changes is performance. Over the past few releases, BuddyPress has been following WordPress in moving its object queries to the “split” model, where one query gets the IDs matching the query parameters, and the second query gets the objects corresponding to the matched IDs. Split queries are generally less memory-intensive, and make it easier to phase in various improvements to caching. The changes we’ve made for BP 2.7 should lead to a huge performance improvement on sites using persistent caching; when querying groups, not only are group objects now fetched from the cache when available, but the ID queries themselves are cached as well. See 5451 for more information.
All normal uses of the
bp_has_groups() stack, including
BP_Groups_Group::get(), should be 100% backward compatible. Plugins that use the
bp_groups_get_paged_groups_sql filters may require an update for BP 2.7 compatibility. Filter callbacks will break in the following cases:
- The callback assumes the old comma-separated JOIN syntax:
SELECT ... FROM wp_bp_groups g, wp_bp_groups_groupmeta gm1 .... The SQL now uses the more verbose JOIN syntax:
SELECT ... FROM wp_bp_groups g JOIN wp_bp_groups_groupmeta gm ON ( g.id = gm.group_id ) ...
- The callback assumes
SELECT *instead of
- The callback requires access to the groupmeta tables that were previously joined for ‘last_activity’ and ‘total_member_count’ (
gm2). These tables are now only JOINed during the main query when required by the
orderbyparameter. Access to the
total_member_countproperties of group objects is unchanged.
- The callback expects the second parameter – the
$sqlarray – to have a specific format. Previously, the
$sqlarray had keys that corresponded to various WHERE conditions, but the array was assembled haphazardly, and some values were not included. Now, the top-level items in the
$sqlarray are the main clauses of the SQL query (‘select’, ‘from’, ‘where’, etc) and the WHERE conditions are grouped in the
$sql['where']key. If your plugin filters the SQL string conditionally – for example, when performing a search – you are encouraged to use the third parameter, the
$rarray of arguments passed to the query method, as the canonical source for query information.
In this comment, I outlined a list of plugins from GitHub and wordpress.org that may be affected by the change. If you see your name on that list, consider yourself pinged.
Though it shouldn’t result in any backward compatibility breaks (except in cases of odd type checking), it’s also worth noting that items returned from
BP_Groups_Group::get() are now
Questions about the new query format, or how to make your plugin compatible with BP 2.7? Please leave comments in this thread.