[wp-trac] [WordPress Trac] #20921: Customizer should check theme errors(), not just exists()

[WordPress Trac]

#20921: Customizer should check theme errors(), not just exists()
------------------------------+------------------
 Reporter:  nacin             |       Owner:
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  3.4
Component:  Themes            |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |
------------------------------+------------------
Changes (by nacin):

 * keywords:   => has-patch commit


Comment:

 [attachment:20921.diff] does a number of distinct things, so listen up:

 What it does and why:
  1. Preview filters are added/removed in start/stop_previewing_theme()
 only if we are not previewing the active theme.

  A theme can have an "error" but still be valid enough to pass
 validate_current_theme(). The single error that can cause this is
 "theme_parent_invalid". Per the comment in WP_Theme->get_page_templates(),
 "If you screw up your current theme and we invalidate your parent, most
 things still work. Let it slide." How to make this occur: Activate a child
 theme. Rename the "Template:" header in the style.css to a theme that does
 not exist. The database still holds the correct 'template'. The theme
 itself is broken, but WordPress otherwise operates normally.

  But, if we add all of the preview filters (which are unnecessary for the
 active theme), we are pulling the 'template' data from WP_Theme and
 overwriting what is in the database. This results in a problem. Simply not
 adding preview filters in this situation allows the DB to win.

  2. If we are previewing the active theme, it validates the active theme
 before continuing. If the theme is invalid, validate_current_theme() does
 the switch_theme() to the default theme, so we redirect back to
 themes.php?broken=true, which is the cause of the diff in themes.php. We
 can get away with a wp_redirect() here as this can only happen when
 customize.php is accessed directly, rather than being loaded from within a
 frame on themes.php. This is because themes.php calls
 validate_current_theme(), which will revert us back to the default theme
 before we even show a Customize link.

  There is one "bug" related to this, but it is so edge that I actually
 laughed. If you have themes.php open in one tab, then invalidate your
 theme, then open customize.php directly, you will get the inner frame
 redirecting to wp_redirect(). This, I do not care. wontfix, punt,
 whatever.

  3. $theme->errors() is also checked, but only for the non-active theme.
 Why? Because validate_current_theme() will handle "fatal" errors for the
 active theme, and the one non-fatal error, theme_parent_invalid, should be
 ignored.

  4. wp_die() becomes a protected method (in anticipating of removing the
 final keyword in 3.5), and $message becomes optional, defaulting to
 'Cheatin'. This makes the code a bit less repetitive.

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