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

[Chip Bennett]

I think this is the real key here:

**Neither* the parent nor the child should be attempting to adjust the
background image in the style.css file at this point.*


The only real issue is: right now, Themes are *not* required to support
custom backgrounds. Should custom-background support criticality be bumped
up from *recommended* to *required*?

Chip

On Mon, Jun 11, 2012 at 1:49 PM, Otto <otto at ottodestruct.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20120611/522c1ef4/attachment.htm>