Follow development on the latest release

Archives

July 6, 2016 — Dev Chat. Project leads @johnjamesjacoby, @boonebgorges, and @djpaulgibbs presented a number of strategic priorities to help guide BuddyPress development in the upcoming year. These priorities are meant to reflect more accurately the arc of core development over the last few years, as well as the team’s understanding of how BuddyPress is actually used.

An Increased Focus on Site Builders and WordPress developers

One of these strategic priorities involves defining the primary intended audience for BuddyPress. Traditionally, BP has tried to balance the flexibility and power demanded by developers and site builders with the simplicity and out-of-the-box functionality desired by end users. In the upcoming releases, BuddyPress will be focusing increasingly on site builders and developers.

@djpaulgibbs: BuddyPress is used by many different kinds of people. We’ll improve BuddyPress by focusing on a narrower target audience: site builders and WordPress developers. This will cause many subtle but meaningful changes throughout the project. However, this is not a big change — it’s just an explicit recognition of what BuddyPress has become, and how people use it.

@boonebgorges: It will no longer be our #1 priority for BP to be 100% turnkey. We have often closed tickets and decided against certain features because we wanted to adhere closely to WP’s “decisions, not options” principle. This principle is designed to serve the non-technical owner who wants something as great as possible, immediately on activation. What the new ideas suggest is that we should embrace configurability a bit more. I think we can and should continue to strive to have a great out-of-the-box experience but we should be OK with deciding to emphasize the developer and site-assembler experience.

@djpaulgibbs The original tagline for BP was “a social network in a box”. It’s now become a set of tools or resources to let you ​build things with it. An example of more configurability/options that came up during discussion was https://wordpress.org/plugins/buddyextender In time I imagine all of those and more (like, the default option for select boxes for the filters on the Directory screens) would become contenders for inclusion in BuddyPress core.

@boonebgorges A general consequence of this reorientation is that we don’t have to say “plugin territory” as much because we are not tied to the idea of “no config screens”, “80% rule”, etc.

BP REST API and BP wp-admin screens

@djpaulgibbs: The two key strategic priorities for the project are the REST API and wp-admin management screens. These are the most important because, alongside the existing front-end templates, we’ll have 3 different “views” of BuddyPress data, empowering our audience to use as little or as much BuddyPress as they need, however they want.

Why there are two strategic priorities when front-end templates as a third view also mentioned: as @dcavins says, we already have those built, and we are building new templates now. It’s also the way BuddyPress has always been, which we’ll continue to support. But to attract new developers and new uses for BuddyPress, the REST API is pretty huge.

REST API is very important because it’ll expose BuddyPress data in a different way, and make it easy for developers to use that data to build anything. Like, mobile apps, JS-only React sites that don’t even use WordPress for templating (instead only as a data store), etc. In such cases where the front-end templates won’t be used, the REST API will provide a way to programatically update that data.

Also, the wp-admin management screens will let site owners manage that data, if they’re only using the REST API as a read-only data source. Providing shortcodes (#7159) will let people disable the front-end templating, yet still access BuddyPress data in their blog posts, or custom templates, etc.

BP REST API is being developed at Github – https://github.com/buddypress/BP-REST

bp-nouveau Template Pack

@djpaulgibbs: Our new template pack has momentum. Because the front-end templates will no longer have to be all things to all people, our template pack can be much bolder and more opinionated with our design choices.

Major strides have been made since the new template pack project launched last April 13 with @im4th at the helm with @hnla. You can help make the new template pack happen. Join us!

Meetings: Every Thursday at 19:00 UTC

Github Repository: https://github.com/buddypress/next-template-packs

BP Trac Component Maintainers

In order to move to the direction we want to focus on, there will be a post calling for component maintainers with tasks similar to WP core’s maintainers. An upcoming post will include more information for anyone interested.

Dev Chat

developer.buddypress.org (#6812) @tw2113 has set up a sample site at https://trexthepirate.com/buddypress/reference/ to get things rolling. @djpaulgibbs: “Once the theme is done and any custom plugins, Boone, John, or I will code review it, and push it out. We’ll then need to talk to meta and figure out how to run the initial import or parsing.” @djpaulgibbs created a new repository in Github at https://github.com/buddypress/developer.buddypress.org and @tw2113 has already uploaded a local copy for review.

A new API to manage single items navigation (#6534) Update: @boonebgorges has committed the awesome new nav API which replaces the old `bp_nav` and `bp_options_nav` system to trunk the day after the chat. Check out his illuminating commit message for particulars. This commit also fixes another trac ticket (#5103 Group slug and user’s subnav parent_slug trouble).

Group Types API (#6784) @boonebgorges got the consensus to ship the new Group Types API without a UI in the front end for the first release. Update: @dcavins has uploaded the patch to add a metabox in the wp-admin Group edit screen for changing group type per discussion in chat.

BP Users front.php (#6769) @im4th followed up on feedback for his patch. @hnla said that he will be looking at this. Update: @hnla has posted feedback and @im4th has uploaded a new patch.

Emails: Passing an email address to `bp_send_mail()` does not render `{recipient.name}` token (#7044) @rayisme has patch and unit tests. @djpaulgibbs has posted feedback and mentioned during chat that this would probably go into BP 2.5.3.

Emails: Allow a custom `unsubscribe` token to be set directly in `bp_send_email()` (#7045) @rayisme noted that this ticket can be closed in favor of #6932 (Emails: real unsubscribe functionality).

BuddyPress Embeds for activity, user profiles, groups (#6772) @im4th mentioned that there are problems with iframe within iframe, i.e., when one embeds a video in the activity stream then embed this activity in a post.

BP Template Pack Meeting

@im4th: will open a new task about the activity post form to summarize what he has in mind so that we can discuss it.

@mercime: Google spreadsheets with screenshots of pages with current UI and how we would address each one of the component pages … then attach images of screens addressed in the next-template-pack for comparison

@hnla: has a draft of basic outline on bpdevel (not for publication at this time).

Use the Github repo Wiki pages for documentation

Review some wireframes made by @karmatosed in 2012 which already have feedback from the community as shown in BP Trac, bpdevel, and Github. We have to decide whether any of those can still be used or whether it would be better to make new wireframes.

Dev Chat, April 27

A new API to manage single items navigation (#6534) @im4th has patch. Dev feedback requested. “The patch is replacing nav arrays with a new class. and make sure the nav is attached to an item ID. The user id for the displayed user nav or the group ID for the current group. Group nav and displayed user nav are separated – meaning there are no more slug collisions.” @boonebgorges and @im4th had a long discussion on the implementation in this Slack log. @im4th and @rayisme have uploaded patches after the meeting.

Dev Chat, May 4

A new API to manage single items navigation (#6534) @boonebgorges will be checking out the progress and at “how much we need to support old ways of reaching into the `bp_nav` and `bp_options_nav` globals and spending some time formalizing the various compatibility breaks with unit tests” Update: @boonebgorges has uploaded a new patch with unit tests.

Audit all DB fetch methods to return integers where appropriate (#6977) @rayisme has patch. Work on this is about 90% done.

bp_send_email function not working with numeric string for $to argument (#7042) Will leave decision of ticket status to @djpaulgibbs.

BuddyPress Embeds for activity, user profiles, groups (#6772) @rayisme requested feedback on the display of the embeds in the template as well as the embeds template. Update: @mercime has posted feedback and @im4th has uploaded revised patch.

Screen notifications settings page (#6712) @rayisme: “I need to refresh #6712. @djpaulgibbs‘ feedback in the ticket was quite helpful for future iterations. I’m not sure if this can make 2.6 or not.”

Use WP page names for BP directory pages headings (#6765) Discussion between @hnla, @johnjamesjacoby, @im4th, and @boonebgorges resulted in the decision that this enhancement would require an migration for existing installations when they upgrade while new installations will get the shorter page names.

BuddyPress Style Modules: @hnla has provided the example one so it’s clear how they work and are formatted etc. at https://github.com/hnla/style-modules/tree/master/members-list-module. Update: A new Style Modules repo has been added to the BuddyPress account at https://github.com/buddypress/style-modules

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

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

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.

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.

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.”

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.

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.”

@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.”

Trac Tickets

Group Types API (#6784). Has patch from @mamaduka. @boonebgorges would like to see the patch for the proposed Group Type UI before proceeding with the review.

Activity post form template improvements (#6680). Has patch. “The main template changes in the activity form ticket is markup changes for the placeholder and some new hooks. The rest are CSS/JS related,” @rayisme mentioned. @djpaulgibbs noted that the enhancement would break backward compatibility with themes. On another note, even if this new enhancement was used in a new bp-template-pack, this would (potentially–we’re not certain, yet–see “homework” below) break backpat with some BP plugins.

Discussion then ensued about what constitutes “breaking backpat issues” – HTML/style enhancements or JS/break functionality of BP plugins or both – which prevent or halts adding new enhancements to BuddyPress. @dcavins then said, “The activity stream/post box was mentioned in the BP survey results last year, and some of the alternatives were pretty impressive. I don’t want BP to fall far behind on key UI/UX bits.”

Homework (for whoever’s interested): Try the patch in #6680 [with BP plugins and themes -Ed.] so we can revisit next week with surety in our hearts about the way forward.

Route /me/*/ to /members//*/ (#6325). Has patch by @dcavins. @djpaulgibbs noted that a decision should be made on where the redirection should be done. @boonebgorges has since commented in ticket to handle redirect in a callback function via new action/filter hook.

Framework for bulk data handling after updates (#6841) @boonebgorges: “I’m most concerned about upgrade flow, and how it affects the technical infrastructure. From my experience, people are afraid to click upgrade DB buttons. You can blame WC for that :)” From @imath: “A lot of users are not backing up their DB before a plugin upgrade, i think we should inform them to do it and then let them click on a button to launch the routine.”

“Since it sounds like we want to require user action here, I think we should just start with an existing UI – doesn’t matter which one (bbPress, imath’s, whatever) and use it as a framework for talking about database locking, batch processing, etc. Migrations probably need to have a UI if only to report any errors. If we ever want to migrate activity favorites (or anything else) to generic relationships, that’s another use case. Anyway, I think we should start with an existing AJAX-based UI because they already exist, and we should solve some of the other problems first,” per @boonebgorges.

Behat for BuddyPress. @djpaulgibbs reported, “There is no documentation. This is annoying. That is all.” @boonebgorges linked to an article about Codeception, a possible alternative.

BuddyPress 2.6.0 Schedule

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.

BuddyPress Work Parties née Bug Fixin’

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.”