[buddypress-trac] [BuddyPress Trac] #5390: Remove some old BuddyBar stuff

buddypress-trac noreply at wordpress.org
Wed Feb 12 14:07:56 UTC 2014

#5390: Remove some old BuddyBar stuff
 Reporter:  DJPaul            |       Owner:
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  Toolbar/BuddyBar  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:                    |

Comment (by boonebgorges):

 > a significant amount of technical debt in the code that otherwise we'd
 have to maintain in perpetuity.

 I disagree. This code has not been touched in years. I assume we'd only
 spend any time on it in case of a serious security issue. In other words,
 it's deprecated (though we perhaps haven't been as explicit as we
 should've been about this deprecation). It doesn't take any time or effort
 to leave there, and it doesn't leave us on the hook to support anything
 but the most extreme cases.

 The situation I want to avoid is this: back when we migrated to the WP
 toolbar, someone set `define( 'BP_USE_WP_ADMIN_BAR', false );` in their
 config file, and their site has been humming along happily since then. If
 we tear everything out, their site will go whitescreen after upgrading to
 2.0. This is unacceptable. (The fact that you didn't find any public
 plugins or themes doing this is not a good indicator of its popularity.
 This is a config option that's likely to be set only on individual sites.)

 It seems to me that, much like the case of #5351 and bp-forums, we are
 engineering a solution to a problem that does not exist. IMHO, this is a
 poor use of our resources. In both cases, the only downsides of the status
 quo are abstract ideas about technical debt and elegance, which I don't
 find convincing when the change will have real repercussions for existing

 That said, if we absolutely must do something, I see a couple viable

 1. Formally deprecate Buddybar code by moving it to deprecated files and
 adding `_deprecated_function()` notices, but do not disable it. This could
 nudge people away.
 2. Move the Buddybar into a plugin, and use a to-be-determined technique
 to automatically migrate folks to that plugin. (See #5351) It may turn out
 that the process of migrating to the plugin is manual, in which case we
 will probably want to put a big admin notice on the Dashboard for a
 release cycle: "Warning: the Buddybar will be torn out soon. Download the
 plugin to avoid catastrophe"
 3. Force-migrate users to the WP bar by no longer respecting
 `bp_use_wp_admin_bar()`. This will cause Buddybar lovers/customizers some
 consternation, but at least it will leave them with a working toolbar.
 Convert Buddybar functions to stubs and deprecate them, in case anyone's
 calling them directly.

 If we're going to move forward with this, I have a strong preference
 *against* 3. We should avoid alienating users when there's no good
 technical reason to do so. 2 seems the most elegant, if we can sort out
 the details. We could even do 1 now, and then plan to phase in 2 over the
 course of a release or two.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5390#comment:3>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list