-
Notifications
You must be signed in to change notification settings - Fork 43
Description
A lot of our plugins are using dedicated admin pages outside of WC Settings area. Some plugins simply have a dedicated settings page while others have more complex admin areas with settings, list tables, etc (Memberships, CSV Import/Export). To create those admin areas, a lot of boilerplate code is needed, and each plugin implements things a bit different. This makes it harder to maintain.
We should look into creating some sort of abstraction that would allow plugins to easily register dedicated admin areas/pages/settings, with support for tabs & sections out-of-the-box. This could reduce boilerplate code and provide a more consistent experience & architecture in plugins.
For settings pages, we could probably subclass WC_Settings_Page
and make it more generic, to support adding settings pages to other plugin admin areas, rather than to WC Settings.
I would imagine some kind of abstract admin class that would already have all the plumbing required for adding the menu/submenu pages, tabs and sections. The subclass would then simply need to provide a list of tabs & sections and callbacks for rendering those.
Perhaps something like
Admin_Area extends SV_WC_Admin_Area {
public __construct() {
$this->tabs = array(
'tab_1' => array(
'label' => __( 'Tab 1' ),
'sections' => array(
'section_1' => __( 'Section 1' ),
'section_2' => __( 'Section 2' ),
),
),
'tab_2' => __( 'Tab 2' ),
);
}
public function render_tab_1( $current_section ) {
// .. render the tab...
}
}
In summary, some of the features that would be nice:
- a common structure for adding dedicated admin areas/pages
- built-in support for tabs and sections
- built-in support for the plumbing required for settings pages
- making
current_tab
&¤t_section
available in JS (similar topagenow
)
Activity
unfulvio commentedon Jun 30, 2016
some method to simplify enqueuing scripts and styles? like, we define an array of screens for each script to load an the FW takes care of the logic? see more advanced logic like in Memberships scripts loading when we have both a WC Setting page, plus custom admin pages, plus scripts loaded in products etc.
unfulvio commentedon Jun 30, 2016
additionally, in the main FW class we have a method is_plugin_settings to tell which is the settings page of a plugin, this usually points to WC settings page; but we might have further/other pages and some plugin have WC Emails which has a different endpoint, yet it's still a settings page somehow
ragulka commentedon Aug 11, 2016
Sometimes I need to provide script localizations using
wp_localize_script()
for a very specific subpage/screen, but I'd rather not include them for all admin pages. It would be nice if we had a standard way of filtering our plugin localize_script options, so that specific screens could hook into it and add stuff they need without it polluting all the pages.