[buddypress-trac] [BuddyPress] #3474: Active 3rd party components are listed as Decativated in the BuddyPress->Pages screen

[buddypress-trac at lists.automattic.com]

#3474: Active 3rd party components are listed as Decativated in the
BuddyPress->Pages screen
----------------------------+------------------
 Reporter:  sbrajesh        |       Owner:
     Type:  defect          |      Status:  new
 Priority:  minor           |   Milestone:  1.5
Component:  Administration  |     Version:  1.5
 Severity:  minor           |  Resolution:
 Keywords:                  |
----------------------------+------------------
Changes (by boonebgorges):

 * cc: johnjamesjacoby (added)
 * priority:  normal => minor
 * type:  enhancement => defect


Comment:

 The only thing that $bp->active_components really does is tell BP which of
 its core components should be loaded during the bootstrap process. This is
 not necessary for plugins, because they are not part of the BP bootstrap
 (they get loaded independently and directly by WordPress's plugin
 architecture). Thus, there's no good reason to require that plugins load
 themselves into $bp->active_components. (The other place where
 active_components are referenced is in bp_is_active(), which is why you're
 seeing the 'deactivated' message. But this is not really a meaningful way
 to check whether a component - other than a root component - is active.)

 That said, it appears that at one time, this *was* the recommended
 behavior. See the BuddyPress Skeleton Component:
 http://plugins.trac.wordpress.org/browser/buddypress-skeleton-
 component/trunk/includes/bp-example-core.php#L90 Plugins that are based on
 the BPSC (like Achievements, which was one of the main plugins I used
 during plugin tests - which explains why I didn't see this issue earlier)
 will probably not exhibit the problem, since they mostly have just copied
 what the Skeleton Component, and indeed the old core components, have
 always done.

 On the other hand, the new BP_Core_Component class registers components in
 the $bp->loaded_components array. That means that plugins based on
 BP_Core_Component (which in the future should be most plugins) will
 exhibit the problem.

 There are a bunch of ways we could go with this. My thinking is that to
 maximize backpat and also to support the (far improved) architecture of
 BP_Core_Component (which keeps activated components separate from those
 that have successfully loaded, which is IMO as it should be), we should
 adopt a two-tined strategy:
 1) In bp_is_active(), we should check $bp->loaded_components in addition
 to $bp->active_components. Thus BP_Core_Component plugins won't have the
 problem.
 2) We recommend that plugin authors register themselves manually in the
 $bp->active_components array, if they're using the old method.

 I would like some feedback from another core dev on this, especially JJJ
 as I think he was the one who juggled $bp->active_components and
 $bp->loaded_components and so will be in a better position to say how they
 should be differentiated.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/3474#comment:2>
BuddyPress <http://buddypress.org/>
BuddyPress