[buddypress-trac] [BuddyPress Trac] #5390: Remove some old BuddyBar stuff
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:
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/>
More information about the buddypress-trac