Class: BP_Group_Extension  - X-Ref

API for creating group extensions without having to hardcode the content into
the theme.

To implement, extend this class. In your constructor, pass an optional array
of arguments to parent::init() to configure your widget. The config array
supports the following values:
- 'slug' A unique identifier for your extension. This value will be used
to build URLs, so make it URL-safe.
- 'name' A translatable name for your extension. This value is used to
populate the navigation tab, as well as the default titles for admin/
edit/create tabs.
- 'visibility' Set to 'public' (default) for your extension (the main tab
as well as the widget) to be available to anyone who can access the
group, 'private' otherwise.
- 'nav_item_position' An integer explaining where the nav item should
appear in the tab list.
- 'enable_nav_item' Set to true for your extension's main tab to be
available to anyone who can access the group.
- 'nav_item_name' The translatable text you want to appear in the nav tab.
Defaults to the value of 'name'.
- 'display_hook' The WordPress action that the widget_display() method is
hooked to.
- 'template_file' The template file that will be used to load the content
of your main extension tab. Defaults to 'groups/single/plugins.php'.
- 'screens' A multi-dimensional array, described below.
- 'access' Which users can visit the plugin's tab.
- 'show_tab' Which users can see the plugin's navigation tab.

BP_Group_Extension uses the concept of "settings screens". There are three
contexts for settings screens:
- 'create', which inserts a new step into the group creation process
- 'edit', which adds a tab for your extension into the Admin section of
a group
- 'admin', which adds a metabox to the Groups administration panel in the
WordPress Dashboard
Each of these settings screens is populated by a pair of methods: one that
creates the markup for the screen, and one that processes form data
submitted from the screen. If your plugin needs screens in all three
contexts, and if the markup and form processing logic will be the same in
each case, you can define two methods to handle all of the screens:
function settings_screen() {}
function settings_screen_save() {}
If one or more of your settings screen needs separate logic, you may define
context-specific methods, for example:
function edit_screen() {}
function edit_screen_save() {}
BP_Group_Extension will use the more specific methods if they are available.

You can further customize the settings screens (tab names, etc) by passing
an optional 'screens' parameter to the init array. The format is as follows:
'screens' => array(
'create' => array(
'slug' => 'foo',
'name' => 'Foo',
'position' => 55,
'screen_callback' => 'my_create_screen_callback',
'screen_save_callback' => 'my_create_screen_save_callback',
),
'edit' => array( // ...
),
Only provide those arguments that you actually want to change from the
default configuration. BP_Group_Extension will do the rest.

Note that the 'edit' screen accepts an additional parameter: 'submit_text',
which defines the text of the Submit button automatically added to the Edit
screen of the extension (defaults to 'Save Changes'). Also, the 'admin'
screen accepts two additional parameters: 'metabox_priority' and
'metabox_context'. See the docs for add_meta_box() for more details on these
arguments.

Prior to BuddyPress 1.7, group extension configurations were set slightly
differently. The legacy method is still supported, though deprecated.