<div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 30, 2014 at 10:35 AM, Srikanth Koneru <span dir="ltr"><<a href="mailto:tskk79@gmail.com" target="_blank">tskk79@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">If i add 'capability' => 'unfiltered_html' then can i skip 'sanitize_callback' => 'prefix_sanitize_integer' ?<br>

</div><div class=""><div class="h5"><div class="gmail_extra"></div></div></div></blockquote></div><br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">.. I'm not sure that that question actually makes sense.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">If you were allowing only integer inputs, then you wouldn't also require the unfiltered_html capability.</div><div class="gmail_extra"><br></div><div class="gmail_extra">

- Capability determines "who" is allowed to change a setting.</div><div class="gmail_extra">- Sanitization is used to make sure that the value they put into a setting is valid.<br><div><br></div><div>So, if a setting should only have integers in it, then 'sanitize_callback' => 'absint' would be what you want to use.</div>

<div><br></div><div>If only people with the ability to post raw HTML should have access to a setting, then it should have 'capability' => 'unfiltered_html'.</div><div><br></div><div>These two things are somewhat different in nature, and ideally you will have both for all cases.</div>

<div><br></div><div>For example, having 'capability' => 'edit_theme_options' makes sense for almost all cases, because if a user isn't allowed to edit theme options, then they shouldn't really be in the customizer. This is why this is the default for customizer-settings. </div>

<div><br></div><div>But for some cases, you're allowing users to change other things through the customizer. For example, the core blog-name is exposed in the customizer, using 'capability' => 'manage_options'. This means that only people who have manage_options (admins, basically) can change that setting.</div>

<div><br></div><div>The sanitize_callback, on the other hand, is dealing with what happens *after* they submit the setting. Before it's saved in the database, you want to make sure it looks like what it is supposed to look like. If it's supposed to be an HTML color, then you'd run it through <span style="color:rgb(85,85,85);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:18.200000762939453px">sanitize_hex_color. If it's supposed to be an integer, then you'd run it through intval or absint. That sort of thing.</span></div>

<div><div class="gmail_extra"><br></div><div class="gmail_extra"><div>-Otto</div><div><br></div></div></div></div></div>