[wp-trac] [WordPress Trac] #19570: Post Formats: admin UI + fallbacks for themes that don't support them

[WordPress Trac]

#19570: Post Formats: admin UI + fallbacks for themes that don't support them
----------------------------+------------------
 Reporter:  alexkingorg     |       Owner:
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  3.6
Component:  Editor          |     Version:  3.3
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |
----------------------------+------------------

Comment (by greenshady):

 Replying to [comment:58 helen]:
 > Disaster territory. :) Actually, I'm not sure in practice - a theme that
 has previously declared support for a format could currently be doing any
 number of things with it, like using their own meta fields, etc.

 I don't think we allow anything like custom meta fields in the
 WordPress.org repository when it relates to post formats.  Someone else
 from the team might have to jump in on this to say for sure, but it's my
 understanding that themes should only be dealing with what WordPress
 allows out of the box.

 > No matter what we do, something somewhere is going to be broken, whether
 it's missing vs. duplicated display of content. So far this path seems to
 be the best balance between user expectations and theme control, but I
 think with actual testing it'll become more clear.

 Is there something we can do to minimize this?  This particular change
 will break post formats on 1,000s of my users sites, at least until I can
 get all my themes updated.  I'll update my themes, of course, but I'd be
 worried about the theme authors who might not update their themes for
 whatever reason.

 > As stated, theme support for a post format now functions as a flag that
 says that the theme handles the metadata, so core should leave it alone.

 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.  So, for many existing themes, the themes will now
 be declaring support for something that they were not designed to support.

 Maybe add an additional argument in `add_theme_support()` to declare that
 a theme supports the new metadata.  Otherwise, attach the data to
 `post_content`.  It's an idea to explore anyway.

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