Creating a plugin that will add options. Where should the options menu pages go?

I am creating a plugin for a restaurant theme that will provide a few options to add the restaurant hours of operation. Currently, I use a custom post type to control the restaurant hours but have since realized this is a bad practice because if the theme changes that info will be lost. I would like to separate them via a plugin and uses options instead of a custom post type.

Is there a standard practice for where the options menu pages should be placed? Theme customizer page? Plugin settings? Custom page? New page under the Settings section?

Read More

Update

Planning to use the existing wordpress APIs so I am not worried about the storage of the data.

Related posts

Leave a Reply

3 comments

  1. I am reading your question as being “Is there a standard practice for where the options menu page should be placed?”

    Is there a standard practice for where the options should be placed?

    I don’t think so but there are better and worse places.

    Theme customizer page?

    No. This is bad for the same reason you are worried about your current setup. It is connected to a particular theme, and wouldn’t easily transfer to a new one.

    Plugin settings?

    This could work, but the settings would be somewhat hidden. Getting to plugin settings pages is not especially straightforward.

    Custom page?

    You mean a new top-level menu– Next to to “Posts”, “Pages”, “Links”, that kind of thing? This could work too but I’d shy away from it unless you have a number of different configuration pages to add beneath the main menu. It is very easy to create a lot of clutter on the sidebar.

    New page under the Settings section?

    This seems like the best place to me to add a single menu. Logically, what you are creating fits well under “Settings” and it would be out of the way most of the time. And it is not associated with a particular theme.

    It isn’t clear where you are planning to save the options in the database, but I assume you’ll be using the Options API to store the data in the *_options table. The Settings API is worth looking into to help with the form building/managing.

  2. You’re addressing two things:

    1. Where to store the data (meaning: what table in the database);
    2. How to change the settings.

    Storage

    First, you might want to register a new setting (in the options table):

    register_setting( 'my_restaurant_options', 'my_restaurant_options' );
    $restaurant_options = array(
        'option_1' => VALUE,
        ...
        'option_n' => VALUE,
    );
    update_setting( 'my_restaurant_options', $restaurant_options );
    

    Settings

    The easiest way to change settings is via a dedicated page. Where you put this page (new menu page, submenu page of settings, submenu page of options, …) is up to you.

    If it’s just theme options, why not put a submenu page in design/theme?

  3. There is absolutely nothing with custom post types per se, but if you are only storing data a couple from a couple of input fields where each field has its own specific purpose you might want to use the Settings API instead. And moving post types and settings our of your plugin (styling) and supplying them through a plugin (functionality) is a splendid decision.

    The Settings API is fairly straight forward. It allows to add setting fields to the existing setting sections (General, Discussion, Permalinks etc.) as well as adding subpages to any top level navigation item in the admin section and also top level pages of your own. Depending on your needs you could add your setting fields to an existing page or add your own page.

    This is a good example of how to add two fields to the Reading settings page, with a clear illustration below. Basically what you would do in order to add a page, subpage, settings section and setting field is this:

    // Example code to illustrate page/subpage/setting relationships, might not work as intended or break
    function wpse_90342_admin_menu {
        // Top level menu page (http://codex.wordpress.org/Function_Reference/add_menu_page)
        add_menu_page('Page title', 'Menu item title', 'manage_options', basename(__FILE__), 'wpse_90342_page_callback',   plugins_url('images/icon.png', __FILE__), 6);
    
        // Sub menu page (http://codex.wordpress.org/Function_Reference/add_submenu_page)
        add_submenu_page( basename(__FILE__), 'My Plugin Tools Page Title', 'My Plugin Tools Menu Title', 'manage_options', 'my_plugin_tools', 'wpse_90342_subpage_callback' ); 
    
        // Settings section
        add_settings_section('eg_setting_section', 'Example settings section on subpage', 'eg_setting_section_callback_function', 'my_plugin_tools');
    
        // Settings field
        add_settings_field('eg_setting_name', 'Example setting Name', 'eg_setting_callback_function', 'my_plugin_tools', 'eg_setting_section');
    
        // Register the settings field
        register_setting('my_plugin_tools', 'eg_setting_name');
    }
    add_action('admin_menu', 'wpse_90342_admin_menu');
    
    function wpse_90342_page_callback() {
        echo "This is the top level page";
    }
    
    function wpse_90342_subpage_callback() {
        echo "This is the subpage";
    
        do_settings_sections('my_plugin_tools' );
        settings_fields( 'my_plugin_tools' );
    
        submit_button();
    }
    
    function eg_setting_section_callback_function() {
        echo "Section header";
    }
    
    function eg_setting_callback_function() {
        echo "Settings field";
    }
    

    You might want to look into the documentation for add_menu_page and add_submenu_page as they require quite a lot of parameters that might need to be consistent between the two in order for your page/subpages/fields to adhere to the intended hierarchy.