Dev Chat Summaries for April 5 & 12, 2017

bp-nouveau template pack

@hnla reported on the bug and a11y fixes made on bp-nouveau to date. He has added a temporary Gruntfile.js, primarily for compiling and linting Sass files, as well as other project-specific configuration files. @mercime will be posting solutions in codepen for removing placeholders from form controls.

Many thanks to @boonebgorges for delving deeply into bp-nouveau and his post introducing the new template pack.

BP REST API

@rayisme has started work on the /members endpoint for the BP REST API locally. He raised a question at the Github repo re Members – GET – List Users Schema. @modemlooper has responded in ticket.

@rayisme noted, “We’ll definitely have the /members endpoint ready by the time BP 2.9 is done, but probably will not be merged into core. The BP REST API will stay as a plugin for at least the next few release cycles until things have been fleshed out, similar to how the WP REST API was a plugin for awhile.”

Trac Tickets

Allow bp_get_group_permalink() to produce HTML links (#7485) @dcavins has committed fix to trunk.

Update bp_group_description_excerpt() to accept a $length param (#7493) @hnla has patch. @dcavins has responded to keep the group as the first parameter.

Required xprofile fields are not validated (#7483) @hnla has confirmed issue reported in ticket. Needs patch.

groups_send_invites() should allow us to omit sending to users that have already received an invite (#7397) @rayisme will be refreshing the patch for BP 2.9.

Include BP Edit Group Slug into the core (#6014) @dcavins refreshed the patch including unit tests. New patch adds support for changing group slug via wp-admin. Dev feedback requested.

Take advantage of BP_Groups_Group magic methods in groups component setup (#7494) @dcavins has patch. Dev feedback requested.

Use JOIN rather than Subquery on user search (#7442) @brandonliles has patch. Dev feedback requested.

Harmful bp_activity indexes (#7500) @johnjamesjacoby in discussion with @brandonliles.

Deprecate the BuddyPress functions for bbPress 1.x forums (#6851) @johnjamesjacoby introduced a motion to “remove bp-forums pretty much completely, or relegate it to its own compatibility plugin like we did Wire and Status.”
@boonebgorges concurred with the compat plugin route and noted, “I’d like to stage it over maybe two releases, with large warnings in the interim release if you are running legacy forums. Maybe even block upgrade to the removing-version if we detect you are running it (like we did with the 5.3 requirement). How many of them will upgrade to BP 3.0 or 3.1, that’s another question. But it’s easy enough for us to create barriers to white screens, so we should do so.” @johnjamesjacoby: “Making this release ideal for the warning. I think the 3.0.0 release is a nice round number to cut the old legacy forum cord, too.” @boonebgorges: “So admin notices + upgrade-blocks for 2.9, and maybe some logic in 3.0 that prevents loading the full plugin if the compat plugin is not found. Someone will need to wrangle all of the necessary steps, including preparing and releasing the compat plugin.”
@johnjamesjacoby has volunteered for the tasks, “the pleasure of the pain will all be mine.”

Create administration sections for every component that’s currently lacking an interface

@johnjamesjacoby: Friends, Messages, and Notifications basically. “Preferably, I’d like to also stagger the work on those, so the expectation isn’t to have a 100% fully covered and integrated interface that covers all users and use-cases. Similar to Groups Admin (how you can’t create a new group from within wp-admin). I really also want a live-chat style Messages UI while you’re in wp-admin”
@boonebgorges: “Big +1 to more admin coverage, though we should think carefully about whether each of these BP components needs its own top-level item. (Friends may be properly a property of Users, rather than its own thing, or whatever).”
@johnjamesjacoby: “Right now, all of BuddyPress makes theme-side websites better, and that’s awesome, and it should, and always will. But once you enter wp-admin, BuddyPress doesn’t actually help WordPress itself be a better piece of software for managing users, community content, etc. We don’t need to talk about all of the detail-work right now, but I wanted to drop that vision in here now, so everyone has an idea of what I’m thinking, and we can maybe try to hit that vision hard in 3.0 and beyond. Hopefully 2.9 and Nouveau and everything else will keep the traditional BuddyPress installation type satisfied for a few years, enough time to work on REST API, wp-admin integration, maybe some GraphQL if we like that, etc.”

BP Theme Compatibility

A basic visualization of the BuddyPress Theme Compat is now available for bp-templates/bp-legacy. Use Ctl/Cmd +/- to zoom in/out, scroll up/down or click + drag right/left to navigate. Visualizations for bbPress Theme Compat and the upcoming bp-nouveau template pack are also in the works.

Slack logs:
https://wordpress.slack.com/archives/C02RQBYUG/p1491418861341587
https://wordpress.slack.com/archives/C02RQBYUG/p1492023677928317
(Slack account is required)

#dev-chat

BP 2.9 Kick-Off Meeting – March 22, 2017

BP 2.9 Scoping/Wishlist

bp-nouveau Template Pack

@hnla, 2.9 Release Lead, will focus on getting bp-nouveau ready for integration into core this dev cycle. He noted, “bp-nouveau represents a clean break from those older templates, clean markup, new styles new file structure with include files and function files managing components and affords us the opportunity to build a better BP than ever before.”

@hnla encouraged all core devs to have a local install running the plugin version and to reconvene at next meeting for a renewed focus & to air any concerns. He has added the following guides to the project for all who want to contribute:

  • Milestones: https://github.com/buddypress/next-template-packs/milestones
  • Project cards: https://github.com/buddypress/next-template-packs/projects

The major steps to get this project for inclusion are pretty much covered by the milestones but broadly fall into:
1. Core integration: adding the switching mechanism to core admin settings, working out the logic for default selection & some means of registering packs in use.
2. Testing the process for stylesheet building and testing the core files merged to trunk along with possible gruntfile adjustments required.
3. Testing of components by device( mobile/ desktop & browser versions) and testing.
4. Testing Accessibility.

@boonebgorges: “I share Hugo’s belief that the time has come to move beyond bp-legacy, and I think that a new set of templates is critical for the future of the project. I’m going to be working with Hugo over the next few weeks to develop some materials that’ll introduce the rest of the team to the workings of bp-nouveau, as well as more details on a plan for moving toward merge, with the idea of soliciting as much energy and contribution from the broader team as possible.” He will help to get bp-nouveau in for 2.9.

@mercime noted that per her initial a11y audit of bp-nouveau (last year), there were items which needed to be fixed in core first. Edit – Most items have been fixed, there are only a few remaining a11y issues which will affect template pack left in core.

@modemlooper likes the Template Pack UI in admin which he thinks will open up lots of customization … spawning child themes of bp-nouveau.

@dcavins volunteered to help with bp-nouveau. @hnla mentioned his concerns with group creation wanted it more a one step process that we could then paginate if we wanted to but accessing certain meta is hard such as group ID at some points where you need it. @dcavins: “I also have some feelings about group creation. (Like change it to one step then redirect to the new group to setup.)”

@boonebgorges will be working on a summary document about bp-nouveau’s status plus user-facing and developer-oriented features over the next week or so.

BP REST API

@rayisme would like to see where we’re currently at and what we can accomplish in this dev cycle. @boonebgorges responded, “it needs someone to take the lead – there was some initial work done on the Members endpoint but it needs to be seen through.”

BuddyPress.org Redesign

@hnla brought up the redesign site/mockups by @modemlooper and @karmatosed and wanted to know the best way to get the redesign implemented.

@rayisme: “There are elements I like about both. modemlooper’s orange header + iconfont section and karmatosed’s “Are you a user / developer” section. At first, I didn’t like the orange header, but I like that it’s a little in-your-face.”

@modemlooper‘s design was à la https://jetpack.com/ and said, “the design reboot started because I thought the homepage lacked alot of marketing points.” @karmatosed thought that doing original design is good. She’s happy to noodle some more.

@johnjamesjacoby: “Naturally, I have opinions, but mostly I really want all of y’all to feel like these themes are yours to create/enjoy also. It seems like everyone is still in the “I wonder what this or that might look or feel like” which is totally fine. No rush, no agenda, and if something naturally suddenly clicks into the place, we should head that direction.”

Dev Chat Schedule

This is a friendly reminder that starting Wednesday, March 29, dev chat at the #buddypress channel on Slack.com will be at 19:00 UTC through the end of Daylight Savings Time for both U.S. and Europe.

Slack log: https://wordpress.slack.com/archives/C02RQBYUG/p1490212929620791
(Slack account is required)

#bp-nouveau, #dev-chat

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