Where to hook register_settings for Settings API when also want to update options outside of Settings API?

Question

The Settings API is a convenient way to add administrative options. Tutorials on the settings API hook register_setting to admin_init. But what if you also want to programmatically change the same options outside of the Settings API?

For example, use the Settings API to maintain a base value for option X. In addition, each new post automatically increments option X via a direct update_option function call. Unfortunately, if option X is registered, update_option triggers a call to the validation function associated with the registered setting. The validation fails because the update_option argument isn't passed because I screw up the different validation required from the different sources of options change.

Where should register_setting for option X be hooked to allow option X also to be updated outside of the Settings API? Alternatively, where should unregister_setting for option X be hooked to allow the direct update_option call to work without the Settings API sanitization/validation function call?

Update: t31os below helpfully provided some illustrative code. Here is a small addition to his code:

    function __construct() {
        add_action( 'admin_init', array( $this, 'admin_init' ) );
        add_action( 'admin_menu', array( $this, 'admin_menu' ) );
        add_action('add_meta_boxes', array( &$this, 'add_regtest_box' )); //added hook
        }   

//added functions
    function add_regtest_box() {
            global $post;
            add_meta_box( 'regtest_box', 'Registered Setting Test', array( &$this, 'regtest_box_contents'), 'post' , 'side' , 'high' );
        }   
    function regtest_box_contents() {
            update_option( 'test-option', array('fieldone'=>-11,'fieldtwo'=>8) );
            $new_vals = get_option( 'test-option' );
            print_r( $new_vals );
        }

If you "add new post" from the dashboard, you'll notice that the metabox on the top right shows fieldone with a value of 11, not -11. That's because the update_option function call in regtest_box_contents is putting the option values through the sanitizing/validating function that was registered (register_setting) to the option. In this case, that's t31os's update_option function, which applies absint() to the option value passed through. The question is how to avoid that function call, e.g. just have the option updated to -11.

Answer 1

Now i've thought about it(Mark is me, i use another account when i'm at other locations) all registering a setting does is prepare options.php to accept your incoming form data when a valid nonce is present and also provides a means to hook a sanitization method to the submission of that data. It's really a convenience thing for plugins, and such..

From the front end of the site it should be perfectly fine to just call update_option and be done with it. It doesn't need to registered on the front end, because you're not submitting form data to options.php as you would be for an administration page.

I tried to replicate your problem, but i've been unable to, here's my ugly test code to create a simple registered page that can save options.

class RegisteredSettingsTest {
    private $page;
    private $name = 'test-option';
    private $options;
    function __construct() {
        add_action( 'admin_init', array( $this, 'admin_init' ) );
        add_action( 'admin_menu', array( $this, 'admin_menu' ) );
    }
    function admin_init() {
        register_setting( 'setting_ref', $this->name, array( $this, 'update_option' ) );
        $this->options = get_option( $this->name );
    }
    function admin_menu() {
        $this->page = add_dashboard_page( 'Test','Test','manage_options','translatable_demo', array( &$this , 'load' ) );
    }
    function update_option( $data ) {
        $clean = array_map( 'absint', $data );
        unset($data);
        return $clean;
    }
    function load() {
        ?>
        <div class="wrap">
            <?php screen_icon('index'); ?>
            <h2>Test</h2>
            <form action="options.php" method="post">
                <?php settings_fields( 'setting_ref' ); ?>
                <p><label for="<?php $this->field_name( 'fieldone') ?>">Field one <input value="<?php $this->get_option( 'fieldone') ?>" name="<?php $this->field_name( 'fieldone') ?>" type="text" /></label></p>
                <p><label for="<?php $this->field_name( 'fieldtwo') ?>">Field two <input value="<?php $this->get_option( 'fieldtwo') ?>" name="<?php $this->field_name( 'fieldtwo') ?>" type="text" /></label></p>
                <p class="submit"><input type="submit" name="Submit" class="button-secondary action" value="Save" /></p>
            </form>
            <!-- Output options data, so we can see how it currently looks -->
            <pre><?php print_r( $this->options ) ?></pre>
        </div>
        <?php
    }
    function field_name( $name, $echo = true ) {
        $name = "{$this->name}[$name]";
        if( $echo )
            echo $name;
        else
            return $name;
    }
    function get_option( $name, $echo = true ) {
        $val = '';
        if( is_array( $this->options ) && isset( $this->options[$name] ) )
            $val = $this->options[$name];

        if( $echo )
            echo $val;
        else
            return $val;
    }
}
$r = new RegisteredSettingsTest;

I loaded the page up, entered the values 1 and 2 into the fields and hit Save(which of course works fine and i see the values 1 and 2). I'm using numeric values, because it's just a simple test.

The most simple front end test i could come up with was to just call update_option inside my single.php(though i could have used any other template file).

update_option( 'test-option', array('fieldone'=>3,'fieldtwo'=>4) );

If there were an issue, i should still see the values 1 and 2 when i load up my test admin page. Unfortunately that's not the case, the new values, 3 and 4 are shown.

Can you post up the code that you're using to update the option from the front end? If it's inside a callback, post the whole function, plus the action/filter it's hooked onto, please.. :)

UPDATE:

Remove the sanitization callback before updating the option.

remove_all_filters( 'sanitize_option_test-option', 10 );

And your values won't get butchered by the callback function any longer, because it'll be unhooked.. :)

Answer 2

Could you not just fire your action on init instead?

The requirement to update options is still the same(only admins can manage_options), so it should work in theory, have you tried it, was their a problem?

Not at my main PC right now, else i'd give it a shot myself to see if it works.

What did you mean here..

The validation fails because the update_option argument isn't passed.

I'd have asked in a comment, but i've not hit the rep requirement on this account yet.

Answer 3

On a sidenote...wouldn't it be better to count the relevant posts and then add the base value from your options to get the total? (If that's really what you need it for.) Unless you want to build a settings-interface available from the front-end, this sounds like it points that you should do it in a different way. I think it might be confusing to the user if their 'settings' change on their own?