Skip to content

Create abstract admin classes #158

@ragulka

Description

@ragulka
Contributor

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)

Activity

unfulvio

unfulvio commented on Jun 30, 2016

@unfulvio
Contributor

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

unfulvio commented on Jun 30, 2016

@unfulvio
Contributor

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

ragulka commented on Aug 11, 2016

@ragulka
ContributorAuthor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @ragulka@unfulvio

        Issue actions

          Create abstract admin classes · Issue #158 · godaddy-wordpress/wc-plugin-framework