[wp-trac] [WordPress Trac] #20313: get_theme_data can cause invalid WP_Theme object data to be persistantly cached

[WordPress Trac]

#20313: get_theme_data can cause invalid WP_Theme object data to be persistantly
cached
--------------------------+-----------------------
 Reporter:  westi         |      Owner:  nacin
     Type:  defect (bug)  |     Status:  new
 Priority:  high          |  Milestone:  3.4
Component:  Themes        |    Version:  3.4
 Severity:  major         |   Keywords:  has-patch
--------------------------+-----------------------
 The new version of {{{get_theme_data}}} in trunk is not aware of the
 concept of themes in subdirectories and makes the naive assumption that
 the style.css file it is passed to parse is for a theme in the root of a
 registered theme root rather than in a subdirectory.

 The function itself works fine and returns correct data (Tests in [UT591])
 but when a persistent caching back end is enabled the WP_Theme object
 caches data with incorrect stylesheet and template values for the theme.

 For example if we have a theme in {{{wp-content/themes/awesome/amazing-
 theme/}}} then both stylesheet and template should point to {{{awesome
 /amazing-theme}}} but if you call {{{get_theme_data}}} with the full path
 to the style.css file in {{{wp-content/themes/awesome/amazing-theme/}}}
 the WP_Theme object gets created for the theme slug {{{amazing-theme}}}
 with the theme root {{{wp-content/themes/awesome//}}}.

 Because the cache keys are based on md5sum of the path to the theme folder
 this data is then cached for the {{{awesome/amazing-theme}}} theme in the
 {{{wp-content/themes/}}} theme root.

 Attached patch fixes this for me in my testing (using error_logs inside
 {{{get_theme_data}}} to examine the WP_Theme object.)

 I tried writing unit tests to show the badly cached data but it wasn't
 easy to do :(

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/20313>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software