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>block appeared in the
activity-loop.phptemplate 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.phpin your theme, you will need to make the mods yourself to support non-JS browsers. Either reproduce the core change, or add
- Custom activity queries – If you have built a plugin or another customization that uses BP’s activity query functions (
BP_Activity_Activity::get()), and if your customization relies on the
'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.