Dev Chat Summary for March 30, 2016

BuddyPress 2.5.2

@dcavins,  release lead for BP 2.6.0, packaged and released BuddyPress 2.5.2 on Thursday, March 31. This fixes some email issues reported in trac and forums.

BuddyPress 2.6.0 Schedule

  • Beta 1: May 25, 2016
  • Release Candidate 1 (string freeze): June 8, 2016
  • Target Release Date: June 15, 2016
  • There are 95 tickets slated for 2.6.0 to date. Forty-seven of 79 tickets still open have patches.

Weekly Meeting Time

Join us every Wednesday at 19:00 UTC at the #buddypress channel on Slack. @djpaulgibbs encouraged anyone who wants “to participate in these meetings but can’t always make it can leave comments in Slack beforehand” or in posts here at bpdevel.

For newcomers, here’s how to get a WordPress/Slack account.

BuddyPress Work Parties née Bug Fixin’

A friendly reminder from @dcavins re invitation to a party on Slack or Trac  to fix ’em bugs this coming Tuesday, April 5 and Thursday, April 14. 🙂

2.6.0 Scoping/Wishlist

BP REST-API. @dcavins followed up on the status of this project, i.e., whether we can work on this or should this hold until WP API gets sorted. @djpaulgibbs noted that “WP API ​is​ sorted. You/we can work on it now.”

BP Style Modules – A Proposal. @dcavins asked for more information about the proposal. @hnla: “Style modules is an additional enhancement for templates, more for engaging the community and providing a means to add small code blocks, similar in the way frameworks offer them sometimes.” @boonebgorges and @hnla later exchanged a series of enlightening comments about some of the details of @hnla‘s proposal.

A new API to manage single items navigation (#6534) @boonebgorges passes baton to @im4th to save this ticket from oblivion. @im4th brought up the issue of an upgrade routine to implement this feature which requires Framework for bulk data handling after updates (#6841).

Incrementor-based caching for ID queries (#6643) @boonebgorges is looking to implement this for at least one component during 2.6.

Accessibility tickets. @mercime will be working on the ones already in trac and will be adding some more later.

Explore Behat to add a functional testing capability to the project. @djpaulgibbs‘ dream is look into adding a functional testing capability to the project. “I don’t know if this is something that we’ll want, but I need to build it before I can convince everyone.”

New bp-template pack @djpaulgibbs is trying to come up with a plan to answer the never-ending questions around if/when BuddyPress will ever get a new one. “I’ve started with asking about eight of you some questions around that. It’s going to be a lot of work to come up with some kind of plan. I got essay-length replies from everyone and each reply is vastly different. Everyone has a very different opinion. I think some goal-setting needs to occur before we are able to write new templates with 100% buy-in from everyone, but it’s still early days and I reserve the right to change that opinion.”

Group Types API (#6784) @boonebgorges mentioned that it would be good to make headway on this ticket. Ping @mamaduka

2016 BuddyPress Survey (#6792) @mercime will conduct this year’s survey after the April 15 tax day.

Activity link moderation doesn’t output useful error message to end users (#6719) @rayisme has made some headway on better error messages in the activity stream. “Question is should we be holding off on this for an activity_status DB column.” @boonebgorges noted that  the “main issue would be documenting that select * from $bp->activity->table_name queries will have to be adjusted accordingly.”

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

#6534, #6643, #6719, #6784, #6792, #6841, #buddypress, #dev-chat

Dev Chat Summary for March 23, 2016

BuddyPress 2.5.2

Four tickets have been slated to date for this milestone. Possible release date: March 28, 2016.

Release Leads for BuddyPress 2.6.0 and 2.7.0

@djpaulgibbs, @boonebgorges, and @johnjamesjacoby have been talking about what they could “adopt from WordPress core’s development processes and see how they work out for BuddyPress.” Starting 2.6, we’re going to have release leads as described in this RL announcement in WP Core by Andrew Nacin.

@boonebgorges noted, “The RL gets a sense at the beginning of the dev cycle what he/she would like to accomplish, as well as what others want and are willing to contribute. Within those parameters, there is likely lots of room for the RL to make decisions about what the focus should be.”

David Cavins David Cavins will lead BuddyPress 2.6. @dcavins (twitter) has been a member of the BuddyPress Core Team since January 2015. David is a huge fan of the groups component and the collaborative possibilities it offers a community. He also builds acoustic guitars in his adopted hometown of Columbia, Missouri.

Mercime Next at bat for BuddyPress 2.7, @mercime has been a member of the BuddyPress Core Team since April 2014. Mercime (twitter) enjoys building sites with an eye on accessibility as well as contributing to open-source projects like BuddyPress, bbPress, and WordPress via trac, codex, forums, theme reviews, and surveys.

BuddyPress 2.6

@dcavins will be setting the release schedule this Wednesday during our dev chat. One of the things he’d love to see are optimizations, like extending “our use of caching to group memberships, for instance.” (#6327). He’d love to get everyone’s feedback on ways to make BP run more lightly, “so please be thinking about your favorite component.”

BuddyPress 2.7

@mercime will share the focus and scope at a later time. In the meantime, @bowe suggested, “a release cycle focused on the community aspects. Bring some lesser known but awesome BP stuff to the forefront and implement some long standing UI/UX improvements and rethinking of what BuddyPress should be in 2016 and onwards.” 🙂

It takes a strong volunteer community to improve the BuddyPress project for each release. Your contributions are most welcome and appreciated!

Open Floor

1. Theme Review

@djpaulgibbs reiterated @karmatosed‘s invitation to join the WP Theme Review Team and review BuddyPress-specific themes currently in queue.

Hey amazing BuddyPressers :wave: – I come bringing good news. We have 4 themes waiting for theme review for BuddyPress which is unusually high. Unfortunately I also bring bad news and we don’t have enough reviewers anymore to do this without it taking ages for the poor themers. I know you’re all super busy, but if any of you with theme experience want to give us a hand it would be brill!

For those interested, please read how to conduct a theme review. @bowe mentioned that he will be reviewing a theme this weekend.

2. BuddyPress.org Theme and Plugin Pages

@bowe is currently working on the outline of the proposed new theme/plugin pages to replace the ones @djpaulgibbs deleted the other week. Let someone know at the #buddypress slack channel when you’ve got something ready Bowe.

3. Audit of Components in BuddyPress Trac

@offereins inquired about other development process ideas which the Lead Developers found useful besides having release leads, like having component maintainers and whether BuddyPress would benefit from the concept. @boonebgorges and @johnjamesjacoby noted the pros and con. @djpaulgibbs opined that BP trac components would probably need some review to see that they’d fit into this kind of model (BP Components e.g. groups would be way too big). @boonebgorges stated, “That would be a good first task for someone interested in making it happen.”
Result: @offereins has accepted the task of auditing components listed in BP trac 🙂

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

#6327, #dev-chat

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.

General Summary as of August 2, 2015

Apologies for not posting updates here lately. This  is a compilation of all the informal and official chats during the month of July ( 1st, 2nd, 3rd, 4th, 5th, and in between) as well as relevant activities in Trac. It’s organized to give you a bird’s-eye view of the cool & amazing BuddyPress features and enhancements coming soon and those which have already landed.

BuddyPress 2.3.3

There will be a minor release coming up to address some necessary fixes and updates. Seven tickets are currently slated for this release, four of which have been completed namely:

  • Add BuddyPress Menus to Customizer (#6509)
  • bp_create_excerpt returning mall-formed markup (#6517)
  • Minor class change for bp-core-admin-tools.php (#6561)
  • WP 4.3 changes in WP_List_Table (#6465)
  • The list of tickets slated for BP 2.3.3 are available on this page.
  • Release date: TBA

BuddyPress 2.4.0

  • Target Release Date: October 6, 2015
  • BP 2.4.0 Beta 1: two weeks before release

TICKETS COMPLETED

Twenty-four trac tickets have been closed to date. The complete list of all tickets completed for BP 2.4.0 are available on this page. Some tickets noted were:

  • Separate functions for creating a new nav link and registering a screen function (#6534)
  • New Filter for Groups Widgets and Members Widgets (#6513)

ONGOING WORK

Eight-two more tickets are slated for 2.4.0. Keep updated with the complete list of these tickets on this page. The following have also been highlighted in compiled chats:

xProfile fields used for signup should be configurable (#6347) @johnjamesjacoby. This feature would allow admins to cherry pick which profile field from any profile field group will be included in the registration page.

Continue xProfile field improvements @johnjamesjacoby continues to tackle tickets relating to xProfile Fields and xProfile Field Groups.

User roles with different profile fields (#5192) @boonebgorges worked with @offereins,  @tanner and  @im4th on the “first killer feature for member types.” Screenshot on the left below shows the new metabox  on the profile field edit panel which allows the administrator to select the member types to which the field is applicable  if you’ve set up member types in your site and none were selected.  Screenshot on the right shows a profile field unavailable to all members. Patches have been committed to trunk. Testing welcome.
membertype-profilefields

A new API to manage single items navigation (#6534) @im4th and @boonebgorges discuss strategies to make the new navigation API much more flexible and configurable than what’s currently available — “register nav items in a maximal way with callbacks, i.e., always register them, and then allow them to be suppressed when rendered, according to whatever access conditions have been set up.”

Add UI for adding Profile Header Images for Users and Groups (#6570) aka Cover Photos.  Screenshot below is a teaser of the profile header image within the Twenty Thirteen theme.  This feature is still in the preliminary stage as the conversation continues between @im4th and @johnjamesjacoby to determine the best approach to set up cover photos using the BP Attachments API. @modemlooper and @buddyboss have also shared how they implement this feature in a plugin or theme respectively.
Profile Photo or Cover Photo

Inline Documentation (#6396 through #6407) second pass by @tw2113 to clean up and update inline documentation. He’s also planning to parse out all the @todo notations and start some tickets for those items.

Fix for bp_groups-template in order to support Ajax for group admin actions (#6387@rayisme has uploaded patch to allow developers to use group template functions across all group contexts.  Dev feedback needed.

Additional styling support for BuddyPress Widgets (#5817) @rayisme has uploaded a patch to ensure that BuddyPress classes are injected in before_widget for themes that do not add the ‘widget’ class.

Companion Stylesheet – Twenty Thirteen (#6533) @hnla continues with the beautification of BuddyPress elements within the WordPress default themes.

Use WP 4.3 site icon feature to set a blog’s “profile photo” (#6544) aka Blog Avatar. @im4th has uploaded a patch using the customizer site-icon feature.

New Invitations API (#6210) @dcavins will continue with his work on this new API in addition to the trac tickets related to invitations and groups.

Accessibility fixes for bp-legacy templates (#6531) and BP admin screens (#6532) @mercime has uploaded patches for the two tickets. @im4th has committed patches for the Avatar UI uploader in the frontend screen and has added patches for the uploader in the backend.

UPCOMING TICKETS

BP Emails: @djpaulgibbs kicked off the BP emails discussion last July 8th which lasted for ~ two hours. Topics included: current WP email solutions/plugins, email queueing, needing a real cron job, BP_Email Class or not, BP email templates, possible Customizer piggyback, including modern PHP library, making the emails customizable by administrators, class/interface that implements the integration with a delivery service, etc.

Devhub for BuddyPress and bbPress: @djpaulgibbs will share more about these projects soon.

Translating BuddyPress

BuddyCamp Brighton, UK

  • Reminder: The first BuddyCamp in Europe is this coming Saturday, August 8! The schedule has been posted and tickets are still available.
  • Speakers: Paul Gibbs, Tammie Lister, Rocío Valdivia, Mathieu Viet, Hugo Ashmore, Sven Lehnert, and Michael Eisenwasser
  • Sponsored by: Bluehost, PlanetHoster, GoDaddy, WPML, Human Made, BuddyBoss, BuddyForms, WooCommerce, WebDevStudios, DataFlexor, Make Do, and Connected. Thank you!
    buddycamp-brighton-speakers
  • Update: Read @djpaulgibbs new post about BuddyCamp Brighton at our BuddyPress blog.

Interview with Paul Gibbs and John James Jacoby

  • Jeff Chandler and Marcus Couch interviewed @djpaulgibbs and @johnjamesjacoby at WP Tavern’s special podcast last Wednesday. If you missed it, just go to this page and listen to the latest updates about BuddyPress and more.
    Interview with John James Jacoby and Paul Gibbs

#5192, #5817, #6210, #6347, #6387, #6396, #6407, #6465, #6509, #6513, #6517, #6531, #6532, #6533, #6534, #6544, #6561, #6570, #dev-chat

We’re going to move our…

We’re going to move our weekly dev chats to our new #buddypress Slack chat room.

What’s Slack? Why the change? Learn about WordPress’ recent Slack announcement over on make.wordpress.org, and join in! We’ll see you there. 🙂