[buddypress-trac] [BuddyPress] #3461: Problem With bp_is_current_component when a Component needs multiple Top level pages(Directory pages)

buddypress-trac at lists.automattic.com buddypress-trac at lists.automattic.com
Wed Aug 10 15:34:28 UTC 2011

#3461: Problem With bp_is_current_component when a Component  needs multiple Top
level pages(Directory pages)
 Reporter:  sbrajesh     |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Core         |     Version:  1.5
 Severity:  minor        |  Resolution:
 Keywords:               |

Comment (by boonebgorges):

 Thanks for always asking tough questions, sbrajesh :)

 Essentially, if you want to have top-level URLs, then you *must* register
 a root component (just like in BP 1.2). And if you want to have a root
 component, you must have a bp-page (this is new in BP 1.5). In order for
 site admins to get the admin warning that they need to create a WP page
 for your component, you must successfully pass the !empty( $bp->{$slug} )
 test in bp_core_add_root_component(). That's because the admin stuff looks
 at $bp->loaded_components and, from there, at $bp->{$component_id}
 admin.php?rev=4920#L486 - so you really do need to be registered in both

 For these reasons, the best suggestion I can come up with, at least off
 the top of my head, is that you register a 'dummy' component in the $bp
 global before using bp_core_add_root_component(). For example,


 function bbg_add_my_components() {
     global $bp;

     // Set up my first component
     $bp->my_slug_1->slug = 'my_slug_1';
     $bp->my_slug_1->id = 'my-slug-1';
     // etc. Register whichever globals you would normally register

     // Set up my first component
     $bp->my_slug_2->slug = 'my_slug_2';
     $bp->my_slug_2->id = 'my_slug_2';
     // That's it for the second, "dummy" component

     bp_core_add_root_component( 'my_slug_1' );
     bp_core_add_root_component( 'my_slug_2' );
 add_action( 'bp_setup_globals', 'bbg_add_my_components' );

 In other words, choose one of the two slugs as identifying the "real"
 component, where you store all of your necessary global data. Then
 register a skeleton, 'dummy' component for any other top-level pages,
 containing just enough information for the component to be picked up in
 the bp-pages admin scripts (so users will know that they have to create WP
 pages for them).

 You'll probably also want to have a wrapper function in your plugin:

 function bbg_is_foo_component() {
     return bp_is_current_component( 'my_slug_1' ) ||
 bp_is_current_component( 'my_slug_2' );

 Or, alternatively, you should be able to use bp_is_page() at this point.

 What do you think? I know that this requires a little bit more work than
 in BP 1.2.x (where you didn't need to put anything in the $bp global in
 order to have a top-level page), but IMO that's OK - we really shouldn't
 have allowed it before, as it gave plugins, etc no way to interact with
 third-party components. In any case, I'm fairly certain that it's an edge

 (On a side note, we might consider allowing multiple bp-pages per
 $bp->{$component} as a future enhancement.)

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/3461#comment:1>
BuddyPress <http://buddypress.org/>

More information about the buddypress-trac mailing list