Somehow I missed a lot of emails in this thread making my last rather redundant.<br><br><br clear="all">Cais.<br>
<br><br><div class="gmail_quote">On Mon, Jun 11, 2012 at 8:36 PM, Edward Caissie <span dir="ltr"><<a href="mailto:edward.caissie@gmail.com" target="_blank">edward.caissie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>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.<br>
<br><br clear="all">Cais.<div class="HOEnZb"><div class="h5"><br>
<br><br><div class="gmail_quote">On Mon, Jun 11, 2012 at 8:05 PM, Otto <span dir="ltr"><<a href="mailto:otto@ottodestruct.com" target="_blank">otto@ottodestruct.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Mon, Jun 11, 2012 at 6:43 PM, Edward Caissie<br>
<<a href="mailto:edward.caissie@gmail.com" target="_blank">edward.caissie@gmail.com</a>> wrote:<br>
> While its all well and good if the Parent-Theme implements the<br>
> add_theme_support( 'custom-background' ) with default parameters set to some<br>
> value but this then requires the Child-Theme must implement the same<br>
> functionality if the background is to be anything other than the<br>
> Parent-Theme's default (as noted by Philip).<br>
<br>
</div>That's not the case with the current code (post changeset 21054). That<br>
changeset reverted the behavior to the same as 3.3. Which is, IMO, the<br>
wrong behavior, but it is what it is, and what it is is 100%<br>
backwards-compatible.<br>
<br>
If a parent theme defines a default with add-theme-support, and the<br>
default has been "removed" by the user, then whatever the child has in<br>
the stylesheet will take effect. No "custom-background" class will be<br>
added to the body_class.<br>
<div><br>
<br>
> Again this is not really an issue for *new* Child-Themes but it will be an<br>
> issue for existing Child-Themes ... how many installations will this affect?<br>
><br>
> Unknown, but it also the reason why I advocated existing themes that<br>
> implement the add_theme_support( 'custom-background' ) do so with no default<br>
> $args being set so as not to "break" existing (and quite likely unknown)<br>
> Child-Themes.<br>
<br>
</div>Themes that now add a new default-image where there was no<br>
default-image before will be affected only if no custom-background was<br>
ever chosen by the user and the child-theme did-it-wrong by defining<br>
the default image via CSS.<br>
<br>
*This is not a breaking-change*. The same thing can happen with 3.3<br>
alone, if a parent-theme suddenly defines the BACKGROUND_IMAGE<br>
constant, which does more or less the exact same thing and has ever<br>
since custom backgrounds have been around.<br>
<br>
Given that the parent theme already had custom background UI for users<br>
to use, then I would hope it wouldn't affect anybody.<br>
- If they used the UI to make background images, then nothing breaks.<br>
- If the parent doesn't define a default-background in the future,<br>
then nothing breaks.<br>
<br>
In Phillip's case, he's saying that he's been making child-themes for<br>
clients, and using the style.css to add background images instead of<br>
using the custom-background UI of the parent theme. And yes, those<br>
cases will be affected if-and-only-if the parent theme suddenly<br>
changes to define a default-image. But this isn't new, if the parent<br>
defined the BACKGROUND_IMAGE, then the exact same thing would have<br>
occurred.<br>
<br>
It's a timebomb that's always been there. Maybe the fuse is a bit<br>
shorter now that theme authors can more easily define default-image,<br>
but I don't see that as a reason to restrict the usefulness of the<br>
feature to theme authors.<br>
<div><br>
<br>
> Perhaps this falls into more of a PSA when using this feature, as it's not<br>
> really a bug ... or is it?!<br>
<br>
</div>It's not a bug. It may be a lack of foresight by child-theme creators.<br>
<div><div><br>
<br>
-Otto<br>
_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>