Like this:

BP 1.7.1 is now available. View the blog post for more info http://buddypress.org/2013/04/buddypress-1-7-1/

Scope

At yesterday’s dev chat, we made some broad decisions about scope, and some specific decisions about timelines, for the BuddyPress 1.8 release cycle.

The major improvements slated for BP 1.8, and the team members who’ve committed to lead them up:

• meta_query support for the main template loops. See #3521 and Eric Lewis’s preliminary patch for the activity component. (Boone)
• Migrating to the WP Rewrite API. See #4954. (John)
• Template hierarchy for BP template parts. See #4639. (Ray)
• Automatic download and update of language packs. See #4857. (Paul)
• General tidying of BP UI styling. See #4953. (Tammie)
• New template pack. See #4952. (Tammie)
• Miscellaneous improvements to BP_Group_Extension. See #4955. (Boone)
• Convert group member queries to BP_User_Query. See #4482. (Boone)

A number of these items (especially #4482 and #4952) are somewhat questionable for 1.8, due to their size and to our tight deadlines. The team may decide partway into the cycle to punt them.

In addition to the major items listed above, the 1.8 milestone contains a number of smaller enhancements, which can be rolled into the release if folks step up to the plate with patches, testing, and feedback.

Timetable

We’re experimenting with a short release cycle: six weeks for feature development, and six weeks for testing. The following dates are of particular interest:

• June 5, 2013 – End of feature development. Beyond this date, nothing gets committed that is not either a bug with a new feature, or a regression from 1.7.x. Any major features from the list above that are not commit-ready by this date will not be included in BP 1.8. At the dev meeting on June 5, the team will make decisions about borderline cases – features that are partially implemented. We plan to release BP 1.8 beta1 in the days immediately following June 5.
• July 17, 2013 – BP 1.8 final release

The timetable is, by design, compressed. As part of our experiment in a shorter dev cycle, we’re going to hold to this proposed schedule as strictly as possible.

Contribute

Interested in contributing to BuddyPress during the 1.8 dev cycle? The more the merrier! Join us in our weekly dev chats (see sidebar for details), visit one of the tickets listed above, or dip your toe into the 1.8 milestone. Core devs are generally lingering in freenode #buddypress-dev, so please stop by if you’re looking for a place to start.

Like this:

At next week’s dev meeting (April 24 – see the sidebar of this blog for time details), we’ll be discussing the scope and schedule for the BuddyPress 1.8 release. The tentative plan is to have a short release cycle – 12 weeks from the beginning of development to the final release. The core team is asking that interested parties leave suggestions about what to include in 1.8 in the comments below, for discussion at the Apr 24 chat. And if (especially if) you can commit to doing significant development/testing for a given feature, you should mention that too.

For reference, here’s what’s already (tentatively) in the 1.8 milestone on Trac: https://buddypress.trac.wordpress.org/query?status=accepted&status=assigned&status=new&status=reopened&milestone=1.8&groupdesc=1&group=priority&col=id&col=summary&col=milestone&col=status&col=type&col=priority&col=component&order=priority See something on that list you want to help with? Feel free to mention that below, too.

Like this:

As promised, I’ve started a codex page that explains how to take advantage of BuddyPress’s new automated testing suite when writing unit tests for your own BP plugins. http://codex.buddypress.org/developer/automated-testing/writing-automated-tests-for-buddypress-dependent-plugins/ has lots of details and a working example, but the summary is: require buddypress/tests/includes/loader.php before your own plugin to make sure that BP gets installed and initialized, and require buddypress/tests/includes/testcase.php for access to BP’s testcase class and factories.

Questions or comments? Please leave them below.

Like this:

Over the last few months, Paul and I have been building a framework for writing unit and integration tests for BuddyPress. As of tonight, the BuddyPress automated test suite is part of BuddyPress core. (See r6905-6908)

I’ve started a Codex page about our tests: http://codex.buddypress.org/developer/automated-testing/. The BP tests are modeled after the WordPress suite; you can read much more about how WordPress tests work at https://make.wordpress.org/core/handbook/automated-testing/.

If you are a BuddyPress plugin developer, or if you contribute to BuddyPress itself, you’re highly encouraged to use, and contribute to, our test suite. The test coverage right now is very, very sparse, but we hope that it will improve as we fix bugs and refactor various parts of the codebase.

An exciting feature of the BP test suite is that it allows dependent plugins to write tests that invoke BP_UnitTestCase and other BP-specific tools. I will write more about this feature, including examples from my own plugins, in the upcoming days.

The testcases are located in the tests/testcases subdirectory of BP’s plugin folder. Bug reports and enhancement requests should be reported to BP Trac.

Like this:

Hi everyone. BuddyPress 1.7 has just been released. Check out the blog post for more details http://buddypress.org/2013/04/buddypress-1-7-is-now-available/

Thanks to everyone for your help this release cycle!

Like this:

The theme compatibility layer coming in BuddyPress 1.7 makes it so that any WordPress theme is BP-compatible. If you are an author of an existing theme that supplies its own BuddyPress templates, you can (and should) prevent BuddyPress from running theme compat in the context of your theme. You can do so by putting the following line in your functions.php:


add_theme_support( 'buddypress' );


Be sure that you put this line either in the global scope, or in a function that is hooked to 'after_setup_theme' with a priority of less than 100. See http://codex.wordpress.org/Function_Reference/add_theme_support and http://buddypress.trac.wordpress.org/ticket/4846#comment:4 for more information.

Here’s an explanation of why this change is necessary. In order to maintain full backward-compatibility with existing BP themes, theme compat only kicks in as a fallback. On any given page, BP first checks to see whether it can find the “old” templates in your theme directory (such as groups/single/members.php); if the old template is found, it is used, while if it’s not found, BP supplies the markup using theme compat. This means that, in the case of PHP templates, your legacy BP theme will work seamlessly with BP 1.7+.

In the case of CSS and JS, however, BP has no reliable way to know whether a theme is providing the necessary files to make your site look and work correctly. Theme compat errs on the side of caution and loads these static assets. But if your theme has also loaded its own version of these files, it may create conflicts in styling, and more importantly, it may cause certain AJAX events to be fired twice. add_theme_support( 'buddypress' ) tells BP that your theme will be taking care of CSS and JS (in addition to PHP templates).

Note that child themes of bp-default do not need to manually register ‘buddypress’ support; BP assumes it.

See #4846 for more details.

Like this:

In r6314, the BP_User_Query class was introduced. BP_User_Query is a new way to query members in BuddyPress, modeled after WP_User_Query and designed to scale many, many times better than BP_Core_User::get_users(). The main function used for member queries in BuddyPress, bp_core_get_users(), has been refactored to use the new BP_User_Query by default, supporting the old BP_Core_User::get_users() as a legacy mode only. See #4060 for extensive discussion of the improvement and of the problems it’s designed to solve.

For the vast majority of BuddyPress installations, the switch to BP_User_Query will be completely seamless. The only break with backward compatibility concerns the filters 'bp_core_get_paged_users_sql' and 'bp_core_get_total_users_sql'. These filters are found in the deprecated BP_Core_User::get_users(), and are intended to allow plugins to modify the user SQL queries directly. Since BP_User_Query totally reworks the way these queries are constructed, there was no way to provide full backward compatibility.

The only two plugins in the wordpress.org plugin repository that use the filters in question are Achievements (by @djpaulgibbs) and BP Better Directories (by me), and they will be refactored to use BP_User_Query by the time BP 1.7 is marked stable.

If you’ve never heard of these filters, or you are certain that you’ve never used them, you can stop reading right now. Go svn up and have fun!

If you have used these filters to customize the SQL queries on a private project, you will need to take action before BP 1.7 is released. You have two options. (I’ll write up detailed examples on the Codex over the upcoming days and weeks – this is just a primer.)

1. Rewrite your filters. BP_User_Query is designed to be flexible with respect to this kind of customization, so you have several options, depending on what your filters do. If you are adding more WHERE clauses to further limit the members returned by the queries, do the following: Run your own separate SQL query for those WHERE clauses, use the new pre-filter on query parameters – bp_pre_user_query_construct – and add the results of your query to the ‘exclude’ or ‘include’ parameters, as appropriate. If your filters are designed to change user ordering as well as limit the results returned, you can override BP_User_Query‘s user id query by passing a list of user ids to the ‘user_ids’ parameter. Neither of these methods require you to touch any of BP’s core SQL clauses – a major improvement. And if you need to do something even more customized, you can still modify the SQL directly, by using the bp_pre_user_query hook and manipulating the $uid_clauses array.
2. If you are unable or unwilling to refactor your filters appropriately, you can force BP to use the legacy BP_Core_User::get_users() for user queries by filtering 'bp_use_legacy_user_query' and returning true. (Note that doing so will forgo the performance improvements of BP_User_Query. I don’t recommend using the legacy query if you can help it.)

Questions or concerns? Please leave a comment here. Found a bug? Please report it on Trac.

Like this:

I’ve just put up a first-draft patch for the new BP_User_Query object, which overhauls (and highly optimizes) the way that BuddyPress performs user queries: #4060. Please read the patch and my comments if you fall into one of the following categories:

• You’ve developed for a BP installation with a very large userbase and can provide data points
• You’re a MySQL wonk and can analyze the optimizations provided by BP_User_Query
• You have developed plugins or other customizations that have used the ‘bp_core_get_paged_users_sql’ or ‘bp_core_get_total_users_sql’ filters, and are concerned about the backward compatibility plan for BP_Core_User::get_users() and these two filters.

Thanks!

Like this:

One of the big features of BuddyPress 1.6 was the new Activity Management panels in the Dashboard, where site admins can edit, delete, and otherwise manage BP activity content. We’d like to keep the More Admin Goodies trend going in BP 1.7. To that end, I’ve made a first pass at a Groups Management panel: #4414.

The main features of the Group Management panels:

• Easily view a list of all groups on your installation. Filter by privacy status. Sort by name, ID, last active, number of members. (see screenshot 1)
• Edit group name, description, settings on a single screen (see screenshot 2)
• Add group members directly to a group, skipping the invitation process. Features AJAX autosuggest for usernames.
• Manage existing user roles. Ban, promote, demote, remove multiple members on a single screen.

A few planned features are not yet implemented in the patch (bulk delete, help text, better styling). On the ticket, we’ve also discussed other enhancement ideas, such as drag-and-drop member role management.

If you’re interested in this feature, have ideas for how it might be improved, or – especially! – want to help with patches, please visit #4414.