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

#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

Nouveau Template Chat

At slightly short notice (although briefly mentioned last week on slack) I’m resuming the template chats for Thursdays @ 20:00 utc ( or earlier if it suits more people? )

As today is at short notice the chat is a more informal one to get the ball rolling again and I hope anyone that is interested will check in and lend a voice.

We’ll keep to a short meeting of 30 mins – depending on how things go this might roll on longer.

As the Nouveau project is in a fairly complete state vis a vis templates, styles, majority of the directory structure, functions/classes etc this is the opportune moment to discuss the areas that will dictate how the template pack is managed and executed in BP core and these areas to some extent dictate how work on the project in general moves forward.

The discussion points are therefore:

  1. Agreement or otherwise that template packs or templates are run in the core bp-templates folder.
  2. If running from core do we want to implement the template switching process? See ‘UI to Pick Template Packs‘ Trac ticket & to be considered in this point is that imath has effected a very effective solution here currently in use if running Nouveau as a plugin
  3. If we do run multiple templates – what if any are the implications of supporting these multiple packs in terms of time updating them if required?
  4. In terms of styles I’ve followed a ‘partials’ approach to breaking the various components into smaller file includes compiled into the main .scss sheet, the principle notion here was that those ‘ _partials’ are maintained in <code>/src/bp-templates/shared/styles/</code> and can be used as a base set for any new set of templates (obviously not being compiled into the ‘build’ for final releases). Although I have kept things flexible so we have options I think this best approach so would seek consensus &/or opinion here.

There is a fair bit to discuss just in the points above, ideally we seek consensus on these points so we can move forward but am  not expecting we can achieve this in one chat session but making a start is the important thing.

Hope to see as many there as possible.

~hnla

P.S. Please feel free to leave any comments about the points above or any other thoughts on the Nouveau templates project.

P.P.S. The template pack is available here on the BuddyPress github account ‘Next Template Packs

#template-packs

Dev Chat Summary for November 30, 2016

BuddyPress 2.7.3

BuddyPress 2.8.0

  • There are currently 83 tickets in queue ( 69 open, 14 closed).
  • January 4, 2017 – Beta 1
  • January 18, 2017 – Release Candidate 1 (string freeze)
  • January 25, 2017 – Target release date

BuddyPress 2016 Survey Extended

The survey period has been extended to December 15, 2016. https://buddypress.org/2016/11/2016-buddypress-survey-site-builders-developers/ Thanks for your participation.

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

#dev-chat

REST API (re)kickoff meeting: Tuesday, December 13

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 user_id parameter to bp_has_groups(), you get a list of groups of which the user is a member. But if you pass a user_id parameter to 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!