The body class "custom-background" is staying even after clearing everything
from the appearance -> background
<style type="text/css" id="custom-background-css">
body.custom-background { background-image: none; }
</style>
<body class="home blog logged-in admin-bar custom-background user-guest
gecko am night morning mon layout-3c">
On Mon, Jun 11, 2012 at 5:13 AM, Philip M. Hofer (Frumph) <philip@...> wrote: > The body class "custom-background" is staying even after clearing everything > from the appearance -> background Confirmed. I reopened http://core.trac.wordpress.org/ticket/20448 with a patch. Thanks for the report.
On Mon, Jun 11, 2012 at 4:37 AM, Jon Cave <jon@...> wrote: > On Mon, Jun 11, 2012 at 5:13 AM, Philip M. Hofer (Frumph) > <philip@...> wrote: > > The body class "custom-background" is staying even after clearing > everything > > from the appearance -> background > > Confirmed. I reopened http://core.trac.wordpress.org/ticket/20448 with a > patch. > > Thanks for the report. Frumph — Best I can tell, this is not actually a bug. I don't think you "cleared everything" from Appearance > Background. You pressed "Remove Background Image," but your theme registers a default image, either via the BACKGROUND_IMAGE constant (old) or the default-image argument passed to add_theme_support() (3.4). As you "removed" that image, we have to print out a "background-image: none", in order to override any background image references in the stylesheet. If your theme registers a default image, we are always going to print body.custom-background. But, if your theme does not register a default image and you do register a default color, then there is a small bug: If you have no customizations at(Continue reading)
Sorry champ, if it works that way then I will not support giving themes the default. Bad programming. Why? Because no matter what happens, because of order of execution the custom-background and background-image: none; will ALWAYS overwrite it. -----Original Message----- From: Andrew Nacin Sent: Monday, June 11, 2012 10:57 AM To: wp-testers@... Subject: Re: [wp-testers] Problem with appearance -> background On Mon, Jun 11, 2012 at 4:37 AM, Jon Cave <jon@...> wrote: > On Mon, Jun 11, 2012 at 5:13 AM, Philip M. Hofer (Frumph) > <philip@...> wrote: > > The body class "custom-background" is staying even after clearing > everything > > from the appearance -> background > > Confirmed. I reopened http://core.trac.wordpress.org/ticket/20448 with a > patch. > > Thanks for the report. Frumph —(Continue reading)
Sorry, didn't see your comment at the bottom about behavior being off Expected behavior - Theme registered a background color or image - custom-background class enabled printf of the background css. Theme cleared of background color and image. custom-background class doesn't exist AND printf of background css non-existant Child Theme registered a background color or image - custom background class enabled and primary themes defaults replaced with child themes registration overrides in the printf of the background css ______________ If you test it, you will see that when you create "defaults" it overrides everything including any changes the end user might want to make, they are forever stuck with using appearance -> background. Theme creators like myself, and I can only speak for myself in this regard see it as a potential boon to my theme to have the default background and color enabled in the appearance -> background. But, unfortunately if a child theme is added to it - the main theme overrides anything the child themes look has immediately. Regardless. Its 'an extra setup step' to use the appearance -> background at that time, making the end user put the information into the appearance -> background just because it wasn’t programmed to replace info or be empty if removed. -----Original Message-----(Continue reading)
To comment on: <at> Nacin: As you "removed" that image, we have to print out a "background-image: none", in order to override any background image references in the stylesheet. I want it to revert to the background references in the stylesheet. ref: last email sent to thread, child themes overriding and execution css order. -----Original Message----- From: Philip M. Hofer (Frumph) Sent: Monday, June 11, 2012 11:13 AM To: wp-testers@... Subject: Re: [wp-testers] Problem with appearance -> background Sorry, didn't see your comment at the bottom about behavior being off Expected behavior - Theme registered a background color or image - custom-background class enabled printf of the background css. Theme cleared of background color and image. custom-background class doesn't exist AND printf of background css non-existant Child Theme registered a background color or image - custom background class enabled and primary themes defaults replaced with child themes registration overrides in the printf of the background css ______________(Continue reading)
It sorta strikes me that if you're using custom background functionality, then you shouldn't have any background image references in the main stylesheet. You should instead define a default image with the custom background code. Like, maybe a user doesn't want a background image and just wants a solid color instead. Selecting "no image" is a valid selection too. -Otto On Mon, Jun 11, 2012 at 1:17 PM, Philip M. Hofer (Frumph) <philip@...> wrote: > To comment on: > <at> Nacin: As you "removed" that image, we have to print out a > "background-image: > > none", in order to override any background image references in the > stylesheet. > > I want it to revert to the background references in the stylesheet. ref: > last email sent to thread, child themes overriding and execution css order. >
True, but no matter what you do via plugin ( like theme companion or even a child theme ) because of order of execution, it will always be background-image: none; when you remove the image that was default. -----Original Message----- From: Otto Sent: Monday, June 11, 2012 11:33 AM To: wp-testers@... Subject: Re: [wp-testers] Problem with appearance -> background It sorta strikes me that if you're using custom background functionality, then you shouldn't have any background image references in the main stylesheet. You should instead define a default image with the custom background code. Like, maybe a user doesn't want a background image and just wants a solid color instead. Selecting "no image" is a valid selection too. -Otto On Mon, Jun 11, 2012 at 1:17 PM, Philip M. Hofer (Frumph) <philip@...> wrote: > To comment on: > <at> Nacin: As you "removed" that image, we have to print out a > "background-image: > > none", in order to override any background image references in the > stylesheet. > > I want it to revert to the background references in the stylesheet. ref:(Continue reading)
On Mon, Jun 11, 2012 at 2:33 PM, Otto <otto@...> wrote: > It sorta strikes me that if you're using custom background > functionality, then you shouldn't have any background image references > in the main stylesheet. You should instead define a default image with > the custom background code. > > Like, maybe a user doesn't want a background image and just wants a > solid color instead. Selecting "no image" is a valid selection too. This is why 3.4 will actually issue a background-image: none; when there is a registered default but the user does not want a background --- in order to override any stylesheet values. With regards to child themes, if a child theme wants to override a parent theme's default settings, then they should be doing it via PHP, not via CSS. That means either calling add_theme_support() and setting default-image to its own value (or to false), or calling remove_theme_support(). If we make it clear that default background images should *not* be specified in CSS, then we can just remove the "background-image: none" stuff, and it would allow a child theme to provide a CSS background-image as long as the user also presses "Remove Background Image" in Appearance. That would make http://core.trac.wordpress.org/ticket/20132 invalid, would simplify some of our logic, would probably be less of a backwards compatibility risk, and would avoid stomping on custom CSS (even though the child theme should probably be using the API properly). Nacin(Continue reading)
On Mon, Jun 11, 2012 at 2:44 PM, Andrew Nacin <wp@...> wrote: > On Mon, Jun 11, 2012 at 2:33 PM, Otto <otto@...> wrote: > >> It sorta strikes me that if you're using custom background >> functionality, then you shouldn't have any background image references >> in the main stylesheet. You should instead define a default image with >> the custom background code. >> >> Like, maybe a user doesn't want a background image and just wants a >> solid color instead. Selecting "no image" is a valid selection too. > > > This is why 3.4 will actually issue a background-image: none; when there is > a registered default but the user does not want a background --- in order > to > override any stylesheet values. > > With regards to child themes, if a child theme wants to override a parent > theme's default settings, then they should be doing it via PHP, not via > CSS. > That means either calling add_theme_support() and setting default-image > to its own value (or to false), or calling remove_theme_support(). > > If we make it clear that default background images should *not* be > specified > in CSS, then we can just remove the "background-image: none" stuff, > and it would allow a child theme to provide a CSS background-image as long > as the user also presses "Remove Background Image" in Appearance. >(Continue reading)
RSS Feed10 | |
|---|---|
7 | |
1 | |
22 | |
8 | |
17 | |
2 | |
35 | |
15 | |
3 | |
24 | |
15 | |
12 | |
40 | |
59 | |
15 | |
8 | |
10 | |
56 | |
42 | |
34 | |
35 | |
57 | |
144 | |
126 | |
51 | |
42 | |
52 | |
21 | |
37 | |
357 | |
457 | |
352 | |
209 | |
72 | |
17 | |
20 | |
97 | |
35 | |
15 | |
34 | |
123 | |
145 | |
73 | |
87 | |
99 | |
181 | |
159 | |
634 | |
929 | |
517 | |
150 | |
173 | |
247 | |
132 | |
193 | |
227 | |
1510 | |
285 | |
174 | |
133 | |
95 | |
195 | |
412 | |
86 | |
25 | |
112 | |
239 | |
124 | |
198 | |
149 | |
532 | |
135 | |
160 | |
138 | |
242 | |
94 | |
156 | |
67 | |
28 | |
52 | |
170 | |
161 | |
397 | |
557 | |
583 | |
23 |
