Better metadata wrappers in BP 1.3

BuddyPress 1.3 will introduce a number of new functions to help plugin authors store options and usermeta. For options, we have:

  • bp_get_option()
  • bp_update_option()
  • bp_delete_option()

and for usermeta, we have

  • bp_get_user_meta()
  • bp_update_user_meta()
  • bp_delete_user_meta()

These functions are essentially wrappers for the corresponding WP functions (get_option(), get_user_meta(), etc). Their syntax is exactly the same as those WP functions.

So why introduce these new functions? In both cases, the goal is to make it possible for BuddyPress to be run on unorthodox setups.

In the case of options, BP 1.3 moves all BP settings out of sitemeta and into blog options tables. On a typical setup, BP will store all settings in the options table of BP_ROOT_BLOG. But in non-standard setups – including BP_ENABLE_MULTIBLOG, or multinetwork BP – certain options may need to be stored somewhere other than BP_ROOT_BLOG. The bp_x_option() functions wrap a utility function called bp_get_option_blog_id(), which allows plugin authors to filter the blog where a given option is stored.

Likewise, in the case of usermeta, the new functions will allow for more flexibility. I’ve already written about bp_get_user_meta_key() and the motivations behind it. The new bp_x_user_meta() functions are just wrappers for x_user_meta() calls, which use bp_get_user_meta_key() to allow the meta keys to be filtered. These wrapper functions should make it much easier for plugin authors to access and store usermeta.

These changes are nearly 100% backward-compatible. If your plugin or theme still uses the WP usermeta and options functions, it should continue to work in BP 1.3, unless the admin enables one of the aforementioned unorthodox setups. Plugin authors are highly encouraged to use the bp_ variants from here on out.

For more information, see the changesets where these wrappers were introduced: [4559] (options) and [4558] (usermeta).

#1-3, #bp_get_user_meta_key, #options, #sitemeta, #usermeta

I’ve been looking through the feature r…

I’ve been looking through the feature requests and there are a lot of awesome suggestions, great work everyone.

What do you think about keeping the new features for 1.3 to just one or two? The release of WordPress 3.0 is in April and I’d like to get a new version of BuddyPress released sometime soon after that. The 1.2 branch will be brought up to scratch in time for the release, but I don’t want the next version lagging behind.

I think we can knock off a couple of major requests for 1.3 – basic privacy (limit my profile to friends / followers / not in public listings) and improved XProfile field and group management. These features will be on top of WP3.0 support work and also an improved install/upgrade interface. We could then start the vote post WP3.0/BP1.3.

That also brings up another important point – the new install/upgrade interface. With this new interface I’d like to start highlighting third party themes and plugins more. So for instance in the new installation wizard there will be a final completion step that will highlight some of the most popular BuddyPress plugins. Site admins will be able to select a plugin they are interested in and perhaps even install it right there. Moving forward I strongly feel that BuddyPress should just provide the base feature set and the tools to build fantastic extensions. It’s then possible to start blurring the line between what is “core” and what is not. There’s no reason why the best component extensions can’t be given as much of the spotlight as bundled core components.

Something to think about, feedback welcome.

#1-3

I’ve started making a list of internal …

I’ve started making a list of internal code improvements and features I’d personally like to add to the list for the next version of BuddyPress, comments very welcome.

  • current_user_can() support
  • Basic Privacy – limit my profile to friends / followers / not in public listings
  • theme_supports() support
  • Generic component extension API
  • Create pages for top level navs instead of hijacking with root components. This would let you move members, groups, blogs, forums etc to a sub page – e.g. /community/groups/
  • Implement a REST API
  • Atom feeds with Activitystrea.ms and PuSH Support
  • Better install / upgrade procedure – wizard like
  • Improved Xprofile field management and advanced search
  • Global search – activity, members, groups, forums, blogs all in one result.

DJPaul – how are we looking for putting together a full list based on community feedback, ready for a vote?

#1-3, #ideas