BP Dev Chat summary (June 26)

Updates about the Tickets into the 5.0.0 milestone

#8045 is achieved: we now have our very first core feature using the BP REST API. If you chose to use BP Nouveau as your template pack (it is the default template pack for new installs), your group administrators will enjoy a brand new interface to manage the members of their group(s).

The interface is more dynamic than our legacy one and Administrators of popular groups will probably love the search feature! Finding the specific member they want to promote, demote, ban or remove is faster than ever!

#6210 @dcavins is working on a new version of the patch to adapt it to play nicer with BP Nouveau & see how things will evolve with the BP REST API. He worked very hard 💪 🏋🏻‍♂️ so far and I believe he’s very close to achieve his goal. I think it’s a very promising feature that will first improve how we handle group invitations and soon give new opportunities for other objects such as sites of a network. I also think it’s an interesting way to test & review the group invites & requests BP REST API endpoints.

There are 7 tickets with patches. Feel free to help us: testing patches and confirming they do the job is a already a great help. If you can improve them: it’s even greater! If you don’t know where to start, read this comment about how to test BuddyPress patches.

#7156 is the master ticket for the BP REST API. @im4th (me 😄) has suggested a patch to include the BP REST API into the BuddyPress’ build process. It’s a first reply to the question we haven’t replied yet since our previous dev-chat: « How to include the BP REST API into the BuddyPress plugin package? ». Feedbacks are very welcome.

BP REST API focus

REST fields (~= BuddyPress Components metadata)

We still have work on this “field” 😅 I’ve submitted a pull request that is implementing them for a bunch of endpoints. @espellcaste: please have a look at it soon and commit if you feel like me & @boonebgorges the approach is good.

The xProfile REST fields will need an extra work as the meta table is a bit different: we can attach a meta to a data, a field or a group of fields. I’ve posted an issue about it with a suggestion to handle this specific case. I’ll update it with a new pull request to adapt the one I was talking about into the previous paragraph.

The current endpoint about Threads/Private messages is more sensitive imho. REST fiels are messages metadata not threads ones. FYI, I’ve been also exploring how to use the BP REST API into the BP Nouveau Messages UI. I think I will carry on because it’s a nice way to eventually improve it.

REST links

I think we need to harmonise their use, for instance in BP REST Activity, BP REST Groups, BP REST Members, the links should all include a filter to let plugins add custom ones if needed. There should be links for the Private Message object to transport the “star” link, and probably the links of the users involved into the message…

Documentation site about the BP REST API

Last but not least! Feedbacks are very welcome about the post I’ve published to share my suggestions.

Next dev-chat

It will happen on July 10th at 19:00 UTC in #BuddyPress slack channel. In the meantime: have fun contributing to BuddyPress 👍

#5-0

BP Dev-Chat Summary (June 12)

BP REST API

A huge work has been accomplished by @espellcaste 💪 so far from the feature as a plugin “BP REST” and we think the 5.0.0 release will be a good time to bring the REST API within BuddyPress core. As explained in #7156 it will introduce 14 BuddyPress endpoints and you’ll soon be able to play with activity updates, groups, members, private messages and extended profile fields using REST requests 🙌

8 other endpoints (eg: blogs, friends) will arrive in 6.0.0.

BP REST Documentation

As @boonebgorges said during the chat, this part is very important for us to help you build great BuddyPress plugins thanks to this new API. We’ve been looking for a nice tool to generate this documentation out of the endpoints schemas and we think we’ve found a good solution to start. We now have to put up a website to host this documentation. I’ll take care of sketching out the next steps of this site and @boonebgorges will be able to help for the domain name.

Let’s start using the API within BuddyPress core!

The best way to help you discover the BP REST API potential is to use it ourselves 😉. We plan to do so by improving how Group members are managed within the Group Manage screen (front-end) and the Group Admin screen (back-end). Below is a video demo to let you discover a bit early how it should look like on the front-end of your community site.

You can follow our progress from the #8045 ticket.

How to include the BP REST API into the BuddyPress plugin package?

We’ve been discussing about it for about 30 mins during the chat and we haven’t decided yet how this will happen. We have 2 options:

  • Carry on maintaining it from GitHub.com and include it during the BuddyPress plugin’s build process (that’s what we’re doing for BP Default & BP CLI)
  • Merge it into BuddyPress Core.

There are “pros” and “cons” for both options. For example, maintaining it from GitHub can be confusing for contributors because it adds a second place to report for this part of BuddyPress as @boonebgorges noted. It’s also problematic regarding the history of how the decisions were made: it would be “tied up in two places“. @espellcaste also expressed his preference, despite the fact working in GitHub is more convenient, about keeping things “in house” (we have less control about the future of GitHub). Finally @boonebgorges also explained we could keep it on GitHub for a couple of releases before bringing it home as “once we go Trac, we cannot go Back“.

Another relative point on this subjet: how plugins should behave if they are both activated?

  • Should the plugin BP REST take over BuddyPress ? Meaning all endpoints can be maintained from the GitHub repository.
  • Should it be BuddyPress? Meaning the BP REST plugin would only be used to develop the 8 remaining endpoints.

We agreed we still have time until the first beta release to decide, but if you have ideas or recommandations : please share them in comments 😊

About the 5.0.0 release schedule

We agreed on a first date : 5.0.0-beta1 will be released around August 15.

As discussed during the chat, it will give us the time to work on the documentation site and decide about the « BP REST API including » strategy.

It should also give us the time to clear the tickets list of the milestone, there are around 10 tickets left and you are very welcome to give us a hand testing or suggesting patches.

Until Beta1 we will have a dev chat every other Wednesday at 19:00 UTC in #BuddyPress. Here is the planning of our next meetings:

If you are going to Berlin to attend to the WCEU 2019: have fun, make good connections and learn great things! @johnjamesjacoby will be there, don’t hesitate to enjoy his conference 👌 and chat with him about BuddyPress 😍

You can also decide to give a hand to BuddyPress during this WordCamp thanks to the contributing area! We’ll be very happy to help from where we are 😁

#5-0

Nouveau – A BP Template Pack Story

Well a few further updates 🙂

Following on from our first introductory update The State of the BP Nouveau template pack we are happy to provide a little more insight into the ongoing development of this project.

Since that first update we have updated many files pushing some ~110 commits ~410 commits in total to date.

We have comprehensively re-factored and structured the directory layout and created many new include files. Styles are re-worked into a modular series of partial files representing two levels  – those that are called and compiled as the base styles and those that are unique to given TP & living in the TP directory.

The focus of the last couple of weeks has really been on template re-factoring, updating markup , improving semantics, adding or removing classes as required while working through screens updating styles. Updating visual styles also involves paying attention to  the structure and formatting of the files, looking at the nesting of rules (less depth allowed in lint rules) , attempting to ensure we have lighter files with selector specificity that’s lower and less troublesome to override and ultimately to hopefully compile css files that are a little smaller in kb.
Amongst other additions since last we wrote there have been:

  • Navigational user selected styles
    We now provide a vertical navigation selection for user object navs seen here

Nouveau Vertical Nav Menu

  • Additional styles for Navs or links exist too so we can have  a default subnav view or a tabbed look, the tabbed look  work as styles & classes  that can be dropped on most ul list links so we can use them on links such as the profile group links or the message screen links:tabbed-navsThese styles for tabbed navs work from classes to apply the styles in the same way the vertical navs function so in time we will add these to the customizer when we’ve worked out what elements benefit from the choices (apart from the obvious).

 

  • Messages gained a massive upgrade courtesy of @im4th as described in the last update further to this we have updated some of the markup for better semantics and tweaked the styling a bit for both the inbox messages listing & preview screen & single message thread views:

messages-inboxmessage-thread

  • All Nav elements in general have received a review and class tokens upgrade to try and make them a little more useful  and clear – gone is reference to ‘tabs’ unless they are specifically visually styled as such. Navs have had a round of default styling as a base line on which we can build out further styles and attention to some very simple screen widths so that we have something that will work for small mobile/tablet devices. small-screen-navs
  • On User screens we have looked at creating a more uniform approach and consistency to headings and simple explanatory text so for example on the user settings screens we have added headings and text to all screens so it’s clear exactly what your looking at, this process is replicated across all screens where required.

user-headings

  • Whats new textarea gets a tidy up of styles to compliment the work carried out by imath for both small and wide screen views.
  • General tables get a freshen up and font sizes managed for th/td cells.
  • BP Lists get attention for heading/meta font sizes & layouts for small / wide screens.
  • Update the Group Create steps screens, improves the markup and classes and pulls out the BP core steps navigation to include in nouveau template-tags file and adjusts markup.
  • Updates for mixins & scss variable files – improves color choices by variable reference, create more individual specific vars to allow changing of  more specific elements without changing all e.g $nav-hover: $dark-grey; allows $nav-hover to take a different color or var while another element can still use $dark-grey as set. Mixins get updates  for responsive text  to compliment the general font size mixin, this allows a value to be divided by a percentage on smaller breakpoints. New clearfix mixin allows clearfix rules to be added to an element fed as a param of the mixin. Add a variation of the messages box used in companion styles; this mixin allows backgrounds  and color to be passed to message element rulesets, authors can now override the defaults for border, background, color. Update our password strength warning colors for variable definitions rather than hardcoded hex.

Moving forward we have more templates to still run over and review for the best markup structure classes and of course a full and detailed review of accessibility improvements we can bring to our templates which @mercime will be tackling at a convenient moment.

@im4th is currently looking at the implementation of the template pack selector for core on this ticket :

https://buddypress.trac.wordpress.org/ticket/7157

As well as continuing to drive new and exciting functionality for bp-nouveau. (take a look at the proposal here for example: https://github.com/buddypress/next-template-packs/issues/64)

We encourage everyone to download and follow along with the development plugin, you can download from:

https://github.com/buddypress/next-template-packs/archive/master.zip

or of course checkout to your plugins local dev via git:

https://github.com/buddypress/next-template-packs.git

We have specific Template dev Chats on Thursdays @ 19:00 UTC on BP’s slack channel, please come along and provide feedback or simply follow along all and any participation is hugely welcome.

If you’re running the plugin and spot an issue or have an idea for an improvement then you can use BP’s issue tickets on the next-template-pack repo to report them:

https://github.com/buddypress/next-template-packs/issues

And last but not least please feel free to leave any comments or questions on this post and we’ll attempt to respond to them 🙂

 

Regards, the Template Pack Team.

 

Dev Chat Summaries for July 20 & 27, 2016

BuddyPress 2.6.2

  • Release date: TBA
  • There are currently 7 tickets in queue (3 closed. 4 open).
  • 404 errors when using HHVM on BP 2.6.1.1 (#7197) @rayisme has patch.
  • BP no longer filters wp_mail_from_name when using wp_mail() (#7024) @djpaulgibbs has patch. Might close this ticket.
  • @mentions break instagram oembeds if same username exists on site as instagram (#7084) needs patch.
  • Unit tests failing on PHP 7.0.9 (#7204) needs patch.

BP 2.7 Trac Tickets

Implement user capabilities for Activity component (#7176) @djpaulgibbs has patch. Feedback requested.

Groups: Draft, Locked or Suspended status (#6677) @dcavins has patch. Feedback requested.

Single items for the Blogs component (#6026) @im4th has patches. Feedback requested.

Hierarchical groups (#3961) @dcavins has patch. Feedback requested.

Components: BuddyPress.org Sites There are a number of tickets in Trac which need to be double-checked if the issues are still valid. If it is and you want to patch it up:
go svn co http://meta.svn.wordpress.org/sites/trunk/buddypress.org/,
create the patch, and upload the patch to the appropriate BP trac ticket.

Slack logs:
July 20: https://wordpress.slack.com/archives/buddypress/p1469041213000135
July 27: https://wordpress.slack.com/archives/buddypress/p1469646028000542

#3961, #6026, #6677, #7024, #7084, #7176, #7197, #7204, #dev-chat

BP 2.7 Kickoff Meeting – July 13, 2016

Project Schedule

  • July 13, 2016 – Kickoff – scoping/wishlist
  • September 21, 2016 – Beta 1
  • October 5, 2016 – Release Candidate 1 (string freeze)
  • October 12, 2016 – Target release date for BuddyPress 2.7

Release Lead for BuddyPress 2.8

Slava Abakumov Slava Abakumov (twitter) has been translating BuddyPress to Russian since October 2008 (long before the very first beta) and has submitted many BuddyPress plugins to the WordPress repository. He is a doting father, developer, and project manager, who also enjoys road-cycling and roller-skating. His motto is “Be good, have fun, create things”.

Congratulations @slaffik! 🙂

BuddyPress Leads in the Windy City

Watch out Chicago! @johnjamesjacoby, @boonebgorges, and @djpaulgibbs will be spending some time together at an undisclosed location in the city this Monday, July 18. 🙂

Images of BuddyPress leads - John, Boone, and Paul.

bbPress 2.5.10

bbPress 2.5.10 was packaged and released by @johnjamesjacoby Wednesday, July 13. This was a security release so please upgrade if you haven’t already.

Navigation API in Codex

@boonebgorges has posted a new article about the new Navigation API. Check out all the examples to help you with customizations.

BP 2.7 Scoping/Wishlist

BLOGS

CORE

  • Accessibility fixes for BP Admin screens and templates @mercime
  • Widget for logged-in user Notifications used in wp-toolbar (#7183)

DOCUMENTATION

GROUPS

MEMBERS

REST API@boonebgorges and @rayisme

TEMPLATES

  • Extract & relocate core markup functions @hnla

TOOLBAR AND NOTIFICATIONS

Though not mentioned during dev chat, following are a few of many interesting tickets which you might like to contribute to or kibitz about:

  • Merge BuddyPress Followers into BuddyPress Core (#7133)
  • UI to pick Template Packs (#7157)
  • Admin UI options for all template features (#7160)
  • Add #hashtag auto-suggest (#7165)

Slack log: https://wordpress.slack.com/archives/buddypress/p1468436417003180
(Slack account is required)

#3961, #6026, #6677, #6712, #6812, #7133, #7157, #7160, #7165, #7179, #7180, #7181, #7182, #7183, #dev-chat

Priorities for the Next 12 Months

Written by @mercime and @boonebgorges.

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.

Slack log: https://wordpress.slack.com/archives/buddypress/p1467831687002740
(Slack account is required)

#dev-chat

Dev Chat Summary for June 15, 2016

BuddyPress RC 1

@dcavins packaged and released BuddyPress 2.6.0 RC 1 (string freeze) last Wednesday, June 15, 2016.
* Developers: Please test your BP plugins and themes with our new features this dev cycle 🙂
* Translators: We need translators for BuddyPress. If you’re interested in contributing, @danbp has written a topic about how you can get involved.

BuddyPress 2.6.0

RC 1 Release Preparation

We discussed two tickets remaining in trac: moving stylesheet of activity embed to to bp-legacy’s /css/ folder (#7123 fixed.) and the Welcome Screen for 2.6 (#7108 fixed).
* Thanks to @im4th for preparing the video demonstrating BP’s new Activity Embed feature on our Welcome Screen.
* Thanks to @djpaulgibbs and @jerrysarcastic for facilitating the transfer of the video to WordPress.tv.
* And thanks @dcavins, @rayisme, and @hnla for improving the text of the Welcome Screen.

New Codex articles for BP 2.6

Thanks to @rayisme for publishing the following articles:
* Activity Embeds
* Group Types API

Improving Management of Trac Tickets

@djpaulgibbs will be implementing some changes to Trac over this weekend per his post here at bpdevel. @dcavins reminded all to comment on @offerein’s suggestions about BP trac ticket categories and focuses.

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

#7108, #7123, #dev-chat