[wp-trac] [WordPress Trac] #20448: Update Twenty Ten and Twenty Eleven to use 3.4 features

[WordPress Trac]

#20448: Update Twenty Ten and Twenty Eleven to use 3.4 features
----------------------------+--------------------------
 Reporter:  nacin           |       Owner:  koopersmith
     Type:  task (blessed)  |      Status:  reopened
 Priority:  high            |   Milestone:  3.4
Component:  Bundled Theme   |     Version:  3.4
 Severity:  major           |  Resolution:
 Keywords:  has-patch       |
----------------------------+--------------------------

Comment (by nacin):

 The logic for custom backgrounds is correct.

  * If a custom background image is set, get_background_image() will return
 the theme mod.
  * If a custom background image is not set and there is no default value,
 get_background_image() will evaluate to false.
  * If a custom background image is set but empty, this means the image has
 been "removed", and the empty value would not be overridden by a default.
 This means get_background_image() (and $background) would evaluate to
 false.
  * In the case of a set-but-empty image ("removed"), where there is a
 default image, we print out background-image: none.
  * Thus, the custom-background body class shows up whenever there is
 either a background image, or a default image.
  * The report from Frumph suggests that all customizations were removed,
 but to remove all customizations, you need to "Reset" rather than
 "Remove."

 Custom colors do have one bug, and I think it was just a transposition
 issue:
  * If there is no custom color saved, then get_background_color() will
 return the default. However, this situation should not output `background-
 color: (default)` in the CSS, as this can override a modified stylesheet.
 (So can images, but that is less of a concern.)
  * It does not output background-color, but it *does* output the custom-
 background body class. This is incorrect.
  * Wrong: `get_background_color() || get_theme_mod( 'background_image' )`.
 Correct: `get_theme_mod( 'background_color' ) || get_background_image()`.
  * Since we subsequently also check for `get_theme_support( 'custom-
 background', 'default-image' )`, there is no functional difference between
 `get_theme_mod('background_image')` or `get_background_image()` here. But
 you can now see why it was a transposition issue — the wrong one was moved
 to be a theme_mod check.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/20448#comment:30>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software