BP Dev Chat Summary: October 16, 2019

The Dev Chat started 20 minutes late: we’re not completely used to the new meeting time (NB: 18:00 UTC every other wednesday)

“Think”

The BuddyPress Blocks poll

@im4th posted the poll on this site and into a topic of the BuddyPress forums on October 10. After 6 days, the community participation is very week. It’s difficult to figure out what are people expectations. Here are the “top blocks” :

  • A block to share a post or a page via the Activity Stream (14 votes)
  • A block to list the recently published posts from across your network (Exists as a widget) (13 votes)
  • A block to dynamicaly list the recently active, popular, newest, or alphabetical groups (Exists as a widget) (11 votes)
  • A block to display Sitewide Notices posted by the site administrator (Exists as a widget) (11 votes)

The least we can say is there doesn’t seem to be a great enthousiasm for BuddyPress Blocks… As JJJ said maybe “the concept of BuddyPress blocks is not an easy one”.

How can we improve the way users get help?

This is a subject we couldn’t talk about during previous dev chat. There are a lot of topics posted on forums, and a lot are remaining without replies. @johnjamesjacoby thinks and I guess he’s right:

I believe, in general, the more activity there is from BuddyPress maintainers on the site, the more that others are likely to engage with us and each other.

So the first thing we can do is to try to contribute ourselves to forum replies as much as we can. Then here are the other ideas we had :

  • A styling refresh of the homepage and forums area.
  • Add some self care content. Eg: the replies to common issues users may encounter when starting with BuddyPress.
  • Moving the “bpdevel site” (this site) to a new make.BuddyPress.org site might help to bring some new contributors to forums. (@im4th announced he will soon share the work he has been doing about this project).

Let’s organize a BuddySesh!

To follow up the nice discussion @im4th had with David Bisset (@dimensionmedia) we’ve been briefly talking about this possible way of gathering BuddyPress contributors from all around the world for a day of conferences / chats. We’ll come back on the subject with David once the WordCamp US is behind us as he’s pretty busy contributing to its Programming team.

“Do”

BuddyPress Beta Tester plugin (& 5.1.0 minor release)

The GitHub repository for the BuddyPress Beta Tester plugin has been published. According to @im4th‘s tests, it’s working fine. To test it with a real Beta Version, @im4th suggested to soon package a 5.1.0-beta. We’ll need to publish it on the WordPress.org official directory once we feel it’s ready.

BP REST API

@espellcaste made great progress about the remaining endpoints of the BP REST API. There are now 3 more endpoints available for testing using the BP REST API Plugin :

BuddyPress Survey for 2019

@im4th suggested to carry on doing the survey @mercime used to do every year for a while now. The last one was done at the end of 2017 for 2018.

Next dev-chat

It will happen on October 30 at 18:00 UTC in #BuddyPress. Friendly reminder that we moved our dev-chat time to one hour earlier, 🙏 don’t miss it!

PS: if you have ideas or questions, feel free (and we are strongly encouraging you) to comment this summary to share them!

#5-0-0, #6-0-0

BP Dev Chat Summary: October 2, 2019

5.0.0 development cycle report

BuddyPress 5.0.0 was released on September 30, 2 days before this dev-chat happened.

First feedbacks

@boonebgorges was the first to share his feedback about this release. He congratulated the “5.0 team” for their amazing contributions.

@im4th sent new props to all 5.0 contributors and informed about the first results of the release in terms of downloads. The spike was reached on October 1st with 23562 downloads (~1K less than the one we had for 4.4.0). At the time of the dev-chat, no support topics were posted about issues relative to the 5.0.0 upgrade.

We unfortunately had an issue with po/mo language packs generation. Thankfully, the Meta Team fixed it very quickly and we updated our release process to make sure it won’t happen again.

What have we done well?

For @espellcaste we kept our development meetings (dev-chat) consistent (every two weeks). He also think publishing development notes during the development cycle and before the release was a good practice.

@im4th thinks having the BP REST API documentation ready before the release was a great team achievement. Developing the BP REST API from GitHub was also a great way to save some time (especially when rebasing!)

What can we improve?

We all noticed testing involvement was very low during 5.0.0 beta tests. We’ve tried to understand the reasons behind this fact:

  • lack of interest?
  • lack of time?
  • lack of visibility of our communication?
  • total confidence in our work?

It’s important we try to reach and get the involvement of early adopters, advanced users, plugin and theme developers during BuddyPress major release beta tests.

@im4th then asked if the frequency and the schedule time of meetings were suitable for all. The “every other Wednesday” seems to be fine with everyone but moving the schedule time to one hour earlier seems better.

What’s next in BuddyPress?

6.0.0 priorities

The first priority is to complete the BP REST API with the remaining endpoints (#7156).

About the Gutenberg project and to follow up with a previous conversation we had about it. We need to have a better idea about BuddyPress users needs on the BuddyPress Blocks (#8048) topic: that’s why we’ll share a poll with them. @dcavins thinks the obvious first step is to have a block version of our existing widgets: we all agreed. About the poll, as @boonebgorges pointed out we might have a very limited participation to it, so we will have to analyze the results very carefully. He also pointed out the poll was to consider as one input like any other. @im4th will work on a text about it in order to be able to explain and share the poll on this blog and on one BuddyPress forums topic.

@im4th thinks that more than blocks BuddyPress users are expecting a “BuddyPress maintained” component to manage User Media (#8022). He plans to revamp the BP Attachments plugin he started a while ago to try to have something ready for 6.0.0.

@im4th is also planning to work on migrating the way BuddyPress builds URL to use the WP Rewrites API (#4954). He thinks that as it’s a breaking change, we need to build it so that it can be “tested & deactivated” for a while.

@dcavins will take benefit of the new BP Invitations API to work on Network invitations and membership requests (#8139). He renew his wish to get our feedbacks about the road he plans to take.

After the dev-chat @im4th & @johnjamesjacoby also talked about including the BerlinDB features into BuddyPress.

How can we have more betatesters?

@im4th shared his ideas about this potential improvement we all agreed on during our 5.0.0 cycle development report:

  • A beta tester plugin just like the WordPress one, but for BuddyPress.
  • Migrate this blog into the BuddyPress.org network (#5525) and extend it to include a handbook about contributing to BuddyPress.

How can we improve the way users get help?

Unfortunately we ran short of time and decided to talk about this point during our next dev-chat.

Next dev-chat

It will happen on October 16 at 18:00 UTC in #BuddyPress. We moved our dev-chat time to one hour earlier, don’t miss it!

PS: if you have ideas or questions, feel free (and we are strongly encouraging you) to comment this summary to share them!

#5-0-0, #6-0-0

BP Dev Chat Summary, September 4

5.0.0’s schedule

  1. Second beta release: September 10.
  2. First release candidate: ~ September 16.
  3. 5.0.0 release: ~ September 30.

Issues & Feedbacks about the first beta release

Some i18n issues appeared into the BP REST API code and have since been fixed by @espellcaste. @im4th will improve the bp.apiRequest JavaScript function before beta2 (#8131).

IAmTheWebb reported that he hasn’t noticed any regression issues but also informed us he hasn’t found the time to test the new features yet. The lack of ticket report is a bit worrying as it makes us wonder if the beta1 has actually been tested by BuddyPress plugin or theme developers 🤔.

@boonebgorges explained it wasn’t easy to test the BP REST API as it required building clients. Having the BP REST API documentation site available would probably help.

The BP REST API documentation site

@johnjamesjacoby & @netweb have been working on the developer.wordpress.org needed set-up to host the BP REST API documentation site. Although we are very confident they will soon fix #4601-meta, we decided to wait until September 20 before applying our backup plan.

In case we can’t make it on developer.wordpress.org @im4th will buy a specific domain name for the staging site we used to write the documentation and we’ll make this site widely available.

BuddyPress plugin & theme developers will be able to consult The BP REST API documentation before the 5.0.0 release 💯.

Hello BuddyPress modal

BuddyPress 3.0.0 introduced this modal to replace the Welcome Screen. We use it to inform about the new features introduced in the new major releases of BuddyPress.

@im4th shared a patch on #8132 to make this modal more inline with the WordPress Administration styles. @johnjamesjacoby shared his thoughts about it on the ticket and agreed during dev-chat that matching core’s modal would be best.

@im4th is 🇫🇷 so there are probably some english mistakes in the text parts of the patch. BuddyPress contributors : don’t hesitate to find and fix them 🙏

5.0.0-beta2

We decided to package a second beta next week to remind our contributors we need their help to test our contributions. Let’s not wait for the stable release to find bugs we could have avoided during the beta period!

Next dev-chat

It will happen on September 18th at 19:00 UTC in #BuddyPress slack channel, just before the release candidate.

PS: @dcavins couldn’t attend to the dev-chat but recently shared in our Slack channel he will soon publish an overview about the changes introduced by the BP Invitations API 👌.

#5-0-0

BP Dev Chat Summary, August 21

5.0.0’s schedule

Here are three important dates about our next major version:

  1. First beta release: August 28.
  2. First release candidate: ~ September 16.
  3. 5.0.0 release: ~ September 30.

BP Invitations API

@dcavins has committed this new API to manage Invitations/Membership Requests across components. The first BP Component to enjoy it is naturally the Groups one. Many thanks and huge congratulations for the accomplished work 👏🤝. See #6210 for more details about it.

BP REST API

Code improvements

  • He also adapted the Group Invites and the Group Membership Requests endpoints so that they are now using the BP Invitations API.
  • The create_item() method of the Group Membership controller is now taking in charge the action to let members join a public group.
  • WP_REST_Server::DELETABLE methods are now all returning an object with two keys. The first one informs about the success of the DELETE request and the second one contains the previous BP object as it existed before its deletion.

Documentation

The content is almost ready! Documenting the Group Invites and the Group Membership Requests endpoints (the last ones) will be achieved before the beta release.

Making it available from BuddyPress.org is in very good hands @johnjamesjacoby will work on it asap to try to have it ready around beta release so that it should be easier for contributors to play with the BP REST API during our Beta/RC release steps.

How the BP REST API will be included into BuddyPress Core for this beta release?

To keep working from our BP REST GitHub repository to fix potential bugs / improvements, we will include it during our build process a bit like what happens today with BP CLI: see this comment on #7156 for more details.

This means:

  • the BP REST API plugin, if active, will take over BuddyPress, making it easier to carry on maintaining it from GitHub during the Beta/RC time.
  • If contributors are using trunk to beta test, they’ll need to npm install & grunt build to get the BP REST API into this build.

5.0.0 milestone’s remaining tickets

  • #8046 & 8093 have been moved to next release.
  • #8103 (BP Legacy Companion Stylesheet for Twenty Nineteen) is kept during the beta/RC to leave a last opportunity to include it before final release if it gets some contributions/testing.
  • #8123 will be committed asap & before beta release.

Beta Release tasks

  • @im4th will take in charge the beta release packaging
  • @dcavins will try to post on this blog to introduce the BP Invitations API
  • We still need to write the announcement post for BuddyPress.org. A draft for it is available on BuddyPress.org (the title is BuddyPress 5.0.0-beta1), don’t hesitate to add the information you think are important to mention. I’ll polish the writing part 🖼 📝

Next dev-chat

It will happen on September 4th at 19:00 UTC in #BuddyPress slack channel. Of course is something goes wrong with right after the beta release, we’ll always be able to meet next week.

#5-0-0

BP Dev Chat Summary: July 24, 2019

Feedbacks about 4.4.0 Security & Maintenance release

4.4.0 has been released on July 23rd and has been downloaded more than 30,000 times since then. No specific feedbacks were posted on our support forums about it. We’ll keep an eye on how it evolves in the coming days but it looks like it went smoothly.

BP REST API

Documentation site

@johnjamesjacoby is assigned to the Meta Trac ticket which goal is to prepare existing developer.buddypress.org to house the BP REST API documentation.

@espellcaste shared his worries about the time remaining until 5.0.0 release. I think it’s still doable and if we’re short, we will be able to use our « test drive » as a fallback. We’ll only have to buy a domain name more meaningful.

As discussed during the previous dev-chat, I’ve started writing the documentation into the « WordPress Handbook » format copy-pasting parts of the Restsplain generated documentation. Here’s a first page for the Components endpoint.

The interesting benefit about doing so is the fact it’s a good way to review the BP REST API. If members of the team want to participate to this effort, they just need to ping @im4th to get admin access to the site.

Code improvements

To illustrate the benefit described in the above paragraph, I’ve (I am @im4th 😁) shared this pull request (#196) about improving the consistency of the Component’s endpoint PUT method arguments description/documentation. @espellcaste will look into it and check the other endpoints about the subject.

@espellcaste also worked on adding hooks to the prepare_links() methods when needed and to items collection query parameters. He will also look into this issue to try to understand why a notice error is thrown when removing the avatar original file.

Finally, although @dcavins couldn’t attend our dev-chat, he’s been hardly working on adapting the BP REST API (197) to go along with the new Invitation API (#6210) he’s been building for BuddyPress. I will look into it more deeply asap. My very first feedback would be to rebase the pull request as there is one merge conflict (probably due to the hooks recently added by @espellcaste)

5.0.0 milestone’s tickets

At the end of the previous topic, @im4th informed he would probably open a new ticket to improve the bp.apiRequest : the dataType argument should default to json, doing so it will save some time to plugin developers using it in the future as REST replies are in JSON.

We did a quick review of the “new” tickets having patches, in particular @boonebgorges and @im4th talked about #8013 to decide about the name of the additional key to use for the exporter item names displayed to regular users. @im4th agreed with @boonebgorges it was best to bp prefix the name.

@espellcaste decided to move #7018 to next release to concentrate on the last BP REST API tasks.

About the list of patches I mentioned into the July 10th’s dev-chat summary. I’ve decided to commit the three crossed out ones (the first 3, if you prefer) below and leave some more time to the BP Legacy Twenty Nineteen companion stylesheet.

About this last ticket, it would be great to have some feedbacks about it as I’m unsure I made the right CSS decisions about it.

BuddyPress & the Gutenberg project

As requested by @espellcaste into this comment of the dev-chat agenda we kept some time to discuss about this topic or more precisely about the first ideas we have to benefit from the Gutenberg project (Phase 1 – editor & Phase 2 – widgets).

The first very important thing @im4th wanted to highlight is:

BuddyPress Blocks will be easier to create by us or plugin developers thanks to the BP REST API: I think it’s a very important point, because the Gutenberg project mainly use REST.

I’ve been thinking about this since the dev-chat and I think we really need to have this ticket fixed for 5.0.0 release : #8116 BP Blocks category.

Then we had difficulties to understand each others and I think that’s because the Block Editor is often called Gutenberg 😇.

Theme Compat API “vs” Block API

@boonebgorges shared very important points comparing the Block API to our Theme compatibility API.

Gutenberg does something similar to what our theme compat does. It provides a way to place dynamic content in the “content” area of a theme template.

Retrospectively, I would add that the Gutenberg team is working on a “JSON templating” feature, but I’m unsure it will be overridable : I think “overridability” is a great feature of our Theme Compat API.

What does the BuddyPress community want/need ?

@espellcaste think it’s important we get our community members expectations about this topic.

another thing I think would be important is to see what the community want… try to get the info somehow…. specially from bp theme authors…

A lot of things could be improved but that doesn’t mean it will have the most impact…

I think he’s 100% right, so instead of dropping the ideas we talked about during the dev-chat, I guess we need to organize them a little and let you give us your opinions about it. It would help us a lot to decide what will be our next steps into this area. So stay tuned! We’ll soon be back to you 🤗.

Next dev-chat

It will happen on August 7th at 19:00 UTC in #BuddyPress slack channel. We will have 1 week left before 5.0.0 first beta so let’s get our last tasks done during the next 2 weeks 💪.

#4-4-0, #5-0-0

BP Dev Chat Summary: July 10, 2019

BP REST API focus

REST fields (~= BuddyPress Components metadata)

PRs #189, #193, & #194 have been merged into the BP REST API by @espellcaste : they brought these REST fields for the Activity, Groups, Members, Messages, Notifications, and xProfile (field/group/data) endpoints.

If you are a BuddyPress plugin developer, here’s how you can use this feature to create/update and get your custom REST Fields.

// Registers a REST field for the Activity Endpoints.
function example_register_activity_rest_field() {
	bp_rest_register_field(
		'activity',      // Id of the BuddyPress component the REST field is about
		'example_field', // Used into the REST response/request
		array(
			'get_callback'    => 'example_get_rest_field_callback',    // The function to use to get the value of the REST Field
			'update_callback' => 'example_update_rest_field_callback', // The function to use to update the value of the REST Field
			'schema'          => array(                                // The example_field REST schema.
				'description' => 'Example of Activity Meta Field',
				'type'        => 'string',
				'context'     => array( 'view', 'edit' ),
			),
		)
	);
}
add_action( 'bp_rest_api_init', 'example_register_activity_rest_field' );

/**
 * The function to use to get the value of the REST Field.
 *
 * @param  array  $array     The list of properties of the BuddyPress component's object.
 * @param  string $attribute The REST Field key used into the REST response.
 * @return string            The value of the REST Field to include into the REST response.
 */
function example_get_rest_field_callback( $array, $attribute ) {
	// The key of the metadata can be different from the REST Field key.
	$metadata_key = '_example_metadata_key';
	
	return bp_activity_get_meta( $array['id'], $metadata_key );
}

/**
 * The function to use to update the value of the REST Field.
 *
 * @param  object $object    The BuddyPress component's object that was just created/updated during the request.
 *                           (in this case the BP_Activity_Activity object).
 * @return string $value     The value of the REST Field to save.
 * @param  string $attribute The REST Field key used into the REST response.
 */
function example_update_rest_field_callback( $object, $value, $attribute ) {
	// The key of the metadata can be different from the REST Field key.
	$metadata_key = '_example_metadata_key';
	
	bp_activity_update_meta( $object->id, $metadata_key, $value );
}

View the code on Gist.GitHub.com

REST links

The Message endpoint got its filterable links (See the prepare_links() method of its endpoint).

@espellcaste and I are agreeing the other components should also include a filter to let plugin developers eventually add custom links. #Needs-PR 😉

Documentation site about the BP REST API

We’ve discussed about the post where I suggest possible roads for a while with @espellcaste. In particular, I’ve shared my 2 concerns about the Restsplain plugin generated documentation :

  • I think we should use it to write a more “human understandable” documentation. For instance, use “Create an activity” instead of POST
  • It would be better to use our bp.apiRequest function in code examples instead of the fetch() one.

NB: After the Dev Chat, @johnjamesjacoby advised to keep docs and support on BuddyPress.org to avoid fragmentation, and to maintain user trust. I agreed it was best and opened a ticket on the Meta Trac (See #4601) to move forward.

Updates about the Tickets into the 5.0.0 milestone

It would be great to have the patches attached to the following list of tickets tested during the next 2 weeks:

Next dev-chat

It will happen on July 24th at 19:00 UTC in #BuddyPress slack channel. In the meantime: have fun contributing to BuddyPress 👩🏻‍💻, we have 1 month left before 5.0.0 first beta 🗓

#5-0

BP Dev-Chat Summary (June 12)

BP REST API

A huge work has been accomplished by @espellcaste 💪 so far from the feature as a plugin “BP REST” and we think the 5.0.0 release will be a good time to bring the REST API within BuddyPress core. As explained in #7156 it will introduce 14 BuddyPress endpoints and you’ll soon be able to play with activity updates, groups, members, private messages and extended profile fields using REST requests 🙌

8 other endpoints (eg: blogs, friends) will arrive in 6.0.0.

BP REST Documentation

As @boonebgorges said during the chat, this part is very important for us to help you build great BuddyPress plugins thanks to this new API. We’ve been looking for a nice tool to generate this documentation out of the endpoints schemas and we think we’ve found a good solution to start. We now have to put up a website to host this documentation. I’ll take care of sketching out the next steps of this site and @boonebgorges will be able to help for the domain name.

Let’s start using the API within BuddyPress core!

The best way to help you discover the BP REST API potential is to use it ourselves 😉. We plan to do so by improving how Group members are managed within the Group Manage screen (front-end) and the Group Admin screen (back-end). Below is a video demo to let you discover a bit early how it should look like on the front-end of your community site.

You can follow our progress from the #8045 ticket.

How to include the BP REST API into the BuddyPress plugin package?

We’ve been discussing about it for about 30 mins during the chat and we haven’t decided yet how this will happen. We have 2 options:

  • Carry on maintaining it from GitHub.com and include it during the BuddyPress plugin’s build process (that’s what we’re doing for BP Default & BP CLI)
  • Merge it into BuddyPress Core.

There are “pros” and “cons” for both options. For example, maintaining it from GitHub can be confusing for contributors because it adds a second place to report for this part of BuddyPress as @boonebgorges noted. It’s also problematic regarding the history of how the decisions were made: it would be “tied up in two places“. @espellcaste also expressed his preference, despite the fact working in GitHub is more convenient, about keeping things “in house” (we have less control about the future of GitHub). Finally @boonebgorges also explained we could keep it on GitHub for a couple of releases before bringing it home as “once we go Trac, we cannot go Back“.

Another relative point on this subjet: how plugins should behave if they are both activated?

  • Should the plugin BP REST take over BuddyPress ? Meaning all endpoints can be maintained from the GitHub repository.
  • Should it be BuddyPress? Meaning the BP REST plugin would only be used to develop the 8 remaining endpoints.

We agreed we still have time until the first beta release to decide, but if you have ideas or recommandations : please share them in comments 😊

About the 5.0.0 release schedule

We agreed on a first date : 5.0.0-beta1 will be released around August 15.

As discussed during the chat, it will give us the time to work on the documentation site and decide about the « BP REST API including » strategy.

It should also give us the time to clear the tickets list of the milestone, there are around 10 tickets left and you are very welcome to give us a hand testing or suggesting patches.

Until Beta1 we will have a dev chat every other Wednesday at 19:00 UTC in #BuddyPress. Here is the planning of our next meetings:

If you are going to Berlin to attend to the WCEU 2019: have fun, make good connections and learn great things! @johnjamesjacoby will be there, don’t hesitate to enjoy his conference 👌 and chat with him about BuddyPress 😍

You can also decide to give a hand to BuddyPress during this WordCamp thanks to the contributing area! We’ll be very happy to help from where we are 😁

#5-0