Again: I'm not arguing what's best-practice. (I certainly concede that point.)<div><br></div><div>Rather: I'm arguing against the "I'll remove any Theme that initializes default options" statement.</div>
<div><br></div><div>"Bad code" is not inherently a reason to suspend Themes. And if we want to make it a Guideline, that's great; but I see no reason not to follow our established procedure for making such changes.</div>
<div><br></div><div>Chip</div><div><br><div class="gmail_quote">On Wed, Aug 3, 2011 at 5:12 PM, Otto <span dir="ltr"><<a href="mailto:otto@ottodestruct.com">otto@ottodestruct.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Aug 3, 2011 at 5:02 PM, Chip Bennett <<a href="mailto:chip@chipbennett.net">chip@chipbennett.net</a>> wrote:<br>
> 1) The Theme Review Guidelines don't currently say anything about handling<br>
> of default options, or how to initialize them. I don't agree with a<br>
> unilateral, blanket statement (or action) of removing Themes based on this<br>
> criterion.<br>
<br>
</div>It's not really a matter of guidelines. It's simply a bad way to write code.<br>
<div class="im"><br>
> 2) Any such statement (or action) would impact almost EVERY SINGLE THEME<br>
> with Theme Options in the repository.<br>
<br>
</div>Not at all. It's perfectly easy to have theme options with defaults.<br>
Just don't set them by default when nobody actually changes them. I've<br>
posted about this here before.<br>
<br>
Basically, if you have an init function that does something like a)<br>
check for options and then b) set options if they're not set, then<br>
you're doing it wrong. Nobody wants a theme setting a bunch of crap in<br>
the database the moment it's activated. It's totally unnecessary.<br>
<br>
Example:<br>
<br>
$my_option = get_option('my_option', 'default');<br>
<br>
If the my_option is set, then it's gotten from the database.<br>
Otherwise, it is "default". This is the proper way to do defaults.<br>
<br>
Example 2: Using a big-array-of-options.<br>
<br>
$defaults = array(<br>
'option1'=>'value1',<br>
'option2'=>'value2',<br>
//etc<br>
);<br>
$options = wp_parse_args( get_option('theme-options',array() ), $defaults);<br>
<br>
Any option not set in the theme-options array will get the default<br>
value used for it instead in the resulting $options array.<br>
<br>
Defaults should be set in variables at the time of getting the<br>
options, not pre-set and shoved into the database at some kind of init<br>
or activation time. This is simply because you cannot tell on what<br>
sort of setup your code will be running for sure, and you don't know<br>
what's in the database in advance. The contents of the database are<br>
outside your control and can be changed by other things, basically, so<br>
your code should be written with that in mind.<br>
<br>
For example, in the theme-previewer, we might just implement a<br>
no-options policy by making the tables read-only (that is one of the<br>
long term plans, in fact). So setting defaults in the DB on such a<br>
setup certainly wouldn't work.<br>
<font color="#888888"><br>
-Otto<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
</div></div></blockquote></div><br></div>