Upgrade now https://buddypress.org/2015/02/buddypress-2-2-1/
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
$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
$bpglobal. Use the
- 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
$bpglobal 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.
BP 2.2 is now available! https://buddypress.org/2015/02/buddypress-2-2-spumoni/
Slack log: https://wordpress.slack.com/archives/buddypress/p1423080058000925
Packaging and reviews started earlier than the meeting and lasted till after the meeting proper.
Testing and feedback welcome :)
Many thanks again to everyone who contributed to BP 2.2:
@andemann, Andrea Tarantini (@dontdream), Boone B Gorges (@boonebgorges), Brandon Allen (@thebrandonallen), Clean-Cole, @colabsadmin, Damon Cook (@colorful tones), @danbp, David Cavins (@dcavins), Fahmi Adib (@fahmiadib), George Mamadashvili (@mamaduka), Greg Rickaby (@gregrickaby), Hugo (@hnla), Jake Spurlock (@whyisjake), Jess Planck (@ev3rywh3re), John James Jacoby (@johnjamesjacoby), Josh (@joshshashaty),@jreeve, @lakrisgubben, Laurens Offereins (@0ffereins), @lenasterg, Mario Peshev (@nofearinc), Mathieu Viet (@im4th), @mercime, Michael Beckwith (@tw2113), @modemlooper, OC2PS (@sooskriszta), Paul Gibbs (@djpaulgibbs), @pro120, @psycleuk, @rayisme, Renato Alves (@espellcaste), Sergio De Falco (@SGr33n), @shpitzyl, Slava UA (@slaFFik), @standardspace, Stephen Edgar (@netweb), @svenl77, @tharsheblows, @thebigA, @thomaslhotta, Tomasz Ostrowski (@tometzky), Unsal Korkmaz (@unsalkorkmaz), @vimes1984, Scott Taylor (@wonderboymusic)
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.
Here’s a reminder for those who haven’t seen it. Please take a few minutes to fill in the Community Hub Poll as the poll closes in the next few days. Get at it!
This poll’s aim is to find out what features the WordPress community would like in their Community Hub. This survey will close at 29 January 2015 00:00 UTC What do we need from you? Please fill in this poll to voice what features you feel are important for the WordPress community hub to have.
#6119: Imports cause PHP Warnings in bp_blogs_format_activity_action_new_blog_post
- @im4th requested feedback on patch to fix the PHP warnings which show up during a WP import which includes a post with no title.
- Update: Patch has been committed to core. This will be included in BP RC 1.
#5509: invites-loop template re-factoring
- @rayisme mentioned that he was going bring in the template improvements which @hnla and @dcavins were working for beta 2.
- Update: Patch has been committed to core and included in BP 2.2 beta 2 release.
#6122: BP JS whats-new-options animation cuts of larger child elements
- @hnla brought up the animation issues with the status update form.
- Update: Ticket has been moved to BP 2.3 for additional discussion and testing.
#6214: TwentyFifteen BP Companion Stylesheet
- @hnla raised the issue about how BuddyPress components were being rendered in the Twenty Fifteen default theme, “We have some issues in other themes, but in terms of the twenty* themes this is worst rendering of BP we’ve seen.” He brought up his previous suggestion about adding a minor companion sheet enqueued on basis of a theme slug check. I mentioned that while we provide minimal styles to allow theme styles to prevail, we need to set the styles to control the look of the BP elements in the case of the Twenty Fifteen theme (looks bad).
- @boonebgorges approved the proposal to create this ticket and start work on a BP-specific stylesheet for the Twenty Fifteen theme. His advice was to “think about pushing fixes ‘upstream’ as much as possible (and to) always be thinking about whether a given change is appropriate for buddypress.css itself.”
- @djpaulgibbs mentioned that there were a couple of contributors who spoke to him and JJJ at WCSF 2014 and wanted to contribute to BuddyPress in a design capacity. They have been preparing BP-specific stylesheets for the Twenty Fifteen and Twenty Fourteen themes.
- Update: Ticket has been moved to BP 2.3.
BuddyPress 2.2 Beta 2
- @johnjamesjacoby announced that he would be releasing BP 2.2 beta 2 later that. @rayisme reported that there were only a couple of forum posts reported on bugs found in beta 1.
- BP 2.2 RC 1 may be released this week.
- Target date for BP 2.2 stable release is January 27th/28th :).
- Update: BP 2.2 beta 2 has been released. Feedback and testing welcome.
- Update 2: Tickets closed to date – 143 Tickets and counting.
12/24/14 – https://wordpress.slack.com/archives/buddypress/p1421265625000062