Two Ways Of Creating WordPress Options Pages

2 Views

I’m about to create my own options pages for my WordPress theme and I’m a bit confused.

I’ve seen a lot of themes that used arrays to generate options pages, it looked like this:

Read More
$options = array (

     array(    "name" => "Welcome Message",
               "type" => "title"),

     array(    "type" => "open"),

     array(    "name" => "Title",
               "desc" => "Enter a title to display for your welcome message.",
               "id" => $shortname."_welcome_title",
               "std" => "",
               "type" => "text"),
);

Plus a few other functions that generated front-end, tables, forms etc.

On the other hand, there are “static” options pages from Codex ( http://codex.wordpress.org/Creating_Options_Pages ).

They look like: 

<form method="post" action="options.php">
    <?php settings_fields( 'baw-settings-group' ); ?>
    <?php do_settings( 'baw-settings-group' ); ?>
    <table class="form-table">
        <tr valign="top">
        <th scope="row">New Option Name</th>
        <td><input type="text" name="new_option_name" value="<?php echo get_option('new_option_name'); ?>" /></td>
        </tr>

        <tr valign="top">
        <th scope="row">Some Other Option</th>
        <td><input type="text" name="some_other_option" value="<?php echo get_option('some_other_option'); ?>" /></td>
        </tr>

        <tr valign="top">
        <th scope="row">Options, Etc.</th>
        <td><input type="text" name="option_etc" value="<?php echo get_option('option_etc'); ?>" /></td>
        </tr>
    </table>

    <p class="submit">
    <input type="submit" class="button-primary" value="<?php _e('Save Changes') ?>" />
    </p>

</form>

What are pros & cons of these approaches and which one should I use/is preffered?

Post Views: 2

Related posts

Leave a Reply

1 comment

  1. I would strongly recommend following the Theme Review guidelines for Theme Settings and Data Security. (If you intend for your Theme to be hosted in the WPORG repository, you will be required to follow these guidelines.

    Here’s a brief summary:

    • Themes are required to prefix all options, custom functions, custom variables, and custom constants with theme-slug (or appropriate variant).
    • Theme are required to implement Theme Options and Theme Settings pages deliberately, rather than relying on copy-and-paste scripts from website tutorials.
    • Themes are required to use the add_theme_page() function to add the Theme Settings Page to the Appearance menu, rather than using add_menu_page() to add a top-level menu.
    • Themes are required to use the edit_theme_options capability for add_theme_page(), rather than rely on a role (e.g. “administrator”), or a different capability (e.g. “edit_themes”, “manage_options”) for the capability to add the settings page.
    • Themes are required to save options in a single array, rather than create multiple options for its settings page. Use of set_theme_mod and get_theme_mod handles this for you, as does using the Settings API.
    • For checkboxes and select options, Themes are required to use the checked() and selected() functions for outputting checked=”checked” and selected=”selected”, respectively.
    • Themes are required to validate and sanitize all untrusted data before entering data into the database, and to escape all untrusted data before being output in the Settings form fields or in the Theme template files (see: Data Validation)
    • Themes are required to use esc_attr() for text inputs and esc_html() (or esc_textarea() in WP 3.1) for textareas.
    • Themes are required to provide explicit Settings-page nonce checking, if not using the Settings API (see: WordPress Nonces)
    • Themes are recommended to use the Settings API to get and save form input data rather than rely on $_POST and $_REQUEST data directly.

    References

    EDIT

    So, to clarify: you don’t have to choose either/or here. The Settings API can handle both approaches simultaneously – and in fact, does so quite elegantly.

    The add_settings_field() call can be generated dynamically, and can use a single callback, with a switch to output field-type-specific form field markup. Here’s how I implement it.