Info about the cookie encoding change in BuddyPress 2.0.3

If you’re a plugin developer who uses the bp_completed_create_steps cookie, or have otherwise used it to customise your site, please read this important change notification. Otherwise, this change won’t affect you.

#2-0, #2-1, #plugins

Using bp_parse_args() to filter BuddyPress template loops

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:
http://codex.buddypress.org/plugindev/using-bp_parse_args-to-filter-buddypress-template-loops/

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!

#2-0

Grunt coming to BuddyPress after 2.0 release

Shortly after BuddyPress 2.0 is released, we’re going to be updating BuddyPress’ development trunk (buddypress.svn.wordpress.org/trunk) to a Grunt-powered build system. Most people won’t even notice, but for developers and contributors, this means a small workflow change.

TL;DR – keep reading if:

• You develop plugins for BuddyPress
• You are a core contributor
• You run a checkout of trunk on a production site

#2-0, #2-1, #grunt

Proposed metadata function changes for BuddyPress 2.0

A few weeks ago, BP’s internal metadata functions, like bp_get_activity_meta() and groups_update_groupmeta(), were refactored to use WP’s core _metadata() functions. See #4551

During the refactoring, special care was taken to preserve the exact behavior of each function, including the oddities and quirks (and bugs) that they’ve accumulated over the years. Now that a functionally identical refactoring is complete, I’d like to address these oddities. 

If you’ve ever used one of the metadata functions from the activity, blogs, groups, or xprofile components, please read #5399 and review the proposed changes. A few of them are straightforward bugfixes that shouldn’t ruffle any feathers. Others are improvements that will break backward compatibility in some hypothetical edge cases, but in each instance I’m not aware of any actual edge case. If you have feedback – including pointers to existing plugins, themes, etc that would be broken by any of the proposed changes – please leave it here or on that ticket.

Thanks for participating.

#2-0, #metadata

#4551, #5399

User last_activity data and BuddyPress 2.0

BuddyPress uses ‘last_activity’ data extensively: for display purposes (‘last active 3 days ago’), to sort results, and to determine whether a WP user is a valid site member. At the same time, ‘last_activity’ has been a perennial performance bottleneck. In the case of users, the information was stored in wp_usermeta. This table gets exceptionally bloated on busy sites, and it’s not properly indexed for the sorts of ORDER BY queries we were performing on it. See #5128 for more background.

A fix for this longtime issue is in place for BuddyPress 2.0. (See r7860.) Short version: user last_activity data is now stored in a ‘last_activity’ row in the wp_bp_activity table. We’ve modified our core queries to take advantage of the new location. And we’ve done a bit of trickery to make sure that the wp_bp_activity table is available for storage, even if the Activity component is disabled. The performance improvements are pretty extreme; I’ll post benchmarks as we near 2.0’s release.

Plugin developers who use user ‘last_activity’ data are urged to account for the new schema. In the past, you may have accessed user last_activity like this:

update_user_meta( $user_id, 'last_activity', $time );
$last_activity = get_user_meta( $user_id, 'last_activity', true );

You are urged to use our API functions instead:

bp_update_user_last_activity( $user_id, $time );
$last_activity = bp_get_user_last_activity( $user_id );

In cases where you are making direct database queries based on this info, please consider using BP_User_Query instead. At the very least, you should refactor your queries to use the new schema.

For the time being, ‘last_activity’ data will continue to be mirrored in wp_usermeta, so your plugins will continue to work. However, you’ll get deprecated notices every time you use the _user_meta() functions to access the information. And hey, the new way performs much better, so you’ll want to update anyway.

Here’s a list of the plugins I found in the wordpress.org plugin repo that will need updating:

• bp-group-control
• bp-default-data
• welcome-pack
• activate-users-in-buddypress
• bp-groups-suggestions
• hts-display-active-members
• bp-member-widget
• buddypress-community-stats
• buddypress-sitemap-generator
• bp-ninja

Questions regarding this change? Need help migrating your code? Please leave a comment below.

(A quick note regarding ‘last_activity’ for groups and blogs. The basic problem there is the same as for users, but the scaling issues are much less severe, so they have not been touched for now. Keep an eye out for relevant updates.)

#2-0, #5128, #last_activity

Contributor Wants/Needs for 2.0 Dev Cycle

Today, during the #buddypress-dev chat on irc the community chatted about things they wished to contribute during the 2.0 dev cycle.

“I believe that individual features get built quicker and in a more robust way when more than one developer/designer/plumber/etc is directly involved in that process. I think this is the most important workflow change we could and should make this year.” – Paul Gibbs

I’ve compiled a list of things from todays dev chat that contributors want to accomplish before the 2.0 release. The ideas discussed today along with the results of the recent BuddyPress survey will help determine additional milestones. You can track the milestones for 2.0 release here: https://buddypress.trac.wordpress.org/milestone/2.0 

@jjj

•  Personally, I’d like to try to clean up the Future Release abyss, but that’s another discussion all together.
• Officially retiring old bbPress and the old bp-forums component; Rewrite Rules; and incorporating a plugin of mine to move profile field visability into the Settings component.
• I hope we’re able to concentrate heavily on moderation and administration functionalities, including integrating more things into wp-admin where it makes sense. Plus, I’d really like to talk about what a default media / photo album experience looks like, which I know imathfromparis has mentioned recently too.
• I plan on dedicating more attention to 2.0 than any release in my recent history, so know that I’d like to around and available and a resource for any questions, tickets, ideas, thoughts, the entire cycle.

@djpaul

• I’m teaming up with Brajesh Singh (of buddydev fame) to work on overhauling the current implementation of xprofile field types. Core has hardcoded pieces of validation and field templating littered throughout itself, and that makes it hard for plugins and themes to add new profile field types. We’re planning to make all this much more sane, and give the power to plugin developers to add bespoke field types. At the very least, we plan to put together a demo plugin alongside these changes to show people how new field types can be added, and I’d like to see if we can find one or two new profile fields which would make a nice addition to core.

http://buddypress.trac.wordpress.org/ticket/5220

@Boone

• My primary interest for 2.0 is in the activity component
• Getting last_activity out of there will greatly increase the efficiency of our members queries. Splitting the query will allow us to scale much better with millions of items
• Begin to implement object caching for certain parts of the activity component, with an eye toward better caching throughout BP
• Helping along karmatosed’s template project
• Helping the CPT/activity ticket that’s been in the works for a long time
• Lurk and commit other people’s patches. Want to give fast feedback to new contributors.

 https://buddypress.trac.wordpress.org/ticket/5349

 @Imath

• Media is a great challenge. I have some ideas about it, mainly around the concept of attachment for other components
• I also like the idea of having a way to manage user profile fields in the admin
• Explore a couple ideas around activity, like using heartbeat
• I think we should also do something for CPT and activity
• I like to find ways to make the site tracking component more popular
• I think about listing the registrations and give the ability to manage them
• Group extension management in the Group Administration screen

@r-a-y

• Like boonebgorges, I want to make sure our object caching is up to speed. We’ve attempted in various releases to add in object caching where appropriate, but actual production environments are having trouble with cache invalidation especially when logged-in.
• I’m also interested in the rewrite rules ticket that JJJ is tasked with. Was playing around with that on a recent project and it’s peeked my curiousity.

@Karmatosed

• I would like to see a (template) sprint. Set a time of 2 weeks and get it prototyped. Call for more hands including core (huge thanks for offers said here). If we keep it small and get this minimal roadmap I think we could do it. Also a freeze – no new stuff.
• The key to this is cut out the extra stuff. We may drop the side menu.. we may cull other things. The idea is we can refine this over time once have something or even over releases to add bells and whistles. We need to be mean in what is in and out. We also need to kill that long ticket and get it into sections or something that is more manageable 🙂

https://buddypress.trac.wordpress.org/ticket/4952#comment:85

@hnla

• Codex has a stage two fleshed out with various tasks that must be addressed.
• Primary amongst those is continuing to edit and update articles – now also with a view to checking for conformance to 1.9 stream retiring any specific to earlier iterations.
• We have some re-factoring to address changing ‘getting started’ to be a ‘users manual’ and starting a general BP Glossary
• Mercime is tackling translation issues
• Lastly we need to follow up and complete the layout re-factoring and menuing where required and will need to speak with core devs with suitable access to these areas, also we need to address a few tickets in trac.

 https://docs.google.com/document/d/19-WnKEH4IfWHL4bnU9_OGRxf4QGUnlPpVOMzk5T1PpI/edit?pli=1#heading=h.4sovg3d0hohl

*If you missed the dev chat you view the irc log here: https://irclogs.wordpress.org/chanlog.php?channel=buddypress-dev&day=2014-01-22&sort=asc

#2-0, #dev-chat, #irc