BuddyPress 2.8.0 Beta 1 is now available!

It’s shipped and ready for testing! Details in a blog post:

https://buddypress.org/2017/01/buddypress-2-8-0-beta-1/

Dev Chat Summaries for December 21 & 28, 2016

BP 2.8 Trac Tickets

BP 2.8 – Prevent loading if PHP < 5.3 (#7277) @boonebgorges has patch. Dev feedback requested (esp. @johnjamesjacoby & @djpaulgibbs).

Removal of `create_function` usage for BP 2.8 (#7325) @tw2113 has patches.

Anonymize BP Core Dependency functions file. (#7335) Closed as wontfix.

`groups_promote_member()` shouldn’t attempt to fetch ⁠⁠⁠⁠BP_Core_User⁠⁠⁠⁠ object (#7382) Patch needs unit tests. Assigned to @boonebgorges.

Add a “buddypress” class to body element of wp-admin (#7353) @slaffik has committed fix to trunk.

Component Maintainers

@slaffik will be contacting everyone who volunteered to maintain BP components in Trac.

@dcavins would like notifications from Trac for new tickets under the Group components. He mentioned different workarounds like getting Slack notifications for the Groups component to getting the RSS feed from Trac for the specific component. @johnjamesjacoby: “We’d need to merge into our Trac what’s already in WordPress Trac. That’s probably Dion and/or Nacin.” @netweb noted after the chat that there’s a ticket in Meta Trac to get this underway.

🥂 Wishing Everyone a Happy & Prosperous New Year! 🥂

Slack logs:
Dec. 21 https://wordpress.slack.com/archives/buddypress/p1482350517001398
Dec. 28 https://wordpress.slack.com/archives/buddypress/p1482955219002247

#7277, #7325, #7335, #7353, #7382

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.

Dev Chat Summary for December 14, 2016

BuddyPress 2.7.4

  • Release Date: TBA
  • There are currently 2 tickets in queue (1 open, 1 closed).
  • Can ‘change’ visibility on registration form even for fields marked “Enforce field visibility” (#7391) Ticket has been reopened to address coding standards.
  • Notice: Trying to get property of non-object (#7329) Has patch. Requested dev feedback from @rayisme
  • @djpaulgibbs: We are incompatible with PHP 7.1 as things stand – and I think we may have to rely on a fix in WordPress 4.7.x as well – so that’s the sort of thing that will likely go out once it’s ready.

BuddyPress 2.8 Tickets

Some more enhancement for translators (#5784) @slaffik recommended to close the ticket.

PHP Fatal error: Uncaught Error: Call to a member function get_do_autolink() on null (#7337) @slaffik has patch. @djpaulgibbs noted that patch should extend beyond preventing fatal errors to making the function usable outside the template loop.

Uninstall button and routine (#2755) This ticket would have to be put on hold until decisions are made on routines and details required to export/copy then delete/drop BP DB tables and other options.

Slack log: https://wordpress.slack.com/archives/buddypress/p1481745673000991

#2755, #5784, #7329, #7337, #7391, #dev-chat

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.

Dev Chat Summary for December 7, 2016

BuddyPress 2.7.3

BuddyPress 2.8.0

  • There are currently 89 tickets slated for this dev cycle (26 closed, 63 open).
  • January 4, 2017 – Beta 1
  • January 18, 2017 – Release Candidate 1 (string freeze)
  • January 25, 2017 – Target release date

BuddyPress 2016 Survey

  • The 2016 Survey will be closing this Thursday, Dec. 15. Thanks for your participation 🙂

Slack log: https://wordpress.slack.com/archives/buddypress/p1481140823000207

Companion Styles: twentyseventeen

Companion stylesheets to support the latest WP twentyseventeen theme is now committed to BP core and will be included in the 2.8 release.

While further iterations are forthcoming shortly to address some design concerns feedback would be helpful especially browser /device testing.

Any issues spotted can be notified on this ticket:

https://buddypress.trac.wordpress.org/ticket/7338

Your comments and testing are appreciated 🙂

~hnla.

#companion-styles, #stylesheets, #theme