[theme-reviewers] Something we need to check for 3.4 appearance -> background
edward.caissie at gmail.com
Tue Jun 12 00:36:51 UTC 2012
The use-case I was describing actually affects one of my clients with a
Child-Theme that pre-dates the custom background additions ... granted I
happen to like this client and will be more than happy to add the few lines
of code to sort this out to current "standards" (at no charge ... it is a
Five-Minute-Fix after all); and, I am willing to accept I should have
addressed this in all client Child-Themes months ago, but ... if it works
you don't fix it.
Which leaves the dilemma, do I implement custom-backgrounds as you (@Otto)
are recommending whereas I set the default I have chosen for the theme, and
let the chips fall where they may ... or do I continue with not setting the
defaults and leaving the background styles in the stylesheet where they
have been from the theme's inception.
On Mon, Jun 11, 2012 at 8:05 PM, Otto <otto at ottodestruct.com> wrote:
> On Mon, Jun 11, 2012 at 6:43 PM, Edward Caissie
> <edward.caissie at gmail.com> wrote:
> > While its all well and good if the Parent-Theme implements the
> > add_theme_support( 'custom-background' ) with default parameters set to
> > value but this then requires the Child-Theme must implement the same
> > functionality if the background is to be anything other than the
> > Parent-Theme's default (as noted by Philip).
> That's not the case with the current code (post changeset 21054). That
> changeset reverted the behavior to the same as 3.3. Which is, IMO, the
> wrong behavior, but it is what it is, and what it is is 100%
> If a parent theme defines a default with add-theme-support, and the
> default has been "removed" by the user, then whatever the child has in
> the stylesheet will take effect. No "custom-background" class will be
> added to the body_class.
> > Again this is not really an issue for *new* Child-Themes but it will be
> > issue for existing Child-Themes ... how many installations will this
> > Unknown, but it also the reason why I advocated existing themes that
> > implement the add_theme_support( 'custom-background' ) do so with no
> > $args being set so as not to "break" existing (and quite likely unknown)
> > Child-Themes.
> Themes that now add a new default-image where there was no
> default-image before will be affected only if no custom-background was
> ever chosen by the user and the child-theme did-it-wrong by defining
> the default image via CSS.
> *This is not a breaking-change*. The same thing can happen with 3.3
> alone, if a parent-theme suddenly defines the BACKGROUND_IMAGE
> constant, which does more or less the exact same thing and has ever
> since custom backgrounds have been around.
> Given that the parent theme already had custom background UI for users
> to use, then I would hope it wouldn't affect anybody.
> - If they used the UI to make background images, then nothing breaks.
> - If the parent doesn't define a default-background in the future,
> then nothing breaks.
> In Phillip's case, he's saying that he's been making child-themes for
> clients, and using the style.css to add background images instead of
> using the custom-background UI of the parent theme. And yes, those
> cases will be affected if-and-only-if the parent theme suddenly
> changes to define a default-image. But this isn't new, if the parent
> defined the BACKGROUND_IMAGE, then the exact same thing would have
> It's a timebomb that's always been there. Maybe the fuse is a bit
> shorter now that theme authors can more easily define default-image,
> but I don't see that as a reason to restrict the usefulness of the
> feature to theme authors.
> > Perhaps this falls into more of a PSA when using this feature, as it's
> > really a bug ... or is it?!
> It's not a bug. It may be a lack of foresight by child-theme creators.
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the theme-reviewers