[theme-reviewers] Something we need to check for 3.4 appearance -> background

[Philip M. Hofer (Frumph)]

This is going to be another one of those situations where I am going to have 
to explain how to go and turn on the ability to turn off comments because 
the default was set to not show it.   I write 20 emails a week explaining 
how to go to screen options to enable that ability.

The simple thing about it is, if a custom background image and color is not 
used, then the CSS for it for custom-background and the class should not 
exist.

Whatever default in the style.css of either the parent or child is 
inconsequential and up to the designer.  Not the core.




-----Original Message----- 
From: Otto
Sent: Monday, June 11, 2012 11:49 AM
To: theme-reviewers at lists.wordpress.org
Subject: Re: [theme-reviewers] Something we need to check for 3.4 
appearance -> background

I think you've got this backwards, man.

Child theme's have their functions.php files executed first. So if
they call add_theme_support('custom_background,$args); with the
$args['default-image'] set, then they can easily override the default
image of the parent theme. Look at how add_theme_support handles
multiple calls.

In other words, if child has this:
add_theme_support( 'custom_background, array( 'default-image'=>'foo' ) );

and the parent has this:
add_theme_support( 'custom_background, array( 'default-image'=>'bar' ) );

Then the default image will be "foo".

*Neither* the parent nor the child should be attempting to adjust the
background image in the style.css file at this point.
Custom-backgrounds mean that the background is chosen by the user, not
by the theme. The theme is defining defaults and letting the user
choose. Attempting to change it in the style.css file directly isn't
letting the user choose anymore.

-Otto


On Mon, Jun 11, 2012 at 1:33 PM, Philip M. Hofer (Frumph)
<philip at frumph.net> wrote:
> Because of the coding of how appearance -> background works in 3.4 there 
> is
> going to be a problem with 'parent' themes setting default images and 
> colors
> to their theme. (probably just images from what I read)
>
> The problem:
>
> If a parent theme sets an image as a default in the $args,  it will 
> forever
> then be required to use the appearance -> background
>
> Why:
>
> Order of execution, even if you remove the background image and color from
> the background -> appearance it still sets background-image: none;  even
> after cleared.
>
> What this does?
>
> This makes it so that any image set from the style.css either child theme 
> or
> parent theme or even plugin will be ignored completely.
>
> -------
>
> What we need to look for.
>
> If the theme in question ever wants to have child themes associated with 
> it,
> then the main theme must *not* set defaults in the $args in 3.4
>
> Since we want everyone to be child theme capable.   Then if any defaults 
> are
> set in the parent theme they need to be removed or child themes simply 
> will
> not work when setting a new image for that child theme.
>
>
> ---
>
> This might change if the logic changes before release, but this is how it 
> is
> right now.  according to:
>
> http://core.trac.wordpress.org/ticket/20448
>
>
>
>
> _______________________________________________
> 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