BP Codex Summary for 2017

Status Update

There were 2 BP major releases (2.8.0 and 2.9.0) and 12 minor releases by the all-volunteer BuddyPress contributors in 2017. These activities have generated the following updates for the codex to date:

2 New Articles
14 Release Change Logs
32 Articles Updated

The Codex in 2018

Here’s hoping that barring major technical glitches or hidden grinches, developer.buddypress.org will be launched sometime this year. We’ll be reorganizing and adding articles to the Codex as some sections will be moved to the developer reference site. Details of the changes will be posted here and we’ll be asking for your feedback and support.

Help us improve the BuddyPress Codex. If you’re interested in updating existing articles or creating entirely new ones, please read our Codex Standards & Guidelines and let us know via the #buddypress Slack channel or in comments below.

Props to Codex Contributors, 2017

Many thanks to everyone who contributed new articles / updated published posts from January 1 – December 31, 2017!

Real-world testing of BuddyPress WP-CLI commands

A few years ago, I started a wp-cli-buddypress project. I occasionally added commands that were useful to me personally, but didn’t pretend to have anything close to complete coverage. A few months ago, Renato Alves (@espellcaste) contacted me to see whether he could help flesh out some of the missing commands. We moved the repo to the official BuddyPress GitHub account https://github.com/buddypress/wp-cli-buddypress, opened a BP ticket to track the potential integration of the commands into BP itself https://buddypress.trac.wordpress.org/ticket/7604, and got to work.

Since that time, Renato and I have done extensive work to bring basic CLI commands to all the main components of BuddyPress. Specifically, we have CRUD commands for all major content types, as well as a few helpful utility methods. The list of supported commands is too long to list here – you can explore by typing <code>wp bp</code> and digging down through the tree – but here’s a very brief summary:

  • activity – CRUD commands, comment management, favorite management, spam/unspam
  • core – Component activation and deactivation
  • group – CRUD commands, member listing and management, invitation management
  • member – bulk generation
  • signup – CRUD commands, activation, resending
  • tool – commands for running any BP repair tool
  • xprofile – CRUD commands for groups, fields, and user data

While there’s more to build – and refinements to be made – we’re at a point where we need real-world testing and feedback. If you are a BP developer, or administer BP-powered sites, and if you use WP-CLI, please install wp-cli-buddypress today and start using it.

There are numerous ways to install a wp-cli package, but because this one is in development, we encourage you to get a repo checkout. Something like:

$ git clone https://github.com/buddypress/wp-cli-buddypress ~/.wp-cli/commands

and then add the path to wp-cli-buddypress/wp-cli-bp.php to the commands subsection of your wp-cli config file https://make.wordpress.org/cli/handbook/config/#config-files.

Questions to consider while using the commands:

  • Are the commands named in a way that makes sense? Note that in some cases, commands have aliases (eg wp bp group create and wp bp group add).
  • Think about argument patterns across the commands, and whether they are consistent and make sense. Some commands take certain positional arguments (wp bp group get my-group) while others require named arguments (wp bp xprofile data get --user-id=5 --field-id=10)
  • What major features are missing?

For specific issues, you’re encouraged to open a GitHub ticket: https://github.com/buddypress/wp-cli-buddypress/issues. For high-level discussions, you can open a GitHub ticket, leave a comment here, or drop into the #buddypress channel on wordpress.org Slack.

And for the truly intrepid: Contributions are encouraged! We’ve worked hard to ensure 100% Behat test coverage, which makes writing new commands fun.

#wp-cli

BP 2.9 Kick-Off Meeting – March 22, 2017

BP 2.9 Scoping/Wishlist

bp-nouveau Template Pack

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

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

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

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

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

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

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

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

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

BP REST API

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

BuddyPress.org Redesign

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

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

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

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

Dev Chat Schedule

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

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

#bp-nouveau, #dev-chat

REST API (re)kickoff meeting: Tuesday, December 13

Hey, remember REST API endpoints? Let’s build some for BuddyPress.

We’ll be holding a one-hour discussion to reignite the BP REST API project, at 1900 UTC on Tuesday, December 13, in #buddypress on Making WordPress Slack. A rough agenda for the meeting is as follows:

  • What work has already been done on building endpoints? See eg https://github.com/buddypress/BP-REST
  • Assuming that we can’t build every endpoint at once, how should we prioritize? Some possible topics for discussion:
    • Which component is most representative of BP content, such that we should use it as a blueprint for other component endpoints?
    • Do we start with read only, vs read-write? How does the authentication problem affect this question?
    • Where can we start using the API in BuddyPress itself? bp-nouveau? The Dashboard?
    • What are some other projects that might serve as prototypes for the API in progress?
  • What kind of architectural planning needs to happen before we can start building? Things to think about:
    • Certain actions, such as the CRUD actions, are common to various BP content types. BP core functions are not always consistent in naming conventions about them (‘insert’ vs ‘create’, etc). Here we have a chance to standardize.
    • We should strive for a consistent parameter vocabulary across components. For example, if you pass a user_id parameter to bp_has_groups(), you get a list of groups of which the user is a member. But if you pass a user_id parameter to bp_has_activities(), you get a list of activity items created by the user. What concepts are shared across the components?
  • What kind of model for development and integration into BP core should we pursue? How much do we try to develop as a plugin before merging?
  • Who’s in? 🙂

This is more than we can solve in a single session, but it should give you some ideas of the questions we ought to think about before we dive into crushing code.

See you next Tuesday!

Call for Components Maintainers

All the BuddyPress development takes place in Trac. All the tickets, most of the feature discussions and confirmed bugs, are all managed via Trac. For better tickets management, we use milestones, components, keywords and other ways to categorize everything. So far we have 24 components:

Component Tickets Maintainer
Activity 87 @lmoffereins
Administration 17  @slaFFik
Blogs 15
BuddyPress.org Sites 26
Build/Test Tools 8 @netweb
Core 157 @boonebgorges
Emails 17 @djpaulgibbs
Extended Profile 58 @lmoffereins
Forums 6
Friends 9 @henry.wright
Groups 58
I18N 10 @slaFFik
Media 13
Members 32 @espellcaste
Messages 16
Navigation 2
New User Experience 2
Performance 4
REST API 2 @espellcaste
Registration 6
Route Parser 7 @boonebgorges
Settings 4
Templates 55  @hnla
Toolbar & Notifications 22

WordPress (as well as some other OSS) uses an interesting approach where a person or a group of people are responsible for a specific component of a software project. The contributors have a specific interest in their chosen component, and enjoy or see the need to focus most of their contribution time on it.

In the long run, this helps that contributor quickly triage tickets in their preferred component, as they specialize in it and build up a knowledge advantage. The overall project benefits by faster review and prioritisation of new tickets.

I propose to implement BuddyPress component maintainers, with the hope that this will help move development even further and faster.

Some components, like Activity, Extended Profile, and Groups, need special love, as the number of tickets there is 50+. These components will benefit from having multiple component maintainers assigned to them.

Component maintainers don’t need to do anything special – just consider reviewing Trac tickets for your component, when you have a will and time to contribute to BuddyPress. You will be expected to look through all existing tickets, as well as new ones, provide feedback and help the larger project prioritise bug fixes and new features.

If you have any thoughts about this, or want to volunteer to become a component maintainer – please write in comments. And remember, it’s good to have several people per component, so join in even if you see someone’s mentioned your favorite component!

#buddypress

General Summaries for May 11, 2016

This post covers the BP Template Pack meeting @ 18:00 UTC and Dev Chat @ 19:00 UTC along with the upcoming BP 2.5.3 and BP 2.6.0 releases.

BP Template Pack

Participants: @dcavins, @im4th, @hnla, and @mercime.

  • @im4th: created a new ticket for the Activity post form for the new Template Pack currently hosted on Github
  • @hnla: added some preliminary notes in the Template Pack Wiki
  • @im4th:  already using Ajax actions returning JSON replies.
  • @hnla: requested that for this new pack or new templates, “please, please, no mention of backpat as it concerns us not, it’s a dirty word and we don’t suffer it for this project.”
  • @dcavins: we should focus on the Messages screen and the Activity Post form for next week.
  • @im4th: with this new template pack, an important thing will be to check we’re accessibility-ready and include this in the roadmap.
  • @mercime: a new Template Pack Trac Ticket for good fortune when ready.
  • @dcavins proposed a weekly meeting to step up discussions. This was seconded by the other participants.

Next meeting: Wednesday, May 18, same time (18:00 UTC), same #buddypress Slack channel (Slack account is required).

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.

Upcoming Releases

BuddyPress 2.5.3

  • There are currently 5 tickets slated. (Closed: 2. Active: 3.)
  • Release Date: TBA

BuddyPress 2.6.0

  • There are currently 95 tickets slated for this dev cycle. (Closed: 56. Active: 39.)
  • Beta 1: May 25, 2016
  • Release Candidate 1 (string freeze): June 8, 2016
  • Release Date: June 15, 2016

#dev-chat

#5103, #6534, #6769, #6772, #6784, #6812, #6932, #7044, #7045, #buddypress

General Summaries for April 27 – May 4, 2016

This post covers the following meetings:
1. BP Template Pack on April 27 @ 18:00 UTC,
2. Dev Chat Summary on April 27 @ 19:00 UTC, and
3. Dev Chat Summary on May 4 @ 19:00 UTC.

BP Template Pack Meeting

Participants: @dcavins, @hnla, @im4th, and @mercime

  • @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.
  • Process: Discovery -> Design -> Development -> Launch.

Next meeting: Wednesday, May 11, same time (18:00 UTC), same #buddypress channel in Slack.

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.

BP Users front.php (#6769) Kudos to @im4th from @rayisme and @boonebgorges for the mystery group avatar. @dcavins and @hnla said that they will test the patch and post feedback.

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.

BP Users front.php (#6769) @im4th has patch. Positive feedback during dev chat, testing welcome.

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

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

#6534, #6765, #6769, #6772, #6977, #7042, #buddypress, #dev-chat