[wp-trac] [WordPress Trac] #30299: Inconsistent custom-background Body Class Behavior

[WordPress Trac]

#30299: Inconsistent custom-background Body Class Behavior
-------------------------------+-----------------------------
 Reporter:  philiparthurmoore  |      Owner:
     Type:  defect (bug)       |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Customize          |    Version:  trunk
 Severity:  normal             |   Keywords:
  Focuses:                     |
-------------------------------+-----------------------------
 Possibly related to #22030 and [21054] (specifically
 [https://core.trac.wordpress.org/changeset/21054#file2 this])

 Currently there’s a problem with the following code:

 {{{
         if ( get_theme_mod( 'background_color' ) || get_background_image()
 )
                 $classes[] = 'custom-background';
 }}}

 On newly installed blogs `get_theme_mod( 'background_color' )` will return
 `false`, while on blogs that have a custom background set and then
 reverted to the default background color declared by the theme
 `get_theme_mod( 'background_color' )` will return the hex string of the
 default background.

 1. Activate a new site.
 2. `var_dump( get_theme_mod( 'background_color' ) )` will give you
 `false`.
 3. Set a custom background color.
 4. Set the background back to its default color declared by the theme.
 5. `var_dump( get_theme_mod( 'background_color' ) )` will give you the
 string of the background color.

 What this means is that themes cannot safely rely on `.custom-background`
 as a helper class without inconsistent behavior. I’ve had to write my own
 function to determine when a background has really been customized:

 {{{
 <?php
 function truly_customized_background( $classes ) {
         if ( get_background_image() || ( 'fafafa' !== get_theme_mod(
 'background_color' ) ) ) {
                 $classes[] = 'customized-background';
         }

         return $classes;
 } // end function truly_customized_background
 add_filter( 'body_class', 'truly_customized_background' );
 }}}

 The default background color for this theme is `fafafa`.

 I'm not really sure what the best way of handling this would be, but I do
 know that as it stands now, the logic behind `custom-background` isn't
 reliable if it's supposed to mean "This site has a custom background or
 image set."

 My very quick and lazy look into a way to handle this on the core side
 looked like this:

 {{{
         if ( current_theme_supports( 'custom-background' ) ) {
                 $args = get_theme_support( 'custom-background' );
                 if ( get_theme_mod( 'background_color' ) === $args[0
 ]['default-color'] ) {
                         var_dump('mod is same as default');
                 }
         }
 }}}

 So would stuff break if we changed the original `custom-background` logic
 to make sure that the theme mod exists and isn't the same as the default
 color declared by the theme?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30299>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform