Dev Chats as of March 15, 2017

BuddyPress 2.9 Schedule

  • March 22 – Kick off
  • June 7 – Beta 1
  • June 14 – Beta 2
  • June 28 – Release Candidate 1 – String freeze
  • July 5 – BP 2.9.0 Target Release Date

@hnla, BP 2.9 Release Lead, looks forward to discussing project scope/focus/tasks with the team on March 22.

Dev Chat Schedule

Daylight Savings Time for the United States started Sunday, March 12, while DST in Europe will begin on March 26. In keeping with schedule adjustments from previous years, following is the schedule of our dev chat till further notice:

  • March 22 – BP Dev chat will remain at 20:00 UTC (4:00 P.M. EST / 1:00 P.M. PST for U.S. residents).
  • March 29 through end of DST – Dev Chat will be moved to 19:00 UTC.

BuddyPress.org Redesign

  • The redesign of BuddyPress.org has been discussed many times over a number of years.
  • Feb. 22: @modemlooper initiated discussion this year about BuddyPress.org colors, adding a showcase page, work on the product side, among other things. He also posted some screenshots on that day and following days to ask for feedback.
  • March 6: @modemlooper set up a responsive demo site.
    March 6 - modemlooper initial design
  • March 15: @karmatosed uploaded her design  during dev chat. She mentioned @djpaul asked her to look at a BuddyPress.org redesign last year.
    March 15 - karmatosed design
  • Other notes:
    • Redesign is also needed for codex.buddypress.org plus a new design for developer.buddypress.org to hold the BP developer reference which @tw2113 has on his site https://trexthepirate.com/buddypress/
    • BuddyPress.org themes are located at https://meta.trac.wordpress.org/browser/sites/trunk/buddypress.org/public_html/wp-content/themes

Slack log: https://wordpress.slack.com/archives/C02RQBYUG/p1489608197865211

#dev-chat

General Summary as of March 2, 2016

This post is a compilation of updates and events over the last few weeks.

The Road to BuddyPress 2.5.0

Beta 1 – Packaged and released by @boonebgorges last February 8, 2016 on schedule.
Beta 1 blog post@im4th with @dcavins.

Release Candidate 1 (string freeze) – Packaged and released by @djpaulgibbs last February 23, 2016.
RC 1 blog post@im4th

2.5.0 Stable Release earlier today – packaged and released by @boonebgorges
Announcement post@im4th with @dcavins and @boonebgorges
Official Changelog@mercime with @rayisme and @djpaulgibbs.
95 tickets were cleared for this milestone

Many thanks again to the 2.5.0 Contributors!
Boone B Gorges (boonebgorges), Brajesh Singh (sbrajesh), Brandon Allen (thebrandonallen), Christian Wach (needle), Damian (timersys), danbrellis, David Cavins (dcavins), Dennis (wpdennis), Fee (wdfee), Garrett Hyder (garrett-eclipse), George Mamadashvili (Mamaduka), Henry Wright (henry.wright), Hugo (hnla), Jeff Sayre (jeffsayre), John James Jacoby (johnjamesjacoby), Jonnyauk, Joost Abrahams (joost-abrahams), kennibc, OC2PS (sooskriszta), Laurens Offereins (Offereins), LenLay, Mathieu Viet (imath), mercime, Michael Beckwith (tw2113), modemlooper, Paul Gibbs (DJPaul), Rami Yushuvaev (ramiy), r-a-y, shanebp, Slava UA (slaffik), Srdjan (jozik), Stephen Edgar (netweb), timeuser, vnd.

BuddyPress Emails Documentation

Many thanks to all who contributed the following Codex articles about this new innovative email notification feature:
Emails by @modemlooper, @rayisme, and @djpaulgibbs.
Email Tokens by @dcavins, @modemlooper, and @djpaulgibbs.
Custom Emails by @modemlooper

BuddyPress “Office Hours”

@boonebgorges proposed a once-a-month concerted bug scrub. @dcavins proposed calling it “BP Breaks Travis Monday.” @djpaulgibbs seconded the idea today and suggested conducting the scrub sometime next week or the week after next.

BuddyPress at WordCamp Paris, Feb. 5, 2016

4 community sites with BuddyPress by @oelita (Sylvie Clément). @oelita shared how she customized BuddyPress according to each client’s requirements in the following projects : a content sharing website, a community site, a matchmaking platform for language exchange, and a social network of gardeners. Slides in French are available at http://www.slideshare.net/Oelita/4-sites-communautaires-faits-avec-buddypress-wordcamp-paris-2016

An alternative media management by @im4th, who is also one of the organizers of WordCamp Paris. He covered the WP media types/management and shared a new plugin, Front-End Attachments, to illustrate how to benefit from the BP Attachment API. Slides are available in French at https://cldup.com/wW276vVmxF.pdf and the plugin is available at https://github.com/imath/front-end-attachments. @im4th reported that because of this presentation, he got invited to speak about BuddyPress at the Bordeaux WP Meetup last Feb. 25 🙂

BuddyCamp Miami, Feb. 19, 2016

Thank You to @dimensionmedia, @ptahdunbar, and fellow WordCamp Miami organizers for hosting the 4th BuddyCamp Miami plus providing the livestreams for this event! If you missed watching the live presentations, the archived videos are still available at the time of this post.

BuddyCamp Miami A.M.: State of the Buddy by @johnjamesjacoby, How to Contribute to BuddyPress @_dorsvenabili, and BuddyPress 101 by @dimensionmedia

BuddyCamp Miami P.M.: Developers: Teach Everything You know by @carlalexander, Navigating BuddyPress’ Identity Crisis by @johnjamesjacoby, BuddyPress: New And Upcoming Features by @_dorsvenabili, and a Q & A Panel hosted by @johnjamesjacoby with @boonebgorges, @im4th, and @dcavins via Google Hangout.

Speakers:

 

Google Hangouts Panel:

#dev-chat

As you might know, we…

As you might know, we recently started work on a REST API implementation for BuddyPress.

To support this, we’re going to arrange a once-per-fortnight dev chat. @bronsonquick and @modemlooper will be leading the discussion. This will be run alongside the regular dev chat for the main project, so on some days, there’ll be two chats!

There will be a BP REST API dev chat this week. Here’s the times/dates for your calendar:

  • Wednesday at 22:00 UTC.
  • Dates: Every other Wednesday, e.g. 27th January, 10th February, 24th February, and so on.

BP REST API Dev Chat Summary for January 14, 2016

Firstly, I’ve been told I’d better do a bit of an intro. My name’s Bronson Quick and I work for the wonderful company that is Human Made. I’ve been using WordPress since 2008 and I’ve been a core contributor. My most known open source project is Chassis, a project that Ryan McCue and I built, which is a very lightweight WP Vagrant install that uses Puppet for provisioning. In terms of BuddyPress contributions I’ve submitted PR’s back to @djpaulgibbs Achievements plugin and @boonebgorges Import From Ning plugin.

Introduction aside, after a few years of chatter and various siloed implementations of BP REST API’s we had our first offical BP REST API meeting this morning. The discussion’s purpose was to start talking about how we tackle making BP REST API and who wants to contribute.

I think the key takeaways are as follows:

  • The core BP REST API team: I will be leading the project with @modemlooper‘s help. If you’d like to contribute as well then please either reply here or drop into the #buddypress change and say Hi! @johnjamesjacoby has created a Github repo for the project.
  • Planning/Architecture: Planning how we tackle this is very important rather than diving straight into the code. As we’re “standing on the shoulders of giants” we can use the lessoned learnt from the WP REST API project and put in time at the start to plan this properly. It makes sense to plan out the data we would like returned from endpoints and how they relate to each other with _links. For example, if we’re displaying the data for the activities endpoint rather than showing a user_id we should link this to a user endpoint.
  • A “schema first” approach: The WP REST API infrastructure in core provides a schema which is used for both human readability of the endpoint data as well as data validation. This approach was recommended to be by one of the WP-API lead developers, Joe Hoyle at WCEU.
  • Implementation: The various iterations of the BP API that we’ve seen in the wild before were usually built pre-WP 4.4 this meant most of them wrapped/extended existing classes and they also used internal BuddyPress functions to get data. We think it’s going to make more sense going more low level and using the existing objects to get the data we need.
  • Test Driven Development: Ideally we’d plan an endpoint, write tests that fail then write the code for the endpoint until the tests pass. This is something that’s often talked about as being an ideal development methodology but it’s rarely practiced in the WordPress space. Tackling a project this way should mean less bugs although I do realise this could be a blocker for new contributors.
  • Privacy: This was raised as an issue. We think if we only expose the data that’s public in BP core and the XProfile components then we should be okay. Roles, capabilities and authentication will all come into play when we get to that point. I suggested perhaps having a constant once this gets into BP core to endable the BP REST API so that it’s up to the site owner or developer to enable this thus putting onus back on the site owner regarding privacy.
  • Initial Endpoints: We think it makes sense to tackle read only endpoints first (i.e. WP_REST_Server::READABLE) for the activity stream and Xprofile endpoint so that we can tackle the linking I mentioned earlier.
  • Folder Structure/Loader: We will need to work out a good structure for this designed with the intention that this “Feature Plugin” will one day land in BP Core. @modemlooper has opened an issue for that.
  • Start Small: A REST API for BuddyPress is a huge undertaking so we want to start small and add to it as we go.
  • Purpose: The question of “What’s the purpose of the BP-API REST API?” was raised.  The main purpose is all about exposing data in a RESTful way so that developers and site owners can use the data in any way albeit a plugin, mobile app or whatever else springs to mind. The other main purpose for the BP REST API is that we can use the endpoints going forward to alter some things internally in BuddyPress as in the past ” the functions throughout BuddyPress are very purpose built to solve one specific theme-side problem”.
  • WP-API: We need to keep on top of the changes to the infrastructure of WP-API going forward as we’ll need to port changes into the BP REST API. Luckily I should be able to be notified of critical changes through Joe Hoyle and Ryan McCue! 🙂
  • Readme: We need a readme.

We’d love your feedback and help!

If you weren’t able to attend the meeting and have some thoughts around this discussion and potential approach then please post a reply below or drop into #buddypress in Slack.

BuddyPress 2.4.0 will introduce Cover Images for members & groups!

Most social media include a feature to allow their users to customize their profile’s header. While this feature may seem trivial, it is actually quite complex to implement in our case.

Unlike these social media which only need to manage one single graphical interface, BuddyPress can be integrated into nearly all WordPress themes and needs to account for all scenarios.

Of course, this complexity is also one of our major strengths: BuddyPress lets you build highly customized community websites.

To add to this complexity, some BuddyPress themes or plugins have already built this feature.

That’s why during the development of this feature and in all the decisions we took we always kept in mind these two concerns:

  1. Maximize the feature’s compatibility with most themes
  2. Include simple ways to deactivate it (if needed)

Before telling you more about these 2 points, here are the BuddyPress Cover Images!

User's profile

User’s profile

 

Members can manage their cover pictures by visiting their profile page and activating the “Change Cover Image” nav.

 

"Change Cover Image" screen

“Change Cover Image” screen

 

If the Groups component is active, Groups will also be able to enjoy cover images!

 

Group's Cover Image

Group’s Cover Image

 

We’ve added a new step to the Group’s creation process to let Administrators set the cover image for their Groups

 

Group's Cover Image creation step

Group’s Cover Image creation step

 

At any time, Group Administrators can manage the cover image by displaying the “Cover Image” sub nav of the Group’s management area.

 

Group's Cover Image manage screen

Group’s Cover Image manage screen

 

Responsive?

 

User and Group cover images viewed on a smartphone.

User and Group cover images viewed on a smartphone.

 

Of course!

 

1. Maximize the feature’s compatibility with most themes

To make this happen, we rely on our great BP Theme Compat API. In short, we are checking the active theme is using the API and the BP Legacy template pack before registering the feature. If it’s the case, BP Theme Compat will take care of everything!

If you’re wondering how the size of the cover image is calculated, i’d say it’s an “equation” involving two parameters: the $content_width global of the theme and the Avatar’s full height.

We have already optimized the feature for the latest “Twenties”. By the way all the screencaps of this article were made using the “TwentyFifteen” theme.

Please note that the BP Legacy template pack has evolved :

Single items Edited Templates New Templates
User bp-templates/bp-legacy/buddypress/members/single/home.php
bp-templates/bp-legacy/buddypress/members/single/profile.php
bp-templates/bp-legacy/buddypress/members/single/cover-image-header.php
bp-templates/bp-legacy/buddypress/members/single/profile/change-cover-image.php
Group bp-templates/bp-legacy/buddypress/groups/create.php
bp-templates/bp-legacy/buddypress/groups/single/admin.php
bp-templates/bp-legacy/buddypress/groups/single/home.php
bp-templates/bp-legacy/buddypress/groups/single/cover-image-header.php

If your theme is using the BP Theme Compat API (which is the case of most WordPress themes) and if you haven’t overridden the templates listed inside the “Edited Templates” column, then as our test drive is attesting: BuddyPress Cover Images should look awesome into your community.

If you’ve overridden one of the edited templates and you want to enjoy this new feature, please make sure to update your templates by the time BuddyPress 2.4.0 is released.

If your theme requires some “fine-tuning” or if you’re feeling the need to customize the default appearance of the members profiles and groups headers, be assured that you’ll be able to do it easily. I’ll be publishing more information in the BuddyPress Codex about it.

For Standalone BuddyPress themes like BP Default.

These themes are using their very own templates and are generally adding BuddyPress support (add_theme_support( 'buddypress' ) ) into their functions.php file. In this case, the BP Theme Compat API won’t register dynamically the BuddyPress cover images feature. But, it will be very easy for these themes to enjoy it! If you’re eager to see how this will be possible, you can have a look at a diff i’ve made when testing the BP Default theme 🙂

Include simple ways to deactivate it (if needed)

Your theme is using the BP Theme Compat API and you want to deactivate Cover Images for members, groups or both?

First, at any time, you can do it by deactivating the corresponding setting for cover images in Settings > BuddyPress > Settings as shown in the screencap below.

BuddyPress Settings

BuddyPress Settings

 

Another way to completely deactivate it is to use these filters :

// For members :
add_filter( 'bp_is_profile_cover_image_active', '__return_false' );

// For groups :
add_filter( 'bp_is_groups_cover_image_active', '__return_false' );

Or you can stop the BP Theme Compat API from dynamically registering the BuddyPress Cover Images support for you site using this kind of code :

function cover_images_no_support() {
    remove_action( 'bp_after_setup_theme', 'bp_register_theme_compat_default_features', 10 );
}
add_action( 'after_setup_theme', 'cover_images_no_support' );

 

If you are a theme designer or the author of a plugin managing Cover images, we recommend that you don’t forget to test that everything works fine for you during the 2.4.0 beta period.
Of course everyone is welcome to help us by testing BuddyPress during this period 🙂

Finally, we’d like to thank all the contributors who gave their professional feedback while building this new “Attachment” feature with special mention to @modemlooper and @BuddyBoss.

To read the full story of this feature: #6570

#6570

General Summary as of September 9, 2015

This is a compilation of dev chats held in August 26, September 1, and September 9.

BuddyPress 2.3.4

There will be a minor release coming up to address some necessary fixes and updates. Five tickets are currently slated for this release, four of which are still open.

  • The list of tickets slated for BP 2.3.4 are available on this page.
  • Release date: TBA

BuddyPress 2.4.0

  • BP 2.4.0 Beta: October 7, 2015
  • BP 2.4.0 Release: October 28, 2015
  • Features slated for this release are available in our Trac Milestone

TICKETS COMPLETED

Forty-one trac tickets have been fixed to date. The list for all tickets completed so far is available on this page. Notable:

User roles with differents profile fields (#5192) Many thanks to @boonebgorges, @Offereins, @tanner-m, and @im4th, work on this ticket has been completed and the “first killer feature for member types” is available for testing and feedback.

ONGOING WORK

Ninety-one more tickets are slated for 2.4.0 to date. You can keep updated with the complete list of these tickets on this page. The following have been highlighted in compiled chats:

xProfile Fields and Field Groups@johnjamesjacoby continues work on enhancements and fixes for the xProfile component, specifically querying & sign-up fields. Patches coming up.

@since standard not parseable with phpDocumentor 2 – (#6576) In preparation for setting up developer.buddypress.org, @djpaulgibbs posted that our current @since tags are not being parsed/extracted correctly per his tests. @tw2113 has accepted the task to convert the @since tags throughout the project and has already completed the conversion in four component folders to date.

Email API and customisation features – (#6592) @djpaulgibbs has posted the scope and vision for the first version of BuddyPress Emails. He has started work on this already in his github repo but would need to “add a bit more code” before he reaches out to all who said they wanted to help with this new feature.

Create New Invitations API – (#6210) @dcavins continues work on the Group Invitations API which needs some other trac tickets to be completed first. To start off, he has introduced a new function `groups_send_invite_by_invitee()` to handle sending a single invitation keyed by the invitee ID and group ID. In conjunction with that, he is working on adding a “manage invitations” pane to the group admin screen.

Let’s give post-form.php the love – (#6569) In ticket, @im4th, @rayisme, and @modemlooper have been in discussion about improving the UI of the Activity post form. @im4th has uploaded patches which include new hooks and reorganization of the post form. @im4th added, “We want to make it possible for any plugin to add custom ‘attachment’ types.”

  • @johnjamesjacoby noted that “with cover photos and avatar upload improvements, @im4th and @rayisme have both done a good job of assessing the typical user and use cases” when @modemlooper voiced his concern about adding new functionalities directly to core instead of introducing such as feature plugins first.
  • @boonebgorges mentioned that he “maintained a lot of BuddyPress sites and knew the pain of having an update introduce UX that he hadn’t prepared for. But I know how to deal with this, and it seems better than the alternative, which is disabling new stuff by default, and never having anyone use it.”
  • @rayisme said that an admin option to turn off attachments is doable and makes sense.
  • @im4th averred that new features will be extensible as usual and will include documentation.

Add UI for adding Profile Header Images for Users and Groups (#6570) and BuddyPress Modal Iframe (#6604) – @im4th has been rocking it with the new cover photos feature along with @rayisme. In the latest patches, in addition to the new UI for cover photo uploads for members and groups in the frontend, @im4th has added uploading via new BP Modals in the frontend and backend for both profile images and cover photos. Very cool, check it out 🙂

Commit Access

BuddyCamp Brighton Videos

The following videos are now available at WordPress.tv:

Enjoy 🙂

#5192, #6210, #6569, #6570, #6576, #6592, #6604, #dev-chat

Dev Chat Summary for August 12, 2015

BuddyPress 2.3.3

Release Date: After WP 4.3.0 rolls out next week.

There are three open tickets:

  • Wrong shape of the CROP size of the group thumbnail (#6551)
  • Mentions.js fails on wp-admin post editor (#6487)
  • WP 4.3 changes in WP_List_Table (#6465)

@djpaulgibbs has volunteered to help move these tickets forward.

BuddyPress 2.4.0

Add UI for adding Profile Header Images for Users and Groups

  • (#6570) @im4th opened the conversation which lasted ~ one hour on the best way forward for this new feature. This resulted with great feedback from @johnjamesjacoby, @rayisme, @djpaulgibbs, and @hnla.
  • Points made:
    1. Feature is available for all themes. bp-legacy‘s member-header.php gets the new hotness, and nothing gets broken if the feature is not activated.
    2. Create new template part with new markup, styles, and JS as needed
    3. Integrate a flexible header image for admin-area profiles, user dashboard
    4. If a custom template part is used in theme, then nothing happens because theme compatibility would never include anything in bp-legacy. If they are relying on theme compatibility and bp-legacy then they get the new markup and CSS that we give them.
    5. Users/theme authors will be able to edit their home.php template to support this new feature
  • More to follow. Odds are, there will be some fast and furious work coming soon.

Conversation replies don’t immediately inherit the HTML of custom templates

  • (#6572) @rayisme introduced a new template part to replace the hardcoded markup used to render a single message item in ticket. Discussion in dev chat then ensued to solve one of the two hard things to do in computer science, naming things . Consensus was reached on the name of the new template part, simply message.php.
  • Update: Patch has been committed to core.

@since standard not parseable with phpDocumentor 2

  • (#6576) @since tags throughout the BuddyPress project needs to be revised/updated to parse docs correctly in preparation for developer.buddypress.org.
  • @tw2113 will be working on this.

Attachment API conflicts with wp_enqueue_media()

BuddyCamp Brighton, U.K.

This event was a success based on the feedback from the attendees. Congratulations to @djpaulgibbs and @karmatosed, organizers of the first BuddyCamp in Europe, as well as to all the speakers and presenters!

  • @im4th has posted about his BuddyCamp experience in français along with his slides at his site.
  • @modemlooper has uploaded his BuddyCamp video about mobilizing your BuddyPress site @ Dropbox.

If you want to include links to your BuddyCamp Brighton slides/videos or photos, post a comment below and we’ll add it to the list above.

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

#6465, #6487, #6551, #6570, #6572, #6574, #6576, #dev-chat