[theme-reviewers] WP.org theme preview

[Chip Bennett]

Again: I'm not arguing what's best-practice. (I certainly concede that
point.)

Rather: I'm arguing against the "I'll remove any Theme that initializes
default options" statement.

"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.

Chip

On Wed, Aug 3, 2011 at 5:12 PM, Otto <otto at ottodestruct.com> wrote:

> On Wed, Aug 3, 2011 at 5:02 PM, Chip Bennett <chip at chipbennett.net> wrote:
> > 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.
>
> It's not really a matter of guidelines. It's simply a bad way to write
> code.
>
> > 2) Any such statement (or action) would impact almost EVERY SINGLE THEME
> > with Theme Options in the repository.
>
> Not at all. It's perfectly easy to have theme options with defaults.
> Just don't set them by default when nobody actually changes them. I've
> posted about this here before.
>
> Basically, if you have an init function that does something like a)
> check for options and then b) set options if they're not set, then
> you're doing it wrong. Nobody wants a theme setting a bunch of crap in
> the database the moment it's activated. It's totally unnecessary.
>
> Example:
>
> $my_option = get_option('my_option', 'default');
>
> If the my_option is set, then it's gotten from the database.
> Otherwise, it is "default". This is the proper way to do defaults.
>
> Example 2: Using a big-array-of-options.
>
> $defaults = array(
>  'option1'=>'value1',
>  'option2'=>'value2',
>  //etc
> );
> $options = wp_parse_args( get_option('theme-options',array() ), $defaults);
>
> Any option not set in the theme-options array will get the default
> value used for it instead in the resulting $options array.
>
> Defaults should be set in variables at the time of getting the
> options, not pre-set and shoved into the database at some kind of init
> or activation time. This is simply because you cannot tell on what
> sort of setup your code will be running for sure, and you don't know
> what's in the database in advance. The contents of the database are
> outside your control and can be changed by other things, basically, so
> your code should be written with that in mind.
>
> For example, in the theme-previewer, we might just implement a
> no-options policy by making the tables read-only (that is one of the
> long term plans, in fact). So setting defaults in the DB on such a
> setup certainly wouldn't work.
>
> -Otto
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20110803/72262a1d/attachment-0001.htm>