BP Dev Chat Summary: August 7, 2019

5.0.0’s schedule

At the end of our discussions, considering the work we still have to achieve to feel satisfied about ourselves, we’ve decided to postpone the first beta release to the last week of August. Our new targeted date for 5.0.0-beta 1 is August 28. Thanks for everyone’s comprehension 🙏

BP REST API focus

NB: we didn’t have enough time to decide about “how to include the BP REST API into BuddyPress Core“. We will do it during our next dev chat. In the meantime, you’re welcome to contribute to #7156.

Documentation

We’re making great progress on this topic. More than 50% of our endpoints are now documented. @im4th shared the link of the testing site we use waiting for #4601 to be fixed (@im4th and @espellcaste are 🤞).

Writing this documentation is also very helpful to improve the API code: 10 pull requests were generated and merged so far.

@im4th is 💯 confident all the endpoints introduced into version 5.0.0 of BuddyPress will be documented before its public release.

Code improvements

In addition to these PRs @dcavins has been working hard on adapting the Group Invites and the Group Request Membership endpoints to the new BP Invitations API. @espellcaste & @im4th ‘s reviews of his patches led to 2 important conversations during the dev chat.

What endpoint should handle the action “a user joins a group”?

While @boonebgorges intuitively expects a POST request to the Group Membership endpoint to succeed if the group is public, I was wondering if “joining a public group” could be interpreted as “requesting an already accepted membership request” and as such use the Group Request Membership endpoint instead. @dcavins informed the second option would generate a consistency issue as the response object wouldn’t fit with “joining a public group“. We decided to use the first option (See PR209).

How should we build the response object to the WP_REST_Server::DELETABLE methods?

So far we were returning the object as it existed before its deletion for all endpoints excepting for the Members endpoint. The Members controller is actually extending the WordPress Users one : so we decided to follow WordPress way of building the response object in this case. See PR210.

BP Invitations API

See #6210 for more details about the API. @im4th & @dcavins are confident about committing the changes into BuddyPress Core to make the API available to everyone for 5.0.0 🙌. A Back compatibility mechanism is in place and our testing did great. The soonest the patch will be converted, the best it will be to finish the needed adaptations of the BP REST API (See PR206). @dcavins will work asap 💪 on the committing task, making sure to split the patch into small & consistent chunks.

5.0.0 milestone’s tickets

As we were already playing overtimes for 30 minutes for this dev chat, we will decide about whether to move the remaining tickets to a next/future release or not during our next dev chat.

If you have CSS skills, you are very welcome to contribute on #8103. If you’re not familiar with working with Trac patches, we’ve put together this Twenty Nineteen child theme to make things easier for you.

Next dev-chat

It will happen on August 21th at 19:00 UTC in #BuddyPress slack channel. As @im4th said at the end of this dev-chat:

Let’s meet again in 2 weeks with everything ready for a beta release the week after 💪 🙌

#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 26)

Updates about the Tickets into the 5.0.0 milestone

#8045 is achieved: we now have our very first core feature using the BP REST API. If you chose to use BP Nouveau as your template pack (it is the default template pack for new installs), your group administrators will enjoy a brand new interface to manage the members of their group(s).

The interface is more dynamic than our legacy one and Administrators of popular groups will probably love the search feature! Finding the specific member they want to promote, demote, ban or remove is faster than ever!

#6210 @dcavins is working on a new version of the patch to adapt it to play nicer with BP Nouveau & see how things will evolve with the BP REST API. He worked very hard 💪 🏋🏻‍♂️ so far and I believe he’s very close to achieve his goal. I think it’s a very promising feature that will first improve how we handle group invitations and soon give new opportunities for other objects such as sites of a network. I also think it’s an interesting way to test & review the group invites & requests BP REST API endpoints.

There are 7 tickets with patches. Feel free to help us: testing patches and confirming they do the job is a already a great help. If you can improve them: it’s even greater! If you don’t know where to start, read this comment about how to test BuddyPress patches.

#7156 is the master ticket for the BP REST API. @im4th (me 😄) has suggested a patch to include the BP REST API into the BuddyPress’ build process. It’s a first reply to the question we haven’t replied yet since our previous dev-chat: « How to include the BP REST API into the BuddyPress plugin package? ». Feedbacks are very welcome.

BP REST API focus

REST fields (~= BuddyPress Components metadata)

We still have work on this “field” 😅 I’ve submitted a pull request that is implementing them for a bunch of endpoints. @espellcaste: please have a look at it soon and commit if you feel like me & @boonebgorges the approach is good.

The xProfile REST fields will need an extra work as the meta table is a bit different: we can attach a meta to a data, a field or a group of fields. I’ve posted an issue about it with a suggestion to handle this specific case. I’ll update it with a new pull request to adapt the one I was talking about into the previous paragraph.

The current endpoint about Threads/Private messages is more sensitive imho. REST fiels are messages metadata not threads ones. FYI, I’ve been also exploring how to use the BP REST API into the BP Nouveau Messages UI. I think I will carry on because it’s a nice way to eventually improve it.

REST links

I think we need to harmonise their use, for instance in BP REST Activity, BP REST Groups, BP REST Members, the links should all include a filter to let plugins add custom ones if needed. There should be links for the Private Message object to transport the “star” link, and probably the links of the users involved into the message…

Documentation site about the BP REST API

Last but not least! Feedbacks are very welcome about the post I’ve published to share my suggestions.

Next dev-chat

It will happen on July 10th at 19:00 UTC in #BuddyPress slack channel. In the meantime: have fun contributing to BuddyPress 👍

#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

Real-world testing of BuddyPress WP-CLI commands

A few years ago, I started a wp-cli-buddypress project. I occasionally added commands that were useful to me personally, but didn’t pretend to have anything close to complete coverage. A few months ago, Renato Alves (@espellcaste) contacted me to see whether he could help flesh out some of the missing commands. We moved the repo to the official BuddyPress GitHub account https://github.com/buddypress/wp-cli-buddypress, opened a BP ticket to track the potential integration of the commands into BP itself https://buddypress.trac.wordpress.org/ticket/7604, and got to work.

Since that time, Renato and I have done extensive work to bring basic CLI commands to all the main components of BuddyPress. Specifically, we have CRUD commands for all major content types, as well as a few helpful utility methods. The list of supported commands is too long to list here – you can explore by typing <code>wp bp</code> and digging down through the tree – but here’s a very brief summary:

  • activity – CRUD commands, comment management, favorite management, spam/unspam
  • core – Component activation and deactivation
  • group – CRUD commands, member listing and management, invitation management
  • member – bulk generation
  • signup – CRUD commands, activation, resending
  • tool – commands for running any BP repair tool
  • xprofile – CRUD commands for groups, fields, and user data

While there’s more to build – and refinements to be made – we’re at a point where we need real-world testing and feedback. If you are a BP developer, or administer BP-powered sites, and if you use WP-CLI, please install wp-cli-buddypress today and start using it.

There are numerous ways to install a wp-cli package, but because this one is in development, we encourage you to get a repo checkout. Something like:

$ git clone https://github.com/buddypress/wp-cli-buddypress ~/.wp-cli/commands

and then add the path to wp-cli-buddypress/wp-cli-bp.php to the commands subsection of your wp-cli config file https://make.wordpress.org/cli/handbook/config/#config-files.

Questions to consider while using the commands:

  • Are the commands named in a way that makes sense? Note that in some cases, commands have aliases (eg wp bp group create and wp bp group add).
  • Think about argument patterns across the commands, and whether they are consistent and make sense. Some commands take certain positional arguments (wp bp group get my-group) while others require named arguments (wp bp xprofile data get --user-id=5 --field-id=10)
  • What major features are missing?

For specific issues, you’re encouraged to open a GitHub ticket: https://github.com/buddypress/wp-cli-buddypress/issues. For high-level discussions, you can open a GitHub ticket, leave a comment here, or drop into the #buddypress channel on wordpress.org Slack.

And for the truly intrepid: Contributions are encouraged! We’ve worked hard to ensure 100% Behat test coverage, which makes writing new commands fun.

#wp-cli