Make WordPress Core

Opened 13 years ago

Closed 8 years ago

#16919 closed defect (bug) (wontfix)

style.css can sometimes conflict with custom background image

Reported by: nathanrice's profile nathanrice Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: Customize Keywords: has-patch dev-feedback
Focuses: Cc:


Steps to repeat:

  1. Theme with the following body style (or something similar):
body {
	background: url(images/texture.jpg) #fff;
  1. Use add_custom_background(); in functions.php
  1. Select custom bg color, but no custom bg image.
  1. View site. Custom bg color shows under the default background image, looks strange. No way to eliminate the use of textured or patterned background without editing style.css.

Intended result would be that if no bg image is chosen, none is needed.

Attached patch should address this.

Attachments (1)

16919.diff (388 bytes) - added by nathanrice 13 years ago.
Create else exception when custom bg color is chosen, but no custom bg image.

Download all attachments as: .zip

Change History (18)

13 years ago

Create else exception when custom bg color is chosen, but no custom bg image.

#1 @nacin
13 years ago

Closed #17102 as a duplicate. Not sure if I see a bug here -- seems like this should be taken care of by a theme callback, no?

#2 @nathanrice
13 years ago

it's definitely a bug. Never noticed it until our themes started manifesting the bug. If a person chooses a BG color but no BG image, the intended result can't be achieved without editing the CSS. And since the idea behind custom BG image is to do things without having to edit CSS, seems like a bug to me.

Sure, a custom callback would work. But why bother? Custom background is supposed to be 1-line easy. A custom callback seems like unnecessary overhead for a theme to have to include just to accommodate for a single else exception.

#3 @nacin
13 years ago

True, but it's not out of the question to think that someone might want to keep the specified background image but just change the color.

#4 @nathanrice
13 years ago

I hear you. But custom background doesn't have the constants for a default background image like custom header does. So a user can't really specify that they don't want to use the default background.

While it's true that your scenario is possible, I think it's just as, if not more likely that they're trying to change the look of the theme, and don't want the original background image to show up

Generally, if an image is used as a background for a site, it's either fully tiled (thus making a background color unnecessary) or tiled horizontally (meaning it needs to blend into the background color, most likely, which the theme author should specify in CSS) or static (which has the same implications as horizontal tiling). In any of those cases, setting a different background color with the original image probably won't look good anyway.

If we start talking about transparent PNG files, then the story changes a bit, I know. But that's still the exception.

To me, nixing the background image if no background image is specified in the admin covers more, and the more likely, scenarios.

#5 @toscho
13 years ago

  • Cc info@… added

Instead of guessing what a hypothetical user may want – couldn’t we just ask him? Add a checkbox to the background options page:

[×] Use default background image

I think this would be most predictable for both, theme authors and end users, and we would know exactly when to insert background-image: none.

#6 @nathanrice
13 years ago

That would take some work. Instead of a checkbox like that, we'd need to have some sort of system, like custom header, for defining the default background image, and a button to remove it (like custom header).

And that defeats the purpose of simplicity that the add_custom_background(); call was supposed to introduce.

#7 @pseudoxiah
13 years ago

  • Cc contact@… added

#8 @iandstewart
13 years ago

  • Cc ian@… added

For what it's worth, I've seen several complaints about themes not working correctly because the a theme has a default background image and a user finds that they can't select a custom background color. I've never seen any complaints where a user expected the background image to stay when they selected a color.

#9 @nacin
13 years ago

  • Milestone changed from Awaiting Review to 3.2

#10 @westi
13 years ago

  • Keywords reporter-feedback added

Isn't the BACKGROUND_IMAGE constant what the theme should be using here to set the default background image?

#11 @nathanrice
13 years ago

Is that new? Also, when trying to use it, like so, in functions.php:

define( 'BACKGROUND_IMAGE', '' );

... it works on the front end, but doesn't work on the custom background upload page. When I look at the source, this is what is output:

<div id="custom-background-image" style="background-color: #000000; background-image: url(''); background-repeat: repeat; background-position: top left"><img class="custom-background-image" src="" style="visibility:hidden;" alt="" /><br /> 
<img class="custom-background-image" src="" style="visibility:hidden;" alt="" /> 

Do I need to define the constant somewhere besides directly in functions.php?

If these constants work, then I retract my former objection. The theme should define the custom background image in functions.php, instead of style.css, and the problem should go away.

#12 @greenshady
13 years ago

Setting a background image in PHP (i.e., BACKGROUND_IMAGE constant) is not ideal because many users just like to overwrite this with CSS and not fiddle with admin options. I'm not sure anything should really be changed in core though. There are pros and cons to leaving it as-is and changing it.

Here's a "fix" for theme developers that need to work around this problem.

add_custom_background( 'my_custom_background_callback' );

function my_custom_background_callback() {

	/* Get the background image. */
	$image = get_background_image();

	/* If there's an image, just call the normal WordPress callback. We won't do anything here. */
	if ( !empty( $image ) ) {

	/* Get the background color. */
	$color = get_background_color();

	/* If no background color, return. */
	if ( empty( $color ) )

	/* Use 'background' instead of 'background-color'. */
	$style = "background: #{$color};";

<style type="text/css">body { <?php echo trim( $style ); ?> }</style>


#13 @jane
13 years ago

  • Milestone changed from 3.2 to Future Release

This clearly need more discussion, so punting in light of it being a week past when we supposed to hit RC and the fact that @greenshady provided an interim workaround.

From a UX perspective, it would be best if the theme populated the Background screen so their predef bg image could be used or not based on user choice of image and color selectors shown on that screen.

#14 @iseulde
11 years ago

  • Keywords dev-feedback added

#15 @nacin
10 years ago

  • Component changed from Themes to Appearance

#16 @chriscct7
9 years ago

  • Keywords reporter-feedback removed

#17 @celloexpressions
8 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

This is something that themes generally handle themselves. It also seems to be less of an issue now that backgrounds are only managed in the customizer. Closing for now due to lack of significant activity for 5 years.

Note: See TracTickets for help on using tickets.