Skip to:
Content

BuddyPress.org

Opened 10 years ago

Closed 6 years ago

#5750 closed enhancement (maybelater)

Push VS Pull - Dependency Management

Reported by: johnjamesjacoby's profile johnjamesjacoby Owned by:
Milestone: Priority: low
Severity: minor Version: 1.5
Component: Core Keywords: trac-tidy-2018
Cc:

Description

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.

Change History (7)

#1 @DJPaul
10 years ago

I think some of our newer code has been built with this in mind, and the idea's fine. The only thing I'd be worried would be refactoring this stuff just for the sake of refactoring.

#2 @boonebgorges
10 years ago

+1 to DJPaul's comment. I like the idea of moving toward this where convenient, but I think it's unwise to refactor just for the sake of elegance. In any case, I can't stress enough the importance of writing unit tests for these kinds of refactors where possible.

#4 @boonebgorges
10 years ago

  • Milestone changed from Awaiting Review to Future Release
  • Type changed from enhancement to task

#5 @DJPaul
8 years ago

  • Type changed from task to enhancement

#6 @DJPaul
6 years ago

  • Keywords trac-tidy-2018 added

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: https://make.wordpress.org/chat/

#7 @DJPaul
6 years ago

  • Milestone Awaiting Contributions deleted
  • Resolution set to maybelater
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.