WP version compatibility guidelines

Growing out of some discussions between team members over the last year or two, along with some musing on https://buddypress.trac.wordpress.org/ticket/6258, I’ve drafted a page explaining our WP version compatibility guidelines: https://codex.buddypress.org/wordpress-version-compatibility/ I’m sure that anyone reading this site always runs WP bleeding on their sites ;) but if you have any thoughts on these guidelines, please feel free to comment here.

On a related note, BuddyPress 2.4 will require WP 3.8. We will no longer actively build workarounds for WP < 3.8, and 3.7 will be removed from our Travis matrix (3.6 was already untested – 3.7 was when the /src transition took place). See https://buddypress.trac.wordpress.org/changeset/10031 and https://buddypress.trac.wordpress.org/ticket/6258#comment:9.

#travis, #wordpress

BuddyPress 2.3.2

BuddyPress 2.3.2 is now available. Go get it! https://buddypress.org/2015/06/buddypress-2-3-2/

Member Type API

BuddyPress 2.2 will introduce the basics of a Member Type API. The primary goal of the API is to provide a common framework for the storage and retrieval of arbitrary member types, a common task on BuddyPress sites. See #6006 for more background.

The new Member Types page on the BP Codex outlines the details of the API, so that developers can get acquainted with the new tools.

In BuddyPress 2.2, BP will provide native support for a number of features beyond the mere fetching/storage of member type data. When BP detects that member types have been registered by a plugin/theme, the following items will be exposed:

  • Member queries (bp_has_members() and BP_User_Query) can be filtered by 'member_type'. This allows developers to filter member lists in directories and elsewhere.
  • A Member Type metabox will appear on each user’s Community Profile page in Dashboard > Users. Admins can use this metabox to view and change the member type for the current user.

We think that these tools will serve as the foundation for various new features in plugins, themes, and in future versions of BP itself. See, for example, #5192 (show different xprofile fields to different types of members) and #6060 (on Dashboard > Users, display member types and allow filtering by member type). Developers: as you start using this framework, we hope you’ll provide us with feedback and ideas for improving it in future releases.

#2-2, #member-types

Dev chat agenda for Wed 19 November 2014

Hi everyone – I have a few items I’d like to discuss during tomorrow’s dev chat, and I thought I’d start a list here so that others could add their own:

#6005 – Some improvements to the interface on the Messages screen. Started as some minor improvements to no-js support, but has blossomed into some more intermediate-level interface changes. Mainly, I want to be sure that the team is on board with making changes of this magnitude in bp-legacy.

#6008 – After some discussion, we’ve moved toward the recommendation of removing HTML altogether from page titles in theme compat. This will mean moving the “Create a Group” and “Create a Site” buttons elsewhere, and will mean a slight change in existing behavior for users who expect the title to be clickable. I’d like for the team to agree on whether this level of breakage is OK, given the benefits.


BuddyPress 2.1 “Patsy” is here!…

BuddyPress 2.1 “Patsy” is here! http://buddypress.org/2014/09/buddypress-2-1-patsy/

Thanks to all who have contributed to this release. Take two slices, and we’ll talk about 2.2 in the morning ;)

Following some technical difficulties, the…

Following some technical difficulties, the latest strings from BP trunk are now available for translation at http://translate.wordpress.org/projects/buddypress/dev. If you maintain a BP language pack, please have at it! (And sorry for the delay.)

Changes to bp_has_activities() queries in BP 2.1

Activity queries were largely overhauled in BuddyPress 2.0, leading to major performance improvements. These improvements were focused on the paginated query, the SELECT that contained a LIMIT clause based on the per_page value. The remaining bottleneck for activity pages on large installations was the other SELECT COUNT(*) query performed in BP_Activity_Activity::get() to get the total number of items matching the query params, a query that is much less amenable to optimization. The kicker is that the value returned by this query is almost never used in BuddyPress; the most common use for the total count figure is to generate pagination HTML, but by default, BuddyPress does not show true pagination for activity anywhere on the front end – just a generic “Load More” button at the bottom of the stream.

BuddyPress 2.1 will include changes to address this bottleneck. (See #5629 and r8491.) The SELECT COUNT(*) query will no longer take place by default, and the logic for displaying the “Load More” button has been altered to work without this query. Most sites will not notice any difference (except for the increase in speed!). However, there are a few cases where developers may need to make modifications to preserve some functionality:

  • noscript support – The “Load More” button on activity page uses Javascript. To cover browsers with JS disabled, a <noscript> block appeared in the activity-loop.php template that contained traditional pagination markup. This pagination will no longer generate properly as of BP 2.1. In BP’s bp-legacy templates, we have removed the <noscript> block and altered the “Load More” href to be populated by bp_activity_load_more_link(). However, if your theme is a bp-default derivative, or if you have overridden activity-loop.php in your theme, you will need to make the mods yourself to support non-JS browsers. Either reproduce the core change, or add count_total=count_query to the bp_has_activities() arguments.
  • Custom activity queries – If you have built a plugin or another customization that uses BP’s activity query functions (bp_has_activities(), bp_activity_get(), BP_Activity_Activity::get()), and if your customization relies on the 'total' or 'total_activity_count' value, you’ll need to make the necessary modifications to work properly with BP 2.1. In most cases, this just means passing 'count_total' => 'count_query' as one of the function args.

Apologies to those for whom this will cause an inconvenience – normally we try not to break backward compatibility for any reason, but it was impossible to ensure that all installations would receive the performance benefits without affecting a certain subset of installations (we did try to minimize impact).

Questions? Please ask in the comments below.

#activity, #bp_activity_activity, #bp_activity_get, #bp_has_activities