Paul Wong-Gibbs 3:33 pm on November 12, 2014
Tags: WCSF   

At #WCSF, some attendees of…

At #WCSF, some attendees of the community summit/working days spent time discussing BuddyPress 2.2 and plans and ideas for the future. We’re pleased now to share our notes from our conversations, below.

(These notes are high-level summaries of our conversation, and should not be interpreted as a firm roadmap or as a promise of any functionality for any particular future release — but it should help you align your expectations with ours.)

Thanks to Rocío for help with taking notes. 🙂

Present: John James Jacoby, Boone Gorges, Rocío Valdivia, Ben Hansen, Paul Gibbs.

Blogs component

  • We like the existing integration into user profile (blogs you’re part of).
  • We should add integration into groups (aka the groupblog plugin).
  • Discoverability of blogs is hard to do because of limited info from WP, and of likelihood of integration of external tools for sites that try to do this (e.g. elasticsearch).
  • Rename component away from “site tracking”.
  • Directory:
    • add blavatar. (avatars for blogs)
    • there are some minor improvements/tweaks we can make to the template.
    • add a “subscribe to blog” button and show it perhaps in a user’s activity stream, or on a new profile tab.

Talking about a “subscribe to blog” button led on to a discussion about how most of the current Blogs’ component functionality (apart from the Directory) is actually powered by the Activity component:

Activity component

Should we have some kind of “subscription component” instead of the existing Blogs + Activity components’ integration?

  • What dependencies would Subscriptions have on Activity? What disappears if Activity is disabled; what does Subscriptions look like?
  • We don’t want to duplicate the data storage structure of the Activity component.
  • How would another plugin integrate into Subscriptions? In terms of API, data required by it.
  • Would Subscriptions required a new DB table?

We eventually discovered a way that we think this could work:

  • A Subscription is an Activity item! (referring to how the data is stored, and not duplicated).
  • Subscription component “entry points” are hooked on relevant Activity actions (e.g. do something when a new blog_post activity item is created).
  • The Subscription table would only have a few columns containing IDs (making it a “pointer table”): auto-inc primary key, user id, primary activity item ID, secondary activity item ID.
  • Think of Subscriptions as some kind of router for handling changes made by members: [event] -> subscription router -> output (email, notifications, etc).
  • Add a UI: “when a new blog_post item is created, notify that to me via Private Message and Email only (no toolbar notification)”.
  • If a Component uses the Activity Component, that Component gets Subscriptions integration for free.
  • If a Component doesn’t use Activity (e.g. Private Messages), we can integrate into the Subscriptions component by using actions/filters.
  • Subscriptions component probably becomes mandatory to avoid breaking notifications when turning it off.
  • The existing “Notifications” component (the toolbar drop-down and user settings) would probably need to be re-written so it can be powered by the Subscriptions component, but we’re too far away at this point to understand exactly what this looks like yet.

User types

Types of users, e.g. “Free”, “Paid”, “Guest”, etc, are very popular in BuddyPress sites, and we should find a way to build this into core.

  • We need to store the “user type” setting in user meta, not xprofile. xprofile is not for settings.
  • In terms of API for developers, “something like bp_register_user_type(), which would magically create a couple pieces of UI in BP, would be supported by an additional param in BP_User_Query, and could be used by plugin authors”.

User data privacy

We discussed roles/caps/filters again, and problems/complications around using those. No immediate plans were generated from the discussion, we need to carry on gradually adding (and auditing our existing) custom capabilities. Eventually we can build more on this.

Attachments

  • API improvements around handling media (specifically avatars) are long overdue.
  • No appetite for a “photo album” component in core at the moment, but our new APIs should be built to let other plugin developers build one “easily”.
  • We want to overhaul/rebuild the user avatar upload process/cropper/management etc as a first step for a UI change directly related to media. Clean-Cole has begin to do some refinement based on prior work by Mathieu Viet.

Relationships (database cardinality)

  • Our existing tables (and WordPress) only support a one-to-one relationship schema, which makes querying for certain types of data expensive, inefficient, and hard. scribu’s “posts2posts” is a popular plugin that adds this kind of new table to WordPress.
  • Should we add this kind of table and API to BuddyPress? Yes.
  • It will let us do a lot of things we have been avoiding for a while. It’s going to be really powerful.
  • Once built, let’s try to migrate Activity Favouriting (bookmarking) to it as a first step.

Networks

  • Improving support for multiple networks running on 1 multisite/network installation, possibly including a UI to see networks similar to how Blogs works now.
  • Improving cache bucket handling and definition of global/network/site buckets.

Other

  • Smaller-scale discussion was had regarding the i18n BuddyPress sites (e.g. es.buddypress.org) and how we can make them better.
  • There was a discussion about integration with WordPress’s upcoming REST API (with Ryan Fugate and Bronson Quick). We’ll post additional notes about these things in due course.