In accordance with our WP…

In accordance with our WP compatibility policy, BuddyPress 2.8 will require WordPress 4.3. See

#2-8, #wp-requirements

Committer updates for BuddyPress 2.8

For the 2.8 dev cycle, we’re pleased to announce that three contributors will be joining us as guest committers:

  • Slava Abakumov (slaFFik) is the BP 2.8 release lead. He’s a longtime contributor to the BuddyPress project, where’s he’s had an especially notable impact on improving internationalization and extensibility.
  • Stephen Edgar (netweb) will be joining the team to focus on build/test tools. He is a member of the bbPress team, and plays an extensive role maintaining build tools for bbPress, BP, and WP.
  • Laurens Offereins (Offereins) has been contributing to BuddyPress since 2014. He’s been key in building out the Member Type and Group Type features over the last few releases, bringing a keen eye for spotting nasty bugs.

Congratulations to Slava, Stephen, and Laurens!

#2-8, #committers

Group queries have been rewritten for BP 2.7

BuddyPress 2.7 will introduce a number of major changes to the code that underlies group queries – specifically, BP_Groups_Group::get(). Most of these changes will be invisible to users and developers, but anyone using filters to modify the underlying SQL may experience backward compatibility breaks in certain cases.

The main motivator for the changes is performance. Over the past few releases, BuddyPress has been following WordPress in moving its object queries to the “split” model, where one query gets the IDs matching the query parameters, and the second query gets the objects corresponding to the matched IDs. Split queries are generally less memory-intensive, and make it easier to phase in various improvements to caching. The changes we’ve made for BP 2.7 should lead to a huge performance improvement on sites using persistent caching; when querying groups, not only are group objects now fetched from the cache when available, but the ID queries themselves are cached as well. See 5451 for more information.

All normal uses of the bp_has_groups() stack, including groups_get_groups() and BP_Groups_Group::get(), should be 100% backward compatible. Plugins that use the bp_groups_get_total_groups_sql or bp_groups_get_paged_groups_sql filters may require an update for BP 2.7 compatibility. Filter callbacks will break in the following cases:

  • The callback assumes the old comma-separated JOIN syntax: SELECT ... FROM wp_bp_groups g, wp_bp_groups_groupmeta gm1 .... The SQL now uses the more verbose JOIN syntax: SELECT ... FROM wp_bp_groups g JOIN wp_bp_groups_groupmeta gm ON ( = gm.group_id ) ...
  • The callback assumes SELECT * instead of SELECT id
  • The callback requires access to the groupmeta tables that were previously joined for ‘last_activity’ and ‘total_member_count’ (gm1 and gm2). These tables are now only JOINed during the main query when required by the type or orderby parameter. Access to the last_activity and total_member_count properties of group objects is unchanged.
  • The callback expects the second parameter – the $sql array – to have a specific format. Previously, the $sql array had keys that corresponded to various WHERE conditions, but the array was assembled haphazardly, and some values were not included. Now, the top-level items in the $sql array are the main clauses of the SQL query (‘select’, ‘from’, ‘where’, etc) and the WHERE conditions are grouped in the $sql['where'] key. If your plugin filters the SQL string conditionally – for example, when performing a search – you are encouraged to use the third parameter, the $r array of arguments passed to the query method, as the canonical source for query information.

In this comment, I outlined a list of plugins from GitHub and that may be affected by the change. If you see your name on that list, consider yourself pinged.

Though it shouldn’t result in any backward compatibility breaks (except in cases of odd type checking), it’s also worth noting that items returned from BP_Groups_Group::get() are now BP_Groups_Group objects.

Questions about the new query format, or how to make your plugin compatible with BP 2.7? Please leave comments in this thread.

#2-7, #5451, #groups

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

BuddyPress 2.5.3 is now available:…

BuddyPress 2.5.3 is now available:

In keeping with our WordPress…

In keeping with our WordPress compatibility policy, BuddyPress 2.6 will require WordPress 4.1. See