Tell me more ×
WordPress Answers is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

Let me preface this by saying that I hardly ever work with WordPress - in fact, the last time I did a site in WordPress was back during 2.2. Yesterday I made quite a mess of everything and asked several questions here trying to get a basic menu plugin working.

I now have the plugin fully functional and behaving exactly as I expect, so I decided to make minor changes here and there to add functionality and compatibility - including using the Settings API. However a very short moment into reading tutorials on this API and I became quite confused, then this confusion only deepened as I read on and tried to implement the examples - which was made even more difficult by the fact that my plugin is implemented as a class.

Unless I'm doing something wrong, from what I understand to use the Settings API requires the creation of a new function PER SETTING. This means 3-5 functions for the average plugin, and up to hundreds for more advanced plugins. It just seems ludicrous to write this many functions (and develop a naming system to keep from confusing them) when you could just as easily import all applicable $_POST variables into an array and forego the entire mess.

Perhaps I'm old-fashioned, but unless there's something to gain from it I don't see the reason to triple or quadruple how much code I'm writing. Here's how I managed options before attempting to add the Settings API:

    function __construct() {
        /* constructor stuff */
        $this->options = $this->db_options = get_option( 'de-menu-options' );
        if( $this->options === false ){
            $this->options = $this->defaults;
        }
        if (is_admin()) {
            add_action('admin_menu', array(&$this, 'admin_menu'));
        }   
        /* more stuff */

        // When WordPress shuts down we store changes to options
        add_action('shutdown', array(&$this, 'update'));
    }

    public function admin_menu() {
        add_options_page('DE Menu Options', 'DE Menu', 'manage_options', 'de-menu-options', array(&$this, 'options'));
        add_option('de-menu-options', $this->options);
    }

    public function options() {
        if (!current_user_can('manage_options')) {
            wp_die( __('You do not have sufficient permissions to access this page.') );
        }
        if ( !empty($_POST) && check_admin_referer('de-menu-options') ) {
            // These options are saved to the database at shutdown
            $this->options = array(
                "columns" => $_POST["de-menu-columns"],
                "maintenance" => $_POST["de-menu-maintenance"]
            );
            echo 'DE Menu options saved';
        }
?>

<div class="wrap">
    <h2>DE Menu Plugin</h2>
    <form method="post" action="<?php echo $_SERVER['REQUEST_URI']; ?>">
        <?php settings_fields('de-menu-options'); ?>
        <input type="checkbox" name="de-menu-maintenance" />
        <label for="de-menu-columns">Columns:</label>
        <input type="text" name="de-menu-columns" value="<?php echo $this->options['columns']; ?>" />
        <p class="submit">
        <input type="submit" name="de-menu-submit" value="Update Options »" />
        </p>
    </form>
</div>
<?php
    }

    function update() {
        // By storing all changes at the end we avoid multiple database calls
        $diff = array_diff( $this->options, $this->db_options );
        if( !empty( $diff )  ){
            update_option('de-menu-options', $this->options);
        }
    }

Now with the settings API I have something more like the following:

    function __construct() {
        /* constructor stuff */
        // Do I load options? Will they be loaded for me? Who knows?
        if (is_admin()) {
            add_action('admin_menu', array(&$this, 'admin_menu'));
            add_action('admin_init', array(&$this, 'admin_init'));
        }   
        /* more stuff */
        // Settings API should update options for me... I think
    }

    public function admin_menu() {
        add_options_page('DE Menu Options', 'DE Menu', 'manage_options', 'de-menu-options', array(&$this, 'options'));
        add_option('de-menu-options', $this->options);
    }

    public function admin_init() {
        register_setting('de-menu-options','de-menu-options',array(&$this,'validate'));
        add_settings_section('de-menu-main-options', 'Main Settings', 'options_section', 'de-menu-options');
        add_settings_field('de-menu-maintenance', 'Maintenance Mode', array(&$this,'options_maintenance'), 'de-menu-options', 'de-menu-main-options');
        add_settings_field('de-menu-columns', 'Columns', array(&$this,'options_columns'), 'de-menu-options', 'de-menu-main-options');
    }

    public function options() {
        if (!current_user_can('manage_options')) {
            wp_die( __('You do not have sufficient permissions to access this page.') );
        }
        if ( !empty($_POST) && check_admin_referer('de-menu-options') ) {
            // These options are saved to the database at shutdown
            $this->options = array(
                "columns" => $_POST["de-menu-columns"],
                "maintenance" => $_POST["de-menu-maintenance"]
            );
            echo 'DE Menu options saved';
        }
?>

<div class="wrap">
    <h2>DE Menu Plugin</h2>
    <form method="post" action="<?php echo $_SERVER['REQUEST_URI']; ?>">
        <?php settings_fields('de-menu-options'); ?>
        <?php do_settings_sections('de-menu-options'); ?>
        <p class="submit">
        <input type="submit" name="de-menu-submit" value="Update Options »" />
        </p>
    </form>
</div>
<?php
    }

    public function options_section() {
        echo '<p>' . __('Main description of this section here.','de-menu-lang') . '</p>';
    }

    public function options_maintenance() {
        echo "<input id='de-menu-maintenance' name='options[maintenance]' type='checkbox' />";
    }

    public function options_columns() {
        echo "<input id='de-menu-columns' name='options[columns]' type='checkbox' value=".$this->options['columns']."/>";
    }

    function validate($options) {
        return $options; // I guess?
    }

It's probably painfully obvious from the scrollbars that the code is already longer with just two options. It's like-wise obvious from the comments that I don't entirely understand what I'm doing. Then there's the matter of having 5 new functions (and removing only 1) in order to accomplish all of this.

So just what advantage am I gaining from all of this extra work?

share|improve this question
Do not use them for such cases. I think they are intended for PHP beginners, who need 3-4 options inside their plugin / theme. This is one of the "features" that should have never been implemented... It's basically an API for another API :) – One Trick Pony Jul 29 '11 at 14:59
I use the settings API for everything i write, it all depends how you use it, note you can use the API without even using add_settings_section and add_settings_field, those two functions add bloat to your code more than anything, avoid those and you avoid the bloat.. – t31os Jul 29 '11 at 15:39
I do the same thing as t3los: register the setting itself, then I just code in the forms in HTML on my settings page. If you want to see a really easy way to do this and keep code for later, check out Yoast's WordPress SEO plugin. – chrisguitarguy Jul 29 '11 at 16:18

2 Answers

up vote 5 down vote accepted

My point of view is that main purpose and benefit of Settings API is structure.

It helps to keep complex settings setups:

  • orderly (logic of registration and sections);
  • secure (nonces, validation callbacks);
  • extensible (hooking into another page or allowing to be hooked into).

As with any such structural overhead it benefits more complex use cases and benefits less simple ones.

So you do can implement anything Settings API does without using it. The question is if you can accomplish that in as reliable, secure and extensible way.

share|improve this answer
I finally got my Settings page working with help from this tutorial: alisothegeek.com/2011/01/wordpress-settings-api-tutorial-1 and with the help of the switch statements and helper functions I must say that things are now more orderly in my code (which is nice since I plan on moving from my two test settings to 15-20 total settings). – stevendesu Jul 30 '11 at 4:57
1  
@steven_desu yep, the running joke is that everyone who uses Settings API writes a framework for it. :) Couple helper functions are almost inevitable. Also note that Settings API is not considered finalized and there are (vague) plans to improve it in the future (I think it was mentioned in context of 3.3 plans). – Rarst Jul 30 '11 at 8:46
I certainly hope it's improved. I honestly see no advantages to the Settings API, but rather every advantage I'm enjoying now is the result of the framework that I borrowed for it. I like that all form elements are now dynamically generated with the same appearance... but that isn't Settings API. I like that default settings and registering settings are handled by the same definitions... but that isn't Settings API. I like that jQuery not only makes the forms pretty, but is progressively enhanced - but I had to manually code the progressive enhancement... – stevendesu Jul 30 '11 at 15:50

If you use callbacks properly, there's no need for all the redundant code. Here's how I implement the Settings API, in a way that is completely scalable.

Advantages (among other things):

  • The Settings API forces sanitization of untrusted user data.
  • The Settings API forces options to be registered as an options array, resulting in a single wp_options DB entry, rather than discrete DB entries for each option
  • The Settings API facilitates security hardening of the settings form
  • The Settings API facilitates admin UI consistent with core admin UI, resulting in better UX
share|improve this answer
So it essentially forces security and aesthetic standards that I was already following without its help? I will read through the tutorial you linked, though. If it makes the Settings API as easy as manually coding the forms (or easier) then I'll accept this answer – stevendesu Jul 29 '11 at 16:10
Are you aware that the source code you pointed to implements the functions oenology_get_settings_by_tab() and oenology_get_default_options without ever first defining them? I thought it was bad enough at 209 lines of code (after removing comments and blank lines), but once those functions are defined it'll be even longer... For four options? – stevendesu Jul 29 '11 at 23:18
They're defined elsewhere. The oenology_get_settings_by_tab() isn't really relevant to what you're doing. But you have to define your form-field markup somewhere, just as you have to validate/sanitize user input somehow, so if you're doing it right, you'll have all that same code as well. – Chip Bennett Jul 29 '11 at 23:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.