WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 23 months ago

#20132 closed defect (bug) (invalid)

Custom Background Image issue

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

Description

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 23 months ago.

Download all attachments as: .zip

Change History (13)

comment:1 SergeyBiryukov23 months ago

  • Component changed from General to Themes

comment:2 SergeyBiryukov23 months ago

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

Version 0, edited 23 months ago by SergeyBiryukov (next)

comment:3 nacin23 months ago

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

Fixed in [21001], #20448.

comment:4 nacin23 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

My thoughts on this: http://lists.automattic.com/pipermail/wp-testers/2012-June/014495.html

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

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.

nacin23 months ago

comment:5 nacin23 months 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.

comment:6 nacin23 months ago

  • Keywords revert has-patch added

comment:7 mfields23 months 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.

comment:8 nacin23 months 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?

comment:9 nacin23 months 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.

comment:10 ryan23 months ago

20132.diff looks good.

comment:11 nacin23 months 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.

comment:12 nacin23 months ago

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

This ticket is invalid per [21054].

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