Make WordPress Core

Opened 12 years ago

Closed 12 years ago

#20132 closed defect (bug) (invalid)

Custom Background Image issue

Reported by: nhuja's profile nhuja Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.3.1
Component: Themes Keywords: revert has-patch
Focuses: Cc:


When a theme uses a body background image and we change the background image from custom background menu, it works beautifully. But if we do not set the background and change the color only, it doesn't replace the theme's background image. A fix would be to add

background-image: none;

if there is no background image in the custom background page. Can this be fixed? I am having an issue with this since my theme uses background image by default in the body tag..

Attachments (1)

20132.diff (3.1 KB) - added by nacin 12 years ago.

Download all attachments as: .zip

Change History (13)

#1 @SergeyBiryukov
12 years ago

  • Component changed from General to Themes

#2 @SergeyBiryukov
12 years ago

(Temporarily?) fixed in [20973], but that seems to have caused a back compat issue, according to the IRC logs and the latest comments on #20448.

Last edited 12 years ago by SergeyBiryukov (previous) (diff)

#3 @nacin
12 years ago

  • Milestone changed from Awaiting Review to 3.4
  • Resolution set to fixed
  • Status changed from new to closed

Fixed in [21001], #20448.

#4 @nacin
12 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

My thoughts on this:

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 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).

And so, I think we should make it clear that default background images are not specified in the CSS. Suggesting a partial revert of this. Patch on the way.

12 years ago

#5 @nacin
12 years ago

20132.diff is a partial revert of [21001], and [21013]. This restores the functionality to be the same as 3.3 with regards to background images. A theme like Adventure Journal that defines BACKGROUND_IMAGE but also defines that image in the stylesheet should remove the image from the stylesheet.

#6 @nacin
12 years ago

  • Keywords revert has-patch added

#7 @mfields
12 years ago

  • Cc michael@… added

I just tested 20132.diff locally and it looks pretty solid to me.

Is there no way to specify the background properties via styles.css? The only reason I am pushing for this is - for very large documents on slowish connections - there can be a flash of unstyled background. Moving the background styles to style.css seems to fix this.

#8 @nacin
12 years ago

The only reason I am pushing for this is - for very large documents on slowish connections - there can be a flash of unstyled background.

Are you referring to the customizer in particular?

#9 @nacin
12 years ago

Thinking aloud, if a theme wanted to include a background-image in the stylesheet, as a fallback in case, for example, remove_theme_support('custom-background') is called, then this would work:

body { background-image: url( ... ); }
body.custom-background { background-image: none }

Then the inline body.custom-background style would take over.

#10 @ryan
12 years ago

20132.diff looks good.

#11 @nacin
12 years ago

In [21054]:

Do not specify background-image: none when a user removes a custom background
on a theme that has a default background image.

The onus is on the theme to omit the default background-image from style.css,
to allow the user to remove the default background image. Or, the theme can
specify a background-image for the body selector, as long as they then zero
it out for body.custom-background, like so:

body {
	background-image: url( ... );
body.custom-background {
	background-image: none;

This allows the theme to be compatible with the custom background feature
but also gracefully degrade if the background feature is disabled.

This is the same behavior as 3.3; setting a default image has simply been
made more prominent in 3.4. Reverts [21013], also parts of [21001].
see #20448 for change and discussion history.

see #20132, which will now be marked as invalid.

Also, per previous changes in #20448, the custom-background class should not
be shown when only a default color is in use.

fixes #20448.

#12 @nacin
12 years ago

  • Milestone 3.4 deleted
  • Resolution set to invalid
  • Status changed from reopened to closed

This ticket is invalid per [21054].

Last edited 12 years ago by SergeyBiryukov (previous) (diff)
Note: See TracTickets for help on using tickets.