PHP 5.2, BP 2.8, and PHP support guidelines


After a discussion with the other project leaders, I’ve just posted guidelines for BP’s PHP version support policy. You can dig into that document for the gory details. For the purposes of this post, here’s a summary:

  • BuddyPress promises full support for all versions of PHP supported by the PHP team (currently, 5.6.x and 7.0.x), and strongly encourages that all sites run a supported version
  • BuddyPress supports certain legacy PHP versions, until the cost-benefit ratio for supporting a given version suggests that it should be dropped

Spelling out that second bullet point. At the beginning of each dev cycle, we’ll decide as a team whether to drop official support for any legacy versions for the following major version.

Currently, we’re starting the 2.7 dev cycle, which means we’re making decisions about 2.8. Here’s the decision:

BuddyPress 2.8 will require at least PHP 5.3.x.

Why now?

Thanks in part to coordination between the WordPress core team and web hosts, PHP 5.2.x use has declined significantly over the last few years. The stats page tells part of this story. Under the assumption that a good portion of PHP 5.2 sites are old and unmaintained (and thus, from a practical point of view, unaffected by BP updates), the team provided us with some more specific numbers. Here’s a recent PHP version breakdown for sites running a version of BuddyPress greater than 2.0:

Unknown - 1.08%
5.2     - 3.23%
5.3     - 12.92%
5.4     - 34.44%
5.5     - 22.38%
5.6     - 23.02%
7.0     - 2.92%

The number of sites affected by dropping support for 5.2 is quite low, well below the informal 5% threshold sometimes mentioned by members of the WordPress and BuddyPress teams.

Coupled with these numbers is the recognition that PHP 5.3 introduced features that have a meaningful effect on our ability to write a modern PHP application: namespaces, closures, guaranteed access to SPL, late static binding, and so on. As BuddyPress aims to build a major new feature – a REST API – it frees us up significantly to be able to take advantage of these and other features unavailable in PHP 5.2.

Security and best practices

Why are we not bumping requirements all the way to PHP 5.6, the oldest version still receiving security updates? As indicated by the numbers above, this change would mean forcefully obsolescing nearly three quarters of all BuddyPress sites. For many (most?) people running BuddyPress, updating PHP is emphatically not a simple task. As such, we would simply lose these users, or cause them to stay on old and unsupported versions of BuddyPress. We support WP’s ongoing, progressive efforts to work with webhosts to move sites off of old versions of PHP.

It’s likely that anyone reading this site is already running a modern version of PHP on their sites and their client sites. But just in case: you are encouraged in the strongest possible terms to run a supported version of PHP.

What comes next

We plan to make a few changes in BuddyPress that will smooth the transition and decrease the possibility of people nuking their sites. See #7195 and #7196 for more details.

In accordance with our WP…

In accordance with our WP compatibility policy, BuddyPress 2.7 will require WordPress 4.2. See

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



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




REST API@boonebgorges and @rayisme


  • Extract & relocate core markup functions @hnla


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:
(Slack account is required)


The state of the BP Nouveau Template Pack

On april 13 we had our first “Template Pack” chat. After 4 months of weekly meetings (on thursdays at 19:00 UTC), we thought it was time to share with you what we’ve accomplished so far.

3 years ago, the very first BuddyPress Template Pack – BP Legacy – was introduced in Totonno (1.7). It was a major improvement. Thanks to the BP Theme Compatibility, BuddyPress can use the template parts included in this Pack and inject them into the wide majority of WordPress themes. Site owners or theme designers can override these template parts to customize the appearance of community sites. And, for sure, they are doing it!

BP Legacy will remain the most compatible Template Pack BuddyPress ever made!

But after 3 years, we are feeling like it’s time we try to improve the user experience and optimize markup, Javascript, CSS, Ajax, etc.. And very quickly we all agreed that this couldn’t be done in BP Legacy without taking the risk to have an impact on all the possible overrides site owners or theme designers did and are still doing. History showed that unfortunately some of them are not necessarly taking the time to synchronise their customizations with the adjustments we sometimes have to do to our template parts…😦 .

Moving forward with BP “Nouveau”.

In french “Nouveau” means “new”. If you’re thinking i’m the one who had the idea to call a new Template Pack this way, you’re wrong :) @rayisme is the one! But i must admit i love this name!

In BP Nouveau, we’ve decided to follow these guidelines:

  • Modularity in CSS, Javascript and PHP.
  • Think forward instead of being afraid of breaking backward compatibility.
  • Build modern UIs by always taking advantage of the latest improvements WordPress or BuddyPress core are introducing.
  • Ease of customizations for site owners and at the same time advanced techniques for theme or plugin developers.

About this last point, the first drastic decision we’ve made was to remove all do_action hooks from template parts! Some of you might be surprised as these kinds of hook are ways to extend or customize. It appears that after 47 commits it actually gave birth to very interesting improvements:

  1. We first introduced new APIs such as the BP_Buttons_Group class. As you know BuddyPress uses a lot of buttons and in Legacy there are a lot of these hooks to let people add their own buttons. Thanks to this new API plugin/theme developers can choose the exact position where to output their buttons!
  2. Two new template hierarchies appeared (one for each single item object BuddyPress is using). For instance, it’s now possible to have a different activity stream layout for any member/member type or any group/group type.
  3. Template parts have been optimized. The huge groups/single/admin.php has been split so that we can now share some template parts between the Group’s create screens and the Group’s edit screen. The xProfile visibility is now a specific template part that is used by the xProfile edit screen and the signup screen. The WP Profile template we fallback on when xProfiles is not active stopped using old yim/aim/jabber fields in favor of a new loop using the wp_get_user_contact_methods() function so that potentially any new contact methods can be added. Finally The registration template has been completely revamped.
  4. New template tags have been created such as the one to generate standardized template notices and user feedbacks which can also contain “dismiss” buttons.

A BP Template Pack customizer panel.

Site owners will be able to customize their community and preview their changes thanks to the WordPress Customizer.  For instance, they can choose to use our default front pages for groups or members and they can choose between 4 layouts for the Members, Groups and Sites directory loops. Take a minute to discover this last feature in the following video.

They will also be able to reorder the Groups and Members primary navigations according to their preferences!

Improved UIs

First the notifications screens is now using Ajax and we’ve added a search functionality and the possibility to filter notifications by component actions. Of course we’ve kept the sort by date ordered DESC or ASC but it’s now located into the Date Received column header a bit like it’s the case in WordPress administration tables.


Then i invite you to watch this 3 minutes video to discover our new Group Invites and our new Private Messages UIs.

Finally we’ve started to work on a new extendable Activity Post form:)


BP Nouveau is only loading what the BuddyPress setups it’s activated on needs. For instance if the Groups component is not active all the corresponding Javascript and PHP code won’t be loaded. SCSS files are now organized into modules.

Getting involved.

You want to help? You are very welcome. To ease our work we’ve packaged the template pack into a plugin we’ve named “next-template-packs”. It adds a new tab into the BuddyPress settings so that it’s easy to switch between BP Legacy and BP Nouveau. In a way it’s a possible interesting start for this core ticket (#7157). You’ll need the latest WordPress version and the latest BuddyPress version (trunk). Here’s the url of our github repository, we would be very pleased to receive some pull requests😉

Let’s build together the most customizable Template Pack BuddyPress ever made!



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 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 –

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:

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:
(Slack account is required)


I’ve just committed the patch…

I’ve just committed the patch in to trunk/2.7. It’s an enhancement to grunt patch to allow you* to upload patches directly to a Trac ticket, and also to download a Github pull request and apply it as a place. See the commit message for instructions.

*Only BuddyPress Trac admins and bug gardeners have access to upload patches in this way.

BuddyPress 2.6.1 is now available

Check out the blog post on for more info:

BuddyPress 2.6.1