1

Working on my first theme and thinking about adding some options that are specifically numbers like number of menu levels or number of posts to display on the homepage. Is it possible to check that the input in the customizer is just a number? And perhaps a certain limit like 5 for menu levels and 20 or something for posts on the homepage? Here is the code I'm working on with the customizer api as an example:

$wp_customize->add_setting( 'posts_number_home' , array(
'default'     => '10',
'transport'   => 'refresh',
'sanitize_callback' => 'sanitize_text_field',
) );

$wp_customize->add_control( new WP_Customize_Control( 
$wp_customize, 
'posts_number_home',
array(
    'section'  => 'mytheme_options',
    'settings' => 'posts_number_home',
    'type' => 'text',
    'priority' => 10,
) 
));
  • Can you put 'type' => 'number'? So that they can't put text in? – ngearing Jun 29 '16 at 4:00
  • Hmm well that would make sense wouldn't it haha. Found this page in the codex that says number is supported "implicitly" as a variation of the text type, but not sure what that means exactly... codex.wordpress.org/Class_Reference/WP_Customize_Control – jetyet47 Jun 29 '16 at 4:09
1

Think I figured it out. Type number definitely works not allowing text input. And it includes little arrow counters for the user. And you can add min max attributes. Someone let me know if this is incorrect in any way, particularly the sanitization.

$wp_customize->add_setting( 'posts_number_home' , array(
'default'     => '10',
'transport'   => 'refresh',
'sanitize_callback' => 'sanitize_text_field',
) );

$wp_customize->add_control( new WP_Customize_Control( 
$wp_customize, 
'posts_number_home',
array(
    'label'    => __( 'Number of posts to display on homepage', 'mytheme' ), 
    'section'  => 'mytheme_options',
    'settings' => 'posts_number_home',
    'type' => 'number',
    'priority' => 10,
    'input_attrs' => array(
    'min'   => 1,
    'max'   => 10,)
) 
));
  • Just a note. It seems that you want integer numbers, so I would use intval as sanitize_callback argument. – cybmeta Jun 29 '16 at 7:00
0

You are right. A couple of fixes/suggestions, though.

  • You should use absint as a sanitization callback.
  • Also, you don't have to explicitly use the WP_Customize_Control class. The number field can be created with the regular syntax you use for the text field with an exception of the type and additional attributes.
  • Another thing is that you don't have to define the refresh transport method since it is used by default.

So the refined snippet should look something like this:

$wp_customize->add_setting( 'posts_number_home' , array(
    'default'           => 10,
    'sanitize_callback' => 'absint',
) );

$wp_customize->add_control( 'posts_number_home', array(
    'label'    => __( 'Number of posts to display on homepage', 'mytheme' ), 
    'section'  => 'mytheme_options',
    'settings' => 'posts_number_home',
    'type'     => 'number',
    'priority' => 10,
    'input_attrs' => array(
        'min' => 1,
        'max' => 10
    )
) );

Edit 07/01/2016: Using intval is not correct because Customizer secretly passes the second object parameter to sanitization callback, while intval expects an optional integer. So the best way to sanitize non-negative integer is absint.

  • This doesn't work using intval for the sanitization callback. It won't save the value. But if I switch back to sanitize_text_field, then it does start working again. Any idea what's up? – jetyet47 Jul 1 '16 at 0:06
  • In fact, yes. absint is the correct way because Customizer secretly passes second object parameter to the callback, while intval expects the integer base for the conversion. absint, on the other hand, only expects one parameter, so it works as expected. – Dmitry Mayorov Jul 1 '16 at 3:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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