[wp-trac] [WordPress Trac] #23347: Theme fallbacks for post format meta data

WordPress Trac noreply at wordpress.org
Tue Feb 19 06:53:50 UTC 2013


#23347: Theme fallbacks for post format meta data
-------------------------+------------------
 Reporter:  helen        |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  3.6
Component:  Template     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------

Comment (by greenshady):

 Pulling this conversation from #19570 since it belongs in this ticket.

 Replying to [comment:60 helen]:
 > Replying to [comment:59 greenshady]:
 > > Support for post formats for several versions has meant something
 different.  It simply meant that a theme supports post formats in some
 way.  Now, this meaning is being changed to say that a theme handles
 specific metadata too.
 >
 > I don't know if it's "too" so much as "instead". The UI for all formats
 shows now no matter theme support, rather than having the theme determine
 the UI (all of some radio buttons before). This is in line with our goal
 of providing something that users can rely on to be consistent. I don't
 know how we can move forward unless we make at least some kind of break
 from the previous paradigm. Hoping that theme compat can address as many
 situations as possible to build trust with users and yet not disrupt
 everything for theme authors. Again, relying on those who build themes
 regularly, especially public release ones, to really help us shape this
 piece.

 The theme compat and UI stuff are great.  That's not the big issue.  We
 need a solution for existing themes that currently expect post format data
 to be stored in `$post->post_content`.  That's where it's always been.
 So, we need solutions for:

 * Themes that don't support post formats.
 * Themes that support post formats and the new metadata.
 * Themes that support post formats and aren't using the new metadata.

 The work thus far has focused on the first two items.  We need to also
 focus on the third.

 My proposal is that we make the theme support call look something like the
 following.

 {{{
 add_theme_support( 'post-formats', array( 'aside', 'gallery' ), array(
 'compat' => false ) );
 }}}

 The `compat` argument:

 * If `true` (default), would add the theme compat layer.  Basically, it
 adds everything where it's expected (the post content).
 * If `false`, would remove the theme compat layer.  This would allow
 themes to explicitly say that they will use the new metadata and don't
 need WP to handle it.

 This will be a good solution for two reasons:

 * Users will be able to use the new post format data with existing themes
 that support post formats.
 * New themes can simply allow WP to handle how the data is output if they
 choose this route.

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


More information about the wp-trac mailing list