Like this:

No dev chat this evening. See you next week!

Like this:

BuddyPress 1.6 Beta 2 now available: http://buddypress.org/2012/07/buddypress-1-6-beta-2/

Like this:

As you might be aware WordPress 3.4 is now at the release candidate stage. The BuddyPress team believes the current version of BuddyPress (1.5.5) is fully compatible with WordPress 3.4. If you find any issues with BuddyPress when testing WordPress, please let us know by starting a discussion on our support forums or by filing a bug report on our Trac.

For developers testing WordPress with WP_DEBUG, we know that the BP Default theme generates deprecated function notices, and have already fixed these in our 1.5 branch on SVN.

Like this:

In a recent change, we’ve updated where the Default Theme’s ajaxurl variable points to; it now points to admin-ajax.php instead of wp-load.php. If you are a BuddyPress plugin author who uses this, update your plugin now to ensure compatibility with BuddyPress 1.6.

Since the early days, the Default Theme has output a javascript variable called “ajaxurl” into the page, and it contained the URL to wp-load.php, which is used early in the WordPress loading bootstrap. Likewise, in WordPress itself, when you’re at a page inside the /wp-admin/ part of the site, it also sets a variable called ajaxurl; rather than pointing to the same place as BuddyPress, the URL it contained was to admin-ajax.php.

Why the difference? BuddyPress was doing it wrong; admin-ajax.php works just fine from the front of your site. We’ve figured out a way to guarantee backwards compatibility for any combination and version of BP Default that you might be using, so nothing will break when you upgrade to BuddyPress 1.6.

However, in situations where a site uses 1.6′s Default Theme as the active theme, or as a parent theme, or when _inc/ajax.php is copied into another theme, if a third-party BuddyPress plugin makes use of BuddyPress’ ajaxurl, your plugin’s AJAX may break. In a nutshell, unless you terminate script output through exit() after your AJAX handler does its stuff, WordPress will suffix your output with a zero (details on the WP Codex), and this may have undesired results.

Plugin authors should implement this change in their plugins now. It’s a backwards compatible change, and will work on all current versions of BuddyPress, and help you avoid bug reports after 1.6 is released.

Like this:

Adding admin screens for all BuddyPress content is one of our long-term goals, so for BuddyPress 1.6, we’ve created a brand-new Activity admin screen. On it, you’ll be able to manage activities made on your site similar to the way you manage posts, comments, and other content.

List of all activity items

Editing an activity item

Editing an activity item with the Screen Options panel expanded

Editing an activity item with the Contextual Help panel expanded

It’s pretty neat, and we’ve been using on TestBP.org for some time, and it’s made managing activity much easier. We’re looking forward to sharing it with you in BuddyPress 1.6, but if you want to play with it now, early adopters can get a copy of “trunk”, our development build of BuddyPress, and take a look. (Don’t run it on a live site!)

Our trac ticket for this change is #3660, and was first introduced to trunk in r5262.

Why

One of the most noticeable changes for site administrators with BuddyPress 1.6 will be the location of BuddyPress’ settings screen in the WordPress admin. Since 1.0, BuddyPress has occupied a top-level, front-of-list menu position, alongside the Posts, Media, and Pages menus (and so on). In 1.5, the BuddyPress menu was unstuck from the front of the list, and for most users, it dropped to the very bottom of the list. Most plugin authors, myself included, added their plugin’s settings screen as an item inside this top-level BuddyPress menu.

In 1.6, we’re removing the top-level BuddyPress menu.

Our settings screens will be inside WordPress’ Settings menu (as one item, with our existing tabs), and the Profile Fields screen will be inside the Users menu.

The new Settings menu’s location

Support for plugins adding items to the old BuddyPress menu

The WordPress Codex has good documentation to help plugins decide where to locate settings:

Adding a top-level menu should only be considered if you really need multiple, related screens to make WordPress do something it was not originally designed to accomplish. Examples of new top-level menus might include job management or conference management.

It seemed appropriate that Profile Fields should go into the Users menu, as there is a logical relationship between a user and user profile fields. BuddyPress’ other settings screens allow people to change configuration; they don’t manage content.

If you’re thinking that BuddyPress does let users create new types of content (activities, groups, private messages, forums, and so on), but there’s no truly convenient way for site administrators to manage these, we totally agree.

In 1.6, we’ve created a brand-new top-level Activity admin screen, giving you full management and moderation over your site’s activity items. We’ll be blogging more about this soon, but early adopters can get a copy of “trunk”, our development build of BuddyPress, and take an early look. (Don’t run it on a live site!)

For Site Administrators

Don’t panic! To manage your site’s Profile Fields, you’ll find that under the Users menu. For everything else, you’ll just need to navigate to Settings > BuddyPress, and you’ll find the same set of BuddyPress settings screens that you’re used to.

If you’re using plugins that added items underneath the old top-level menu, you’ll continue to access those in exactly the same place that you do now. We’ll auto-detect and add the top-level menu back, just for those plugins’ screens.

For Developers

Don’t panic! If you’ve written a plugin that added an item underneath the old-top level item, everything will continue to work as it does today — just fine.

To provide that compatibility, we’re auto-detecting and adding the top-level menu back, just for your plugin. We hope that you will consider re-locating your plugin’s settings screens to under WordPress’ Settings menu (or other more appropriate location).

Our trac ticket for this change is #3708, and was first introduced to trunk in r5406.

Like this:

Notes from yesterday’s dev chat:

• 1.5.1 will be out soon. Read the fixes so far.
• 1.6′s scope was discussed. The plan is to release 1.6 very close to the WordPress 3.3 release.
• If something doesn’t get finished for 1.6, it will go into 1.7. We really don’t want another release as long as 1.5 took!
• 1.6 big tickets: Akismet & Activity Stream integration (#3660), full bbPress 2.0 support (#3598), an autocomplete/autosuggest for @mentions (#3278), switch to the WP Admin Bar (#3661), new child theme (#3662), and FOAF (#2738).

Like this:

BuddyPress dev chat is on at its usual time tomorrow, at 19:00 UTC in Freenode. If you want to get involved with the next dev cycle (1.6), now’s a great time!

Like this:

Weekly Update – 19/9/11

• Monitored forum and trac for 1.5-RC-1 bug reports and support requests
• Wrote the 1.5 changelog
• Committed fixes for #3563, #3575, #3580, #3588.

Like this:

As always, dev chat is on later today. Plan is to review any new important tickets and the release of the next beta.