[buddypress-trac] [BuddyPress Trac] #5390: Remove some old BuddyBar stuff
buddypress-trac
noreply at wordpress.org
Wed Feb 12 13:42:23 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 DJPaul):
To your point specifically about leaving the BuddyBar itself in the code.
I disagree, and my idea to delete the BuddyBar is what inspired me to
create this ticket. Leaving significant amounts of code in the project
that is not run for both new installs, and surely the vast majority of
existing sites -- considering the forced, opt-out upgrade back in 1.6 --
leaves a significant amount of technical debt in the code that otherwise
we'd have to maintain in perpetuity. Why do we want to continue supporting
a worse, un-supported, lower quality toolbar when we have a forwards-
compatible alternative that's been running in BP for just over a year and
a half, powered by WP Core APIs?
The only ways to re-enable the old BuddyBar is to set a site option with a
key of "_bp_force_buddybar", define the BP_USE_WP_ADMIN_BAR constant as
false, or filter `bp_use_wp_admin_bar`. It's not controllable via an
option in the UI, and we don't even bother to tell people to not use the
BuddyBar, because no-one ever sees it or knows about it.
A Google search of plugins.svn.wordpress.org and themes.svn.wordpress.org
has no matches for any of these, so no-one is publicly downgrading to the
BuddyBar from a theme or a plugin.
Compared to the discussion in #5351 about removing old bbPress, I think
this is an easy no-brainer.
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5390#comment:2>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list