Post Formats UI Update, 2/21

First run commit, mostly for soaking of functionality, went into trunk on Monday. This includes fallback output for theme compat and fields in the admin. The admin UI does not represent anything final – especially of note is the tabs, which are essentially the way they are in order to reuse CSS and avoid adding temporary code to core.

Our next steps for the actual building of the UI are:

  • Hook up the media modal to the gallery field.
  • Doing some preview magic for audio/video, also possibly hooking up the media modal.
  • Adding icons for each selector (currently tabs) and some of the inputs.
  • Experimenting with interactions for the selector itself – it still seems that a selector that collapses on itself once a format has been chosen, rather than tabs that always show everything, will be better.
  • Hiding the title and/or the content for some of the post types. @melchoyce’s wireframes show which formats should have the title hidden by default; note that we should always allow the title to be edited, even if hidden under a toggle. The same goes for the content – can be hidden for some of the post types where the content serves more as a description or commentary on the other data provided for the format (image, gallery, audio, video, and quote come to mind).

Related to hiding the title, we need to add a way for titles to be smartly auto-generated/populated for those formats where a title isn’t prominently “required”. Some of the ones that also don’t need content may be served well with some smart detection if possible, e.g. the title of a video or image.

After discussion about old and new themes and content, we’ve chosen to go a little more aggressive with compat output. We had previously attempted using the current add_theme_support( ‘post-formats’ ) implementation to determine whether or not compat output should appear, but it quickly became apparent that it would create less-than-ideal situations with themes that supported post formats in the original style but have not updated. We’ve now introduced add_theme_support( ‘structured-post-formats’ ) for themes to indicate that they handle the metadata for a given format(s) and that core need not add fallback output. See the commit message on r23467 for more details.

The next step for fallback output is to accommodate new-style themes (that is, themes that specifically handle metadata) with old-style content. The Codex has recommendations for content entry/handling that will help us figure out what might have previously been done for post format support. @wonderboymusic has started work on functions to parse out relevant format data from the content itself: #23570 (URL), #23572 (audio/video), and #22960 (getting images from a gallery shortcode, especially the first). We’ll need more for other formats, but this is a start. While that is going on, we’ve been discussing what the theme output layer would look like and how de-duplication would work. “Cutting” the parsed-out data from the content itself before display is, again, a bit aggressive, but seems likely to be the best way forward (noting that it would be on display only, not actually altering the user’s content). See post-dev chat IRC logs for more details: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-02-20&sort=asc#m560171

Finally, note that we’ve created a Post Formats component in Trac. There will sometimes be some overlap between components, but especially for the 3.6 cycle, let’s put anything that relates to getting this feature working in that component so we have it handy.