Bonjour, Nouveau – An introduction to the next template packs

The bp-nouveau team has spent more than a year working on the new template pack. As someone who hasn’t been deeply involved in the project, I wasn’t sure how to get the kind of high-level view needed to assess why a new template pack – and Nouveau in particular – is needed. So I figured I’d do some research and write up my findings, in the form of a pitch: Here are the problems that Nouveau aims to solve, and here’s how it solves them. With Hugo’s help, I’ve done just that. I hope this’ll be a helpful tool for the larger BP community to understand and to get excited about Nouveau.

 

The state of BuddyPress templating

One of the marquee features of BuddyPress 1.2 (alongside the Activity component and single-WP support!) was the new BuddyPress Default theme. The year was 2010, a time fondly recalled by lovers of jQuery-powered animations and background gradients. BuddyPress 1.7, released in 2013, boasted theme compatibility: headers, footers, and other boilerplate was to be provided by regular WordPress themes, while BP-specific markup was provided by a set of templates bundled with BuddyPress. The templates were called bp-legacy, indicating that they were derived about 90% from the older bp-default, and with a nod toward a future where bp-legacy was, in fact, relegated to legacy status.

That future has arrived more slowly than one might have hoped. Designing and building a new set of templates that’s worth shipping means revisiting BuddyPress with a fresh set of eyes – from the perspective of both users and developers. Given what we know about the social web in 2017, and given the nature of the sites that we know are built using BuddyPress, how best can we present BP-generated content like groups and profiles? Given the last seven years’ experience customizing and maintaining BP-powered sites, what have we learned about the features of template markup, CSS, and JavaScript that strike a balance between simplicity and ease of customization?

 

Bienvenue Nouveau

The BP Nouveau project attempts to address this problem with a new template pack meant to replay bp-legacy as the new default for BuddyPress installations. Nouveau has been written from scratch, to reflect modern aesthetics and conventions. Let’s look at some notable features of Nouveau, and the thought behind them.

Developer-facing and technical improvements

  1. Modular, modern JavaScript

    The problem: bp-legacy’s monster global.js file determines nearly all front-end functionality for BuddyPress. The single file makes it extremely difficult to override or modify individual bits of functionality. And the code itself is the result of 7+ years of accreted jQuery-based spaghetti, which has proved to be somewhat fragile and difficult to maintain.Nouveau’s solution:

    1. The theme JS has been completely rewritten. Component-specific functionality is split into separate files: https://github.com/buddypress/next-template-packs/tree/master/bp-templates/bp-nouveau/js
    2. Nouveau heavily leverages Underscore.js and Backbone. Backbone, which is designed to work with data collections, is a natural match for BP interfaces like the activity stream and the message inbox. These libraries are widely used in the WordPress Dashboard, making the technology familiar to WP developers.
  2. Markup built for the contemporary web

    The problem: Most of bp-legacy’s markup predates the conventions of modern site building. HTML5 conventions and accessibility features have been tacked on rather than part of the initial design. Conventions like CSS selectors have not been consistent through the history of the project, causing conflicts with other applications.Nouveau’s solution:

    1. Markup has been rewritten to conform to semantic best practices, including proper element and selector use.
    2. Accessibility and compatibility with modern/mobile browsers is taken into account.
    3. Naming conventions are more consistent across templates.
  3. More minimal styling for better theme compatibility

    The problem: When bp-legacy was first conceived, it inherited all the highly opinionated styles of bp-default. Through a concerted effort, bp-legacy themes were “anonymized” over the course of several releases, so that fonts, form styling, and other conventions would be inherited from the WP theme. But the nature of bp-legacy’s markup and styles meant that a significant amount of additional styling was needed to fit nicely into WordPress’s default Twenty themes.Nouveau’s solution: The improved markup and styling has been written with an eye to universality. Elements are designed in such a way that they more elegantly inherit styles from the theme. This reduces the need for custom stylesheets when embedding in an existing theme, and reduces – or perhaps eliminates – the footprint of “companion stylesheets” in BuddyPress itself.

  4. More consistent and flexible PHP template functions

    The bp-legacy templates have evolved numerous techniques for adding navigation and action items that are often clever but also quite inconsistent. Some elements are invoked from directly within templates, while others are added via action hook. Some template functions make hard assumptions about the output, while others offer flexible parameters.Nouveau attempts to smooth these differences by introducing new template functions aimed at providing the greatest amount of flexibility for theme developers. Functions like bp_nouveau_activity_entry_buttons() and bp_nouveau_activity_comment_buttons() have rich function signatures and robust filters to allow for maximal control over these types of elements.

 

User-facing and front-end improvements

  1. Customizer compatibility

    The problem: bp-legacy predates the Customizer, so that any theme modifications had to be hardcoded in child themes, requiring a WP developer – or at least CSS knowledge – to make minor modifications.Nouveau’s solution: The behavior of a Nouveau-powered site can be modified extensively via the Customizer, including group/member front pages, the order of nav items, and one/two column layout selection. The integration provides a framework for more extensive Customizer functionality in future versions of BuddyPress.

    Screenshot_2017-04-05_11-13-30.png

  2. Better differentiation of content types

    The problem: bp-default and bp-legacy used mostly identical markup, styling, and design for different content types. Group directories and profiles looked exactly like member directories and profiles, and so on. This similarity leads to a tendency for confusion when new users approach BP, and it makes BP-powered sites feel less engaging and exciting by blending together fundamentally dissimilar types of content.Nouveau’s solution: Using the Customizer, site admins can select between various built-in layouts for content directories. For example, group directories might be distinguished from member directories by the former to a two-column layout but the latter to one-column.

  3. A rethought Messages component

    The problem: bp-default’s Messages interface felt like an afterthought, a tool for sending private messages that is somewhat slow and difficult to use.Nouveau’s solution: The Messages interface has been totally redesigned, leveraging Backbone and other JS technologies to feel more like a fast, highly responsive single-page app.

    Screenshot_2017-04-05_11-31-14.png

The future of Nouveau and bp-legacy

The current proposal is to merge Nouveau into BuddyPress. New installations of BP will have Nouveau activated by default. Upgrading installations of BP upgrading to will keep bp-legacy. A new admin tab will provide site admins with a UI for toggling between the two template packs.

Bp-legacy will continue to be actively maintained for at least a few more major releases. At some point in the upcoming six months, we’ll come up with a phased deprecation plan, describing a set of dates when bp-legacy will no longer receive new features, will no longer receive minor bug fixes, and so on.

#bp-nouveau

BuddyPress 2.9 will require WordPress…

BuddyPress 2.9 will require WordPress 4.4 or greater. See https://buddypress.trac.wordpress.org/ticket/7474 and https://codex.buddypress.org/getting-started/wordpress-version-compatibility/.

hnla and BP 2.9

The intrepid Hugo Ashmore – better known as @hnla around these parts – will be the official release lead for BuddyPress 2.9. Hugo is a longtime member of the BP community, playing a key role in the forums, on the Codex, on our WP theme companion stylesheets, and generally keeping us honest. Thanks, Hugo!

BP 2.8.2 security release

BP 2.8.2 is now available, and is a security release for all versions: https://buddypress.org/2017/03/buddypress-2-8-2-security-release/

BP 2.8.1

2.8.1 is now available https://buddypress.org/2017/02/buddypress-2-8-1-maintenance-release/

BP 2.8.0 RC1

2.8.0 RC1 is now available: https://buddypress.org/2017/02/buddypress-2-8-0-release-candidate-1/

#2-8, #rc

REST API chat summary – December 22, 2016

Slack log: https://wordpress.slack.com/archives/buddypress/p1482426116001568 (at the time I’m writing this, there seems to be a Slack bug that’s causing a 30-minute gap in the log)

Present: boone, codeart, chetansatasiya, chiragpatel, rekmla, ckchaudhary, espellcaste, offereins, modemlooper

I started with a couple discussion topics for moving toward our inital members endpoints:

  1. We decided that xprofile data will be available (and updateable) via the /members/ endpoints. So the member schema will have something like an xprofile_data property, which will be an array of fields and their data. For performance, we’ll explore having a parameter that allows the client to specify the xprofile fields that should be return in a request (or to disable them altogether).
  2. The /members/ routes will have full CRUD endpoints, even when those endpoints are totally redundant with WP’s corresponding users endpoint. This is specifically the case with DELETE.
  3. Avatar URLs will be available as part of the default member object. We’d like to explore the ability to create and update avatars via the API, but this will be a parallel project that shouldn’t block the members endpoints. (Avatar creation will require some discovery mechanism for clients to determine the proper size/aspect ratio, and will require the client to handle crop/resize, at least in the first implementation.)

codeart and chiragpatel will spend some time over the next few weeks collaborating on a first pass at the endpoint controller and the data schema. Our next meeting will probably be during the first week of January, depending on progress; a time will be announced next week.