[buddypress-trac] [BuddyPress Trac] #5750: Push VS Pull - Dependency Management

buddypress-trac noreply at wordpress.org
Fri Jul 11 14:01:32 UTC 2014


#5750: Push VS Pull - Dependency Management
-----------------------------+-----------------------------
 Reporter:  johnjamesjacoby  |      Owner:
     Type:  enhancement      |     Status:  new
 Priority:  low              |  Milestone:  Awaiting Review
Component:  Core             |    Version:  1.5
 Severity:  minor            |   Keywords:
-----------------------------+-----------------------------
 We've long since talked about integrating with !BuddyPress and it's
 components as an opt-in, progressive enhancement style experience. Within
 the !BuddyPress project however, we sometimes take advantage of the
 convenience of packaging components together and not adopting that same
 approach.

 bbPress is a great example, where it chooses how to integrate outwardly
 with other components by pushing it's functionality out to Groups,
 Profiles, Notifications, etc... Where as some of our !BuddyPress
 components use `bp_is_active()` and pull functionality in from other
 components.

 Look at `bp-groups-notifications.php` for example. Here, we do several
 `bp_is_active( 'notifications' )` checks and trigger some !BuddyPress
 notifications if the component is active. I posit we should do the
 opposite, and replace those checks with unique actions that the
 Notifications component can hook into instead.

 This does a few things:

 * Makes components less dependent on one-another
 * Increases flexibility and ease of use for customizations
 * Allows us to create conventions around component interactions
 * Enables third party plugins to hook into places they could not
 previously

 The Core component will likely benefit from this the most. There are over
 60 usages of `bp_is_active()` in places where components could choose to
 push their functionality into Core actions rather than be unknowingly
 pulled in. Obviously not all of these usages will make sense to replace,
 and if we choose to go this route, we'll want to approach this type of
 refactor methodically and purposely.

 Opening this ticket here for discussion, and as a master ticket for any
 related changes we make.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5750>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac


More information about the buddypress-trac mailing list