[theme-reviewers] WP.org theme preview
chip at chipbennett.net
Wed Aug 3 22:18:22 UTC 2011
Again: I'm not arguing what's best-practice. (I certainly concede that
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.
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
> > of default options, or how to initialize them. I don't agree with a
> > unilateral, blanket statement (or action) of removing Themes based on
> > criterion.
> It's not really a matter of guidelines. It's simply a bad way to write
> > 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.
> $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(
> $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.
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the theme-reviewers