Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

Problem description

I'm searching for a way to add a settings section/settings fields to the ~/wp-admin/options-discussion.php page exactly where Core calls

do_settings_sections('discussion');

How to

When I register the setting and add the settings field, nothing appears:

function register_setting()
{
    register_setting(
         'discussion'
        ,$this->option_name
        ,array( $this, 'sanitize_setting' )
    );
}

public function add_settings_field()
{
    add_settings_field(
         $this->option_name
        ,__( 'Label', 'wpse_textdomain' )
        ,array( $this, 'render_field' )
        ,'discussion'
        ,'discussion'
        ,array()
    );
}

Debug/inspect

Now I was curious why nothing appeared and dumped the global that holds the settings section right below that line in core:

var_dump( $GLOBALS['wp_settings_sections'] );

The output was a plain simple NULL.

Question

How does one register a settting there, without registering the section with add_settings_section( 'discussion', __( 'Title', 'textdomain' ), 'callback', 'discussion' ); first?

Reason

The reason why I ask for "without registering the setting without the section" is plain simple: If another plugin registers the same section afterwards, it would overwrite/override the added section.

EDIT To make it more clear what I'm asking for. I'm aware that there're two sections default & avatars already present on the page and that I can hook in there. Point is that I don't want to hook into existing core feature settings, but below them, right into the settings sections that core should output with do_settings_sections( 'discussion' );. Point also is, that the discussion page was never registered by core and therefore can't get used as do_settings_section() aborts without being able to loop through any (not) registered pages. I'm fully ok with an answer that confirms that and states: No, doesn't work. Is a bug. or even better creates or helps creating a patch.

share|improve this question

1 Answer 1

up vote 5 down vote accepted

You have to call add_settings_section() first, pass a unique ID and assign it to the page (poor name) discussion:

add_settings_section( 'ads_id', 'Extra Settings', 'ads_description', 'discussion' );

Then register a callback to save your field(s) …

// Register a callback
register_setting(
    'discussion',
    'ads',
    'trim'
);

… and then register one or more fields:

// Register the field for the "avatars" section.
add_settings_field(
    'ads',
    'Test field',
    'ads_show_settings',
    'discussion',
    'ads_id',
    array ( 'label_for' => 'ads_id' )
);

Here is a very simple example:

add_action( 'admin_init', 'ads_register_setting' );

/**
 * Tell WP we use a setting - and where.
 */
function ads_register_setting()
{
    add_settings_section(
        'ads_id',
        'Extra Settings',
        'ads_description',
        'discussion'
    );

    // Register a callback
    register_setting(
        'discussion',
        'ads',
        'trim'
    );
    // Register the field for the "avatars" section.
    add_settings_field(
        'ads',
        'Test field',
        'ads_show_settings',
        'discussion',
        'ads_id',
        array ( 'label_for' => 'ads_id' )
    );
}

/**
 * Print the text before our field.
 */
function ads_description()
{
    ?><p class="description">This is the description</p><?php
}

/**
 * Show our field.
 *
 * @param array $args
 */
function ads_show_settings( $args )
{
    $data = esc_attr( get_option( 'ads', '' ) );

    printf(
        '<input type="text" name="ads" value="%1$s" id="%2$s" />',
        $data,
        $args['label_for']
    );
}

Note the fifth parameter for add_settings_field().

Result

enter image description here

share|improve this answer
    
For later readers: I have to note that the main problem I had with the sanitize callback not working was, that I hooked into load-options-discussion.php. This is (kind of) wrong as the callback won't work unless you hook the registration of the setting (register_setting()) to admin_init. Point is that it's kind of hard to abort the class on other admin pages this way to not use memory when it's not needed (check 'update' === $_POST['action'] for example), but it works. –  kaiser Apr 25 '13 at 22:42

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.