The $bp global

Way back in the early days of BuddyPress, the $bp global variable was king. Just about everything BuddyPress related was connected to it in some way (other than the template loops themselves.)

This approach is not uncommon. Even WordPress does something similar in wp-settings.php:

$GLOBALS['wp'] = new WP();

The major difference between WordPress and BuddyPress here is that the $wp global has always been a WP() object responsible for setting up the WordPress environment, while our $bp global used to be just a big collection of random attributes.

We’ve been fairly open and relaxed about latching on to the object as a global data store for all of BuddyPress’s runtime variables. Several third-party BuddyPress plugins use it, and our BP_Component interacts with many of its variables directly.

Fast forward to 2012, and $bp is transformed into a real BuddyPress object, complete with methodology and best practices, and ready to be a bit more intelligent than it was in the past. Since then, we’ve slowly removed our dependence on touching the $bp global directly, and instead encapsulated it in a call to buddypress() to retrieve the object into the current scope. You can read more about the overall initiative on Trac Ticket #5138.

This evening, I replaced all of our remaining global touches with one sweeping changeset. In most cases, this should be a completely invisible change that means very little to anyone not working on BuddyPress core. For the small group of us constantly building and maintaining core, this means a few different things:

  • No more defining the $bp global. Use the buddypress() instead.
  • Even though the global is still hanging around for backwards compatibility, touching it directly should be avoided to prevent accidental breakage.
  • We can start to introduce magic getters and setters for commonly referenced or manipulated variables to ensure their evocation and ongoing validity.
  • We can start reliably moving other BuddyPress globals into this object, and architecting what the next generation of extensions to BuddyPress core will look like, and how BuddyPress core will react to them.
  • We can sleep a bit more soundly knowing that the $bp global has an extra layer of protection against being unknowingly overridden by unexpected plugin conflicts or other WordPress environmental oddities. (Though it’s been years since BackPress and BuddyPress were actively loaded together, between BuddyPress, BackPress, and bbPress, the “bp” namespace was very easily polluted.)

Though developer impact should be minimal, this represents a sweeping code change for BuddyPress 2.3 that should not go unrecognized or uncelebrated. This bit of clean-up was years of iteration and testing, and it feels pretty darn good to have it over and done with so we can move on to other more pressing issues.

Trac Updates

It can be cumbersome to navigate, intimidating to learn, and difficult to master. We know Trac isn’t always the most user friendly tool, but we love it anyways because it works really well for managing the type of project BuddyPress is and the workflow we use.

These issues are exacerbated when Trac is out of date, or has not been “gardened”, which usually refers to general pruning, tidying, and making sure there’s a place for everything and everything is in its place.

Over the past year or two, we’ve focused on improving the software and the build tools, and (other than software updates to keep up with WordPress’s Trac) haven’t revisited our Components, Milestones, or Resolutions in a long while.

This morning I made some rearrangements I think will help us stay better organized and on-target, outlined below:

  • Added the “Under Consideration” milestone, for issues that the core team has reviewed but hasn’t decided on exactly where it belongs yet. This is good for keeping Awaiting Review empty, and getting feedback to ticket authors sooner.
  • Components are now namespaced by what exactly they are intended to be. This should help tickets get categorized appropriately sooner, and help the core team better assess what areas need what improvements.
  • Several components were renamed to more approximately reflect our intentions for them.
  • Removed (4) beta and RC releases from Versions. Any related tickets were moved to their closest appreciate version. We were hugely inconsistent with these versions, and much of the time these were not accurate.
  • Deleted old milestones for Unit Tests and TestBP.org. These had 4 total tickets that were moved to more apprpriate milestones.
  • Added the “regression” ticket type, to help draw attention to issues that should be tested more quickly and prioritized higher.
  • Tens of tickets were shuffled around to better match the above changes. Sorry for the barrage of emails this probably sent out to several of you.
  • Updated current and future milestones to loosely set the pace for 2.2.1 and 2.3, which will start not-long-after 2.2 is released.

Like most things, all of these changes are open to criticism and scrutinization. If it turns out they hurt more than they help, we can try something else. These changes are inspired by years of interacting with Trac and witnessing repeated workflow hang-ups.

We aren’t exactly agile; sometimes members of the core team don’t intersect on issues for a few days, and tickets go unloved for weeks or months. I think we do great in the face of this, and hope our slightly modified arrangement feels like a natural progression of our growing team and project.

Some agenda items for today’s core developer chat:

  • Activity stream performance improvements: https://buddypress.trac.wordpress.org/ticket/5349
  • BuddyPress profile editing within wp-admin: https://buddypress.trac.wordpress.org/ticket/5197
  • General BuddyPress 2.0 goal and expectation setting

Tomorrow we’ll be releasing BuddyPress 1.9 With it…

Tomorrow, we’ll be releasing BuddyPress 1.9. With it comes a host of fixes, improvements, WordPress 3.8 compatibility, and a shiny new Notifications component.

Once BuddyPress 1.9 is released, the core team will be taking some time off for the holidays before getting started on 2.0. Each of us have a wish-list of things we’d like to see in our next major iteration, and we know you do too. We’ll be putting together a brief questionnaire after the beginning of the new year, to make sure our vision is on track with yours, and so we can course correct if necessary.

More here tomorrow after 1.9 goes out!

We’re going to be packaging up BuddyPress 1.7…

We’re going to be packaging up BuddyPress 1.7 imminently. Last chance to hit us with any issues regarding:

  • Theme Compatability
  • Groups Admin
  • Users queries
  • Security issues

Spent some time today cleaning up the many…

Spent some time today cleaning up the many international subdomains we have at BuddyPress.org. If you are an admin for one of these sites, take a look around and make sure things aren’t too broken. A few things:

  • Cleaned up about 5k pending spam comments across all the sites. Yikes!
  • It’s using some unified header magic right now. You don’t have control over the menus yet.
  • If you want forums, just ask. I activated bbPress on a few of the recently active sites, though I didn’t make any forums for them.
  • If you’re not an admin for any language, but want to be, post here and I’ll be in touch.
  • If you’re an admin and don’t want to be anymore, speak up in case someone else wants to take it over.
  • If you want to trick out your subdomain i18n site beyond what is immediately obvious, comment here so we can figure out how to make it happen.

#i18n

Updated BuddyPress org to use the latest bbPress…

Updated BuddyPress.org to use the latest bbPress trunk, which enables forum wide search.

Finally.

We’ll keep iterating on the templates, sidebar, and layout. Right now it’s a little wonky.