Hi !
Weโve just published the 1st beta version of our next major release. You can read more about it here: https://buddypress.org/2019/08/buddypress-5-0-0-beta1/
๐ฉ๐ปโ๐ป๐จ๐ฝโ๐ป
Hi !
Weโve just published the 1st beta version of our next major release. You can read more about it here: https://buddypress.org/2019/08/buddypress-5-0-0-beta1/
๐ฉ๐ปโ๐ป๐จ๐ฝโ๐ป
Here are three important dates about our next major version:
@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.
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.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.
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:
npm install & grunt build
to get the BP REST API into this build.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.
This is the agenda for our next Dev Chat which will happen thisย Wednesday at 19:00ย UTC inย #BuddyPress.
If you have anything you wish to add to this agenda or specific items related to those listed above, please leave a comment below.
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 ๐
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.
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.
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.
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).
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.
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.
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.
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ย ๐ช ๐
This is the agenda for our next Dev Chat which will happen this Wednesday at 19:00 UTC in #BuddyPress.
PS: This will be our last Dev Chat before the release of the 5.0.0-beta1 ๐จ!
If you have anything you wish to add to this agenda or specific items related to those listed above, please leave a comment below.
Dear BuddyPress block developers,
We thought about you! As the BP REST API will be included into our next major release (5.0.0), it will open up new opportunities to create great features and of course BuddyPress blocks. To make things obvious for our end users, what about storing them into the BuddyPress blocks category weโve just added to BuddyPress Core (See changeset #12418) ?
To do so, when registering your block type, youโll just need to set the category
property of your block to buddypress
. Hereโs an example below.
( function( blocks, element ) { var el = element.createElement; blocks.registerBlockType( 'bpeb/example-block', { title: 'BuddyPress example block', description: 'A BuddyPress example block to show how to be listed into the BuddyPress blocks category.', icon: 'buddicons-groups', category: 'buddypress', edit: function() { return el( 'p', {}, 'BuddyPress blocks are stored into the BuddyPress blocks category.' ); }, save: function() { return el( 'p', {}, 'BuddyPress blocks are stored into the BuddyPress blocks category.' ); }, } ); }( window.wp.blocks, window.wp.element ) );
Get the BuddyPress Example Block from Gist.GitHub | Block Editor Handbook
NB: This category will be available as soon as 5.0.0 will be released.
๐ ๐
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.
@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.
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)
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.
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 ๐.
@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.
@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 ๐ค.
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 ๐ช.