<div class="gmail_quote">On Wed, Aug 3, 2011 at 4:47 PM, Otto <span dir="ltr"><<a href="mailto:otto@ottodestruct.com">otto@ottodestruct.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div>
Basically, you wrote your theme wrong. It should function properly without any options being set at all. Options are *optional* and you should have default fallbacks for all of them.</div><div><br></div><div>Setting options on activation is a big no-no. Don't do it. I'll remove a theme from the system for doing that. It's bad code, bad karma, and it often breaks the theme previewer.</div>
</div></blockquote><div><br></div><div>I have problems with this:</div><div><br></div><div>1) The Theme Review Guidelines don't currently say anything about handling of default options, or how to initialize them. I don't agree with a unilateral, blanket statement (or action) of removing Themes based on this criterion.</div>
<div>2) Any such statement (or action) would impact almost EVERY SINGLE THEME with Theme Options in the repository. </div><div><br></div><div>There is no security issue, or any other similarly egregious concern, with this issue. Thus, it needs to be implemented in the Guidelines following the usual procedure.</div>
<div><br></div><div>Personally, I think the matter needs to be discussed before being added to the Guidelines; however, if it is a matter of "pulling rank" here, so be it. Just let us know if that's the case, so that we can add it to the Guidelines.</div>
<div><br></div><div>But even if we add it to the Guidelines, based either on community discussion or an "above our pay grade" decision, it needs to follow the established timeline: that is to say, it won't become *required* until WordPress 3.3 is released.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
<div><br></div><div>Write your theme options code such that it doesn't need to have the options actually there to begin with. get_option has a second parameter to specify a default if needed. If you're using one-big-options-array, then you should have code to account for the fact that the option might not be in the array. That sort of thing.</div>
<div><br></div></div></blockquote><div>I do like this as a matter of suggested best-practice, at least in the template-file output. I think it could be a bit impractical in the Admin Settings Page option form, but I'm going to explore implementing in Oenology.</div>
<div><br></div><div>Chip</div></div>