[theme-reviewers] WP.org theme preview

[Doug Stewart]

This contradicts a hard-and-fast WPTRT rule: NO MULTIPLE OPTIONS.

Otto, unless there's a different way to handle get_option() for
serialized arrays and define a default that way, I can't see any way
of satisfying both requirements simultaneously.


On Wed, Aug 3, 2011 at 6:18 PM, Chip Bennett <chip at chipbennett.net> wrote:
> 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
>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>



-- 
-Doug