[wp-trac] [WordPress Trac] #24109: Twenty Thirteen: Remove unneeded post formats `add_theme_support()` declaration

[WordPress Trac]

#24109: Twenty Thirteen: Remove unneeded post formats `add_theme_support()`
declaration
------------------------------------+--------------------
 Reporter:  DrewAPicture            |       Owner:
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  3.6
Component:  Bundled Theme           |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+--------------------

Comment (by lancewillett):

 Thinking more about this as I see it in action on WordPress.com and as I
 look at how we are implementing the vision for structured post formats.

 '''1. Recommendation: change the 'post_formats_compat' filter to to be
 dependent on themes declaring {{{add_theme_support( 'structured-post-
 formats' );}}}'''

 {{{add_filter( 'the_content', 'post_formats_compat', 7 );}}}

 This now runs for all themes, even for themes that declare post formats
 the "normal" way (not the new structured way).

 Instead, we should make it conditional on specifically opting in to
 structured post formats so that older themes with existing post formats
 support will work exactly as they do now. Opt-in instead of forcing them
 to get the new markup, like Quotes getting {{{blockquote}}} added
 now—without being intended.

 Already getting reports from theme authors where the new markup is
 breaking their existing styling, for Quotes, for example.

 The opt-in action would be simply adding {{{add_theme_support(
 'structured-post-formats' );}}} without arguments.

 I think it should work without any arguments, just to turn on the new post
 content filtering.

 Then, if any arguments are passed to the "structured-post-formats" — the
 theme will be telling WordPress that it does not want the
 "post_formats_compat" function to kick in; instead it wants to build the
 output itself.

 '''2. Rename {{{post_formats_compat}}} to {{{post_formats_output}}} or
 {{{post_formats_content}}}.'''

 This function doesn't really provide compatibility, after all. What it's
 actually doing is creating default core HTML output for post formats. This
 is something we should encourage themes to use, because it's based on best
 practices and clean and semantic HTML5.

 By naming it "compat" as we do now, it seems like a fallback rather than
 the default. Something you don't want to have run ...

 If a theme wants to avoid the default HTML output for a particular post
 format, it can declare {{{add_theme_support( 'structured-post-formats'
 );}}} and pass it an array of arguments — the post format by name. Naming
 the post formats that they wish will bypass the core output, and it's up
 to the theme to parse the post meta directly or filter the post content
 itself.

 '''Open questions:'''

 1. What if a theme uses the new {{{get_post_format_*()}}} functions
 without any kind of post format {{{add_theme_support}}} declarations?
 2. What if a theme uses the new {{{get_post_format_*()}}} functions
 without just the non-structured post format {{{add_theme_support}}}
 declarations?

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