It’s been a while between updates for the codex but it’s been busy year so far on and of.
Needless to say the Codex hasn’t been forgotten and the team and those willing helpers will be re-focusing on various aspects to do with:
- Further enhancing and improving the sectioning of pages and their parentage, ensuring guides are in the most appropriate sections and are easy to find.
Attending to minor styling updates to help the menus stand out for nested items, heading sizes/positioning
Ongoing checking of some of the older articles to check for accuracy and up to date references.
We’ll manage these tasks on a monthly basis in a simple single google doc:
Codex monthly task list (while exploring the possibility of using some free project management tools to take over from google docs)
Naturally we welcome feedback, good or bad :) to help us know if we’re on track. Any comments are helpful, let us know whether there are areas that you think could be improved, and any volunteers to help tackle these areas are always welcome.
Lastly some belated acknowledgements for submitted articles over the course of this year are due so thank you to the following people for their contributions:
@chouf1 – http://codex.buddypress.org/developer/translations/ heaviliy revised, new content
Revisions & Updates:
@shanebp The-activity-stream-loop & the-group-members-loop-bp-group-has-members
As ever the contributions from the community are what make the Codex a valuable and vibrant resource so keep them coming.
The codex team.
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.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
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.
Quick #2.1 update: we’re still scoping out the big-ticket items for 2.1, and should have more to confirm on in the next week or so, but as of yesterday (May 14th), the 2.1 dev cycle has formally kicked off. Here are the dates for this release’s milestones that we agreed on:
1) “merge” deadline (when major features should be in): July 9th 2014
2) beta: August 6th 2014
3) release: August 27th 2014
If you’re looking to get involved and contribute to BuddyPress, or just learn a bit more about what that entails, I’ll be posting a recap on this blog within the next week, with some easy and productive ways you can help us build and support BuddyPress 2.1.
We all know there’s a lot of expectations about adding a “media feature” to BuddyPress core. Team wants to do the right choices about it so this feature behave nicely with existing plugins dealing in this area, and so that custom components will be able to use it for their particular needs.
For a detailled story of our discussions, you can check the trac ticket 5429.
During the 2.0 dev-cycle, we’ve decided to move this feature into a plugin.
A month ago, i’ve published the very first version of BP Attachments: a component to help others deal with media/files. This version is available on github and we are very interested by your feedbacks/contributions about it.
This plugin is requiring at least BuddyPress 2.0 and WordPress 3.9.
The github repository also includes a wiki where i’ve described how to install/activate it and the way it works. So far the plugin can deal with Group and Member’s attachments & avatars.
If you’re dreaming about having such a feature in BuddyPress, help us make it come true!
- you can simply test it, report bugs, enhancements, or thoughts.
- as a plugin author, you can help us check there are no conflicts (such as duplicate names in functions)
- if you want to join the adventure by pulling requests or suggesting patches, that would be awesome!
BP 2.0.1 is out: http://buddypress.org/2014/05/buddypress-2-0-1/
In BuddyPress 2.0, one of the coolest things for developers is the
bp_parse_args() function. This function is copied over from our cousin, bbPress.
What this allows developers is the chance to filter various parameters before they are passed for further rendering.
I’ve just created a codex article explaining how to use
bp_parse_args() to filter BP’s template loops here:
If anyone has any questions about the codex article, please drop a comment below and I’ll try to answer it.
Now, go and read the codex and grab a slice of pizza!