Create abstract admin classes

[ragulka]

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 && current_section available in JS (similar to pagenow)

[unfulvio]

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]

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]

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.