Suggestion of bp_core_get_* functions to the Core component

[espellcaste]

While working on wp-cli-buddypress, I saw the need for a few core functions. I'd like to suggest those to BuddyPress. They are:

bp_core_get_active_components()
bp_core_get_inactive_components() (inactive, aka deactivated)

[DJPaul]

Not against this in principle, but there are more places internally (in the core code, and in the phpunit tests) where these settings are referred to. Everything would need to use the new functions provided by your patch if we're going to merge this in.

[espellcaste]

Working on an update...

[DJPaul]

I spent about two hours looking at this. 7654-2.diff is not ready or even correct, but I wanted to save what I had done.

I found a challenge when auditing the bootstrap() method in the main BuddyPress loader class. Basically, should these methods return the database option, or touch the globals as configured in bootstrap()? bp_core_get_components() is a example of a function used in the admin UI which returns hardcoded values, but could easily be switch to touch one of the above instead.

I also felt a need for e.g. bp_core_get_optional_components(), but while this project is arguably over fond of functions that wrap functions, we already have bp_core_get_components($component_type) which could be used instead of these individual functions, if we wanted to.

My gut feeling is that we should keep the duplicate filter calls in bootstrap() which set the global $bp properties, have (and add) the documented filters in bp_core_get_components() return from the global $bp properties -- rather than the database options -- and then consider if we need really need wrapper functions that just call bp_core_get_components().

[espellcaste]

Agree @DJPaul!

After a while, the idea was good but I run into the same problems as you. I'd rather keep it as it is and focus on more important BuddyPress problem.

Thanks for taking the time though! :)