General Summaries for April 13 – 20, 2016

This post covers the following meetings:
1. New Template Pack, April 13,
2. Dev Chat, April 13,
3. BuddyPress Work Party, April 14, and
4. Dev Chat, April 20.

New Template Pack

We held the first meeting to discuss the new template pack an hour before our regular Dev Chat as scheduled. Members of the core team shared expectations and observations about the new BuddyPress template pack based on what @im4th has accomplished so far in his next-template-pack plugin. The plugin already has an option for end users in the back end to either use bp-legacy templates or use the new template pack and it uses handlebars templating but like email tokens, you can only work with what you have in the JSON payload.

 The initial discovery phase touched on the following items:

  • modularized template pack with some theme goodies sprinkled in
  • put all the new features in next-template-pack including improved UI, compatible with latest BP/WP versions, and all the accessibility baked in.
  • modern JS and CSS, works really nicely with the idea of the CSS snippets library, too … making the whole experience more flexible and easily customizable
  • general agreement that the new template packs don’t have to be beholden to bp-legacy backward compatibility
  • core files  still have to honor the parent theme styles
  • modular CSS – BP  pattern library
  • make a list of the kinds of things we need to output, so we can work to unify styles as much as possible, see http://alistapart.com/blog/post/getting-started-with-pattern-libraries
  • planning documents: Google Docs, bpdevel, Trac tickets
  • identifying core markup to use/move
  • move next-template-pack to BuddyPress github account
  • manifesto with project scope and implementation plan
  • Shoot for the moon. “I’d say let’s not be circumspect (with anything). Let’s go for it, then throttle back what we have to,” per @dcavins

Next meeting: Wednesday, April 27,  same time (18:00 UTC), same #buddypress channel in Slack.
Update: See additional notes in the April 20 Dev Chat at the bottom of this post for the Template Pack meeting next week.

Dev Chat

BuddyPress 2.5.3

  • There are three tickets in queue with improvements to BP Email.
  • Release date: TBA

Email Subject special characters display problem with initiator.name token (#6966). This is the only ticket left open for this minor release. @dcavins, @djpaulgibbs, and @rayisme discussed about the feasibility of adding emoji support in BP Emails. Need to check which email providers and mobile clients show emojis. @rayisme has volunteered to work on this ticket.

BuddyPress 2.6.0

  • There are 115 tickets currently slated for this cycle (32 closed. 83 open)
  • Beta 1: May 25, 2016
  • Release Candidate 1 (string freeze): June 8, 2016
  • Target Release Date: June 15, 2016

Route `/me/*/` to `/members//*/` (#6325) @rayisme has patch for the redirection.

Minimum WP version bump for BP 2.6 (#7013) @dcavins reminded all re @boonebgorgespost: BP 2.6.0 will require WP 4.1 or higher.

filter for $after_member_slug in bp-core-catchuri.php (#6694) Has patches by @dcavins, @boonebgorges, and @rayisme. Needs testing/feedback.

Use “Mystery Group” avatar when group avatar not available (#6372) Has patches by @abweb and @boonebgorges. Feedback welcome.

Activity post form template improvements (#6680) Has patches by @rayisme and @mercime. @dcavins has posted before and after-patch screenshots of the Twenty-* themes and premium themes to address some backpat concerns. Comments on the ticket are welcome.

Re backward compatibility from @boonebgorges: “I think we should try to differentiate between different kinds of (potential) backward compat breaks for templates. some are minor, while others are debilitating. some will simply be a case of a custom template not receiving new features, while others will break markup so that stuff like JS no longer works.” Weigh potential gains from the break “on a case-by-case basis . If we were never willing to break compatibility, we’d never fix any bugs 🙂 “

Accessibility: Update Heading Structure in Template Files (#6871)  @mercime asked for the consensus of the team.  @boonebgorges, “My position is that if we can demonstrate that the styling changes are minimal in the Twenty themes, it’s fair evidence that it’s a change with fairly low negative impact. This also assumes that the a11y benefits are meaningful, which I’m relying on your judgment for.” @djpaulgibbs noted, “BuddyBoss and a UK agency have both told me that the heading changes that have gone into 2.6 will require them to update all their sites/themes. I am not trying to be against improvements. But it’s a fine line.  I am just saying if we are committing to making such significant changes to the main markup, we need to communicate that NOW and way better than we ever have before. Because honestly we’ve always changed stuff and broken it. It has had little to no documentation, generally. As Boone said, we need to look at the impact of each change on its own basis.”

BP Template Versioning (#6642) @djpaulgibbs and @hnla discussed  @im4th‘s work in documenting template changes in the file header in ticket as well as versioning of the template files like Woo does.

Add BP top level menu and Admin Page to Improve User Experience (#6827) @mercime will upload new patch.

Creation of developer.buddypress.org (#6812) @tw2113 would like to get this going sometime soon, “Essentially we need to get a final destination set up, run a parser scan on the latest stable version, and then comb the website for inconsistencies and things needing changed also work on any sort of triggers/automation to update the source there and re-parse.”

BuddyPress Work Party

Route `/me/*/ to /members//*/` (#6325) @rayisme has uploaded new patch. Dev feedback needed.

Comment notification NOT notified (#6057) @im4th has uploaded new patch. Dev feedback needed.

Cover Image location is incorrect for blogs other than the primary blog (#6931) @im4th has uploaded new patch. Dev feedback needed.

Extending Messages notification should be improved (#6750) @rayisme committed patch to trunk.

Profile Cover not working when we define a custom BP_XPROFILE_SLUG (#6962) @rayisme committed patch to trunk.

fatal error: bp_blogs_record_existing_blogs (#6940) @rayisme has closed the ticket in favor of #6370 below.

Blogs: Improvements to bp_blogs_record_existing_blogs() (#6370) Has new patch by @rayisme. @johnjamesjacoby has given feedback in ticket.

Add aria attributes for dashicons in Components screen (#7017) @mercime has committed patch to trunk.

Dev Chat – April 20

Notifications for activity stream comments and replies (#6057) @im4th has patch plus screenshots uploaded and would like to get this new feature in for 2.6. @boonebgorges has posted feedback in ticket. Feedback in Slack was very positive with some suggestions on inline documentation. Looks like this will be fixed soon.

BP Users front.php (#6769) @im4th has uploaded screenshots and the first patch for this new feature. @hnla and @dcavins have mentioned testing and providing feedback soon.

bp_notifications_get_notifications_for_user() bug (#7020) @rayisme has patch.  Testing and feedback welcome.

Route `/me/*/ to /members//*/` (#6325) @boonebgorges has posted feedback for @rayisme‘s patch.

filter for $after_member_slug in bp-core-catchuri.php (#6694) Fix has been committed to trunk by @boonebgorges during dev chat.

BP Template Versioning (#6642) @dcavins: “Need to settle on the format/requirements for the template versioning, we could tag all of the templates, before we come up with our super jam for how to help site owners realize their templates are no longer up to the current high standards.” @boonebgorges “The minimum that needs to be decided for the process to start is what header format we’re going to use. Questions about how we inform users, how we assemble changelogs, etc – these can wait. On the other hand, Inline changelog + summary changelog with each version may be enough.”

Allow admin to select fields to display in user “excerpts” on Groups’ user list page (#4126) @boonebgorges mentioned the UX considerations in the ticket proposed by @oc2ps require admin-level tools (which we don’t currently have) for site owners to modify the way that BP content looks on the front end. Comments/thoughts about whether it’s the kind of thing we want to do are welcome.

@booneborges noted that “if we’re going to introduce something like this into BP, it would have to be an actual interface where you could customize things and it would extend to interfaces other than member directories, in the long run. I think the answer for this ticket is that it’s not a route we can comfortably go down given our current approach to templates.”

Date xprofile field enhancement (#5500) @boonebgorges mentioned that this ticket has a new patch which “has some promise, but will need extensive rewriting to fit with BP/WP standards (not just coding standards, but architecture). I will try to take some time in the next couple weeks to pore over it, but if anyone has time in the meantime, feel free.”

Screen notifications settings page (#6712) Has patches. @rayisme requested for dev feedback.

Additional notes for next week’s Template Pack Meeting

  •  @johnjamesjacoby: “I’d like to propose that in whatever new template pack is built, that no `do_action()` calls exist in template parts, and if we find ourselves wanting them, we architect a better solution inside of the API.”
  • Use “magic hooks” from @johnjamesjacoby, “anywhere we need `before/after` actions in templates, is a place where a new template part should exist, and `bp_get_template_part()` should fire its own `before/after` actions before & after every part is successfully pulled in.”
  • On the other hand, @boonebgorges noted, “Here’s another take on this. If you are a WordPress developer, you know that if you see a `do_action()`, you can make something appear there by calling `add_action()`. If we introduce micro-APIs for every little thing, it obfuscates what is currently a fairly simple process.” @im4th added, “without overriding the full template. That’s the good part of the `do_action` i agree.”

#dev-chat

#4126, #5500, #6057, #6325, #6372, #6642, #6680, #6694, #6712, #6750, #6769, #6812, #6827, #6871, #6931, #6940, #6962, #6966, #7013, #7017, #7020, #buddypress

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

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

Core Dev Chat Summary for January 27, 2016

Trac Tickets

Comment syncing between activity and post comments for Custom Post Types (#6842)  @im4th needed to run an upgrade routine to add a new activity meta to activities about a blog post and consulted whether he could do this using a regular upgrade routine or wait for #6841 to be fixed to committed to core.  @boonebgorges, @djpaulgibbs, @johnjamesjacoby, @rayisme, and @dcavins joined in the discussion to find the optimal solution in the upgrade routine. @im4th also suggested using a dynamic meta_key so that he could avoid the upgrade routine. Update: @im4th has uploaded a new patch which shows that using the dynamic meta_key can avoid an upgrade routine 🙂

Profile/Cover image upload doesn’t work in MS Edge browser (#6846) Update: @im4th just committed to trunk and 2.4 branch so this one’s fixed already 🙂

Email API and customisation features (#6592)  @djpaulgibbs has started committing section by organized section of this cool new feature last week (Jan. 27). Dev feedback welcome.

BuddyPress 2.5.0

  • Beta 1: February 8, 2016
  • RC 1 (string freeze): February 22, 2016
  • Target Release Date: March 2, 2016
  • There are 126 tickets slated for this cycle to date. (Closed: 41. Active: 85)

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

#6592, #6842, #6846, #dev-chat

Core Dev Chat Summary for January 20, 2016

This summary includes pertinent developer conversations in Slack before and right after the official chat time last week.

Trac Tickets

Email API and customisation features (#6592) Three hours before dev chat, @boonebgorges and @djpaulgibbs had a long and interesting discussion about the new Email API. Topics covered: standardizing verbs for method names, choosing taxonomy for Email Types to give admins the option of implementing multiple templates, among others. Latest: @djpaulgibbs has since updated the `amazing-emails` branch at https://github.com/paulgibbs/buddypress/

XProfile field database schema (#6350) @johnjamesjacoby will be writing down his vision for improving the xProfile tables.

Groups: Add Profile Fields and Profile Field Groups (#6783) From an enhancement for the Groups component, @im4th has proposed a change in direction to making this a generic component which would work for any object (Members, Groups, and Blogs) in ticket. @im4th consulted with @johnjamesjacoby about the best way forward.

Comment syncing between activity and post comments for Custom Post Types (#6482) @imath and @rayisme deliberated and agreed on adding `bp_activity_type_supports()` which works similar to WP’s `post_type_supports()` function. This would provide some flexibility if/when more features are added to BP activity types in the future.

General Administration

Messaging

A lively brainstorming session arose from a proposal by @johnjamesjacoby to replace the old “social network” association used for the past 8 years. There were slogans, taglines, and observations shared during and even after the chat:

• If we’re going to change it, can we think of it more as a strategic/goal/mission statement—more than just a tag line? ~@dcavins
• Social network” and “in a box” are both icky. Something having to do with “community” is better than “social network”. As for “in a box”, it glosses over the developer-focused flexibility of BP, which IMO is one of its strong points. ~ @boonebgorges
• It (“BP as a platform”) seems technically accurate, and speaks to the breadth of purpose, and I think it’s meaningful to a non-technical audience. I think we have two audiences – network builders and developers – so maybe our branding should have two parts too ~ @boonebgorges

BuddyPress. Go Social. Build Communities. Create Networks. ~ @mercime
Enabling Community Platforms ~ @hnla
Building Blocks for your Community ~ @jjj
Community toolbox ~ @karmatosed
Community components you can put together in a very easy and funny way ~@im4th
A suite of social components for building communities ~ @pollyplummer
BuddyPress. A developer/professional platform that can scale up to millions of users. ~ @mercime
BuddyPress: Create your own community space ~ @rayisme
You have the users, BuddyPress (has) the building blocks to kit out your community to the fullest ~@netweb
BuddyPress, an online community building kit ~ @robkk

Fun & flexible software for online communities, teams, and groups.
BuddyPress helps you build any type of community website using WordPress, with member profiles, activity streams, user groups, messaging, and more.
~ @johnjamesjacoby

New BudddyPress.org Theme

@johnjamesjacoby noted that the “theme needs a complete revamp and redesign to make it more attractive. I would like for BuddyPress & bbPress to be powered by the same theme, so that they are effectively co-branded as such.” Someone’s going to be tapped to work on the new theme.

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

#dev-chat

#6350, #6482, #6592, #6783

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.

Dev Chat Summary for January 6, 2016

The first dev chat of the year focused on the 2.5.0 release scope. There are currently 104 tickets slated for  this dev cycle: 22 closed and 82 active. The following were mentioned during dev chat (major features have asterisks).

API

*BuddyPress Embeds for activity, user profiles, groups (#6772) @rayisme and @im4th work on ensuring that nested embeds show up as well as preventing embeds from breaking layout, among others.

*Create New Invitations API (#6210) @dcavins has written a bunch of tests for this feature in the last two releases. He’s currently working on the actual code changes and it’s going pretty well. Ultimately, he mentioned he’d like nearly all of the  features of Boone’s Invite Anyone plugin to be rolled in.

*A new API to manage single items navigation (#6534) @boonebgorges

*Email API and customisation features (#6592) @djpaulgibbs will be ready for review in a week or so. He has done lots of work on it and has recently posted an extensive technical update in ticket.

*Group Types API (#6784) @boonebgorges

BLOGS

*Comment syncing between activity and post comments for Custom Post Types (#6482) @im4th has patch which ready for  review/testing.

CORE

Use WP page names for BP directory pages headings (#6765) @hnla

Hooks Documentation Continued @tw2113

GROUPS

Add function to send single invitation (#6025) @dcavins is working on this in relation to the main ticket (#6210) Invitations API above.

NOTIFICATIONS

Comment notification NOT notified (#6057) @im4th will refresh the patch next week.

Screen notifications settings page (#6712) @rayisme

TEMPLATE PARTS

*Companion Stylesheet – Twenty Twelve (#6766) @hnla has committed the first pass of the SASS and compiled CSS files.

BP Users front.php (#6769) @hnla

XPROFILES

*xProfile fielddata visibility should be stored in xprofilemeta (#6413) @boonebgorges has the patch written, “just some work to do on making the migration routine less insane.”

*xProfile fields used for signup should be configurable (#6347) @johnjamesjacoby

xProfile field database schema (#6350) @johnjamesjacoby

BUDDYPRESS.ORG

*developer.buddypress.org (#5129) @tw2113 is working on the parser

GENERAL – ADMIN/UI

Accessibility Upgrades Continued @mercime

FOR NEXT WEEK:

  1. REST API
  2. “Social Network” vs. “Community Software” marketing direction

#5129, #6025, #6057, #6347, #6350, #6413, #6482, #6534, #6592, #6712, #6765, #6766, #6769, #6772, #6784, #dev-chat