Post Formats: admin UI + fallbacks for themes that don't support them

Description

Post formats would be nicer to use if the admin UI provided a little more structure and functionality around them. The plugin here creates an admin UI via JavaScript and should be considered a functional prototype.

There are several custom fields provided to put various bits of data into structured fields, allowing for custom output of those fields in a theme.

Note that the URL field is separate for Link formats so that URL will not be included in pingbacks until #18506 is accepted.

Creating structured data to support post formats makes them more powerful and allows themes to do more with them, but it also causes a potential backward compatibility problem for users that change to a theme that doesn't support post formats. To solve this problem, the following code can be used:

Creating structured data to support post formats makes them more powerful and allows themes to do more with them, but it also causes a potential backward compatibility problem for users that change to a theme that doesn't support post formats.

There's another way we could tackle this without the need of implementing a fallback. And it's by always having all the data stored on the_content, not in separate fields to begin with. We could use something like the HTML inline comments that are currently used to generate post page breaks, or the more tag, for structuring the data into retrievable pieces.

Those are examples of structuring data without fragmenting the data. (Which I think is worth considering/discussing for this.)

Example: for a Quote post we could have a <!-- the quote --> comment before the quote data, then a <!-- the quote author --> one before the author of said quote. If you were to output the_content you will get all the data in a way that makes sense when reading, without losing anything. But a theme aware of the post format structure can make use of specific template tags (that look for those comments) to output the chunks of data in the way it pleases, like the_quote() and the_quote_author().

On the UI side, when you create a post using the post formats UI you'd never interact with the_content directly, just with specific input fields for the structured data (quote, quote author). But, if you were to change the format of that post back to a "standard" post, it would transition seamlessly, still holding every bit of data you entered when it was a quote-post.

tl:dr. The input of the information could appear to the user as structured fields, but all the data could then be stored on the same place (the_content) with "marks" to structure it without fragmenting it. Themers can then rely on specific template tags to craft their designs.

19570.diff​ is a UI-free, JS-required functional rough outline, mostly uploaded here for progress tracking and any early objections. There are meta fields and tabs for selecting a format, all of which save. Tabs won't look like that exactly - was just using an existing style to keep the patch minimal.

19570.2.diff​ adds showing/hiding fields based on the selected format, still unstyled. The CSS for hiding is pretty terrible - will hopefully have a better idea for it at a decent hour. Naming is also all over the place.

19570.3.diff​ is a more refined and testable patch for functionality, with some minimal styling and the addition of wonderboymusic's get_post_format_meta() function from #23347. Use in conjunction with #23347 to test theme fallback output.

Things that should be addressed before a first-run commit:

Wiring up the media modal to the image and gallery formats and inputs. A preview of the image/gallery should appear within a placeholder area and the input should be hidden, perhaps with hide-if-js rather than type="hidden".

Be able to actually delete the meta fields.

Don't offer any new strings for translation just yet.

Further to-dos:

Screen option for show/hide of post format selector and fields.

Possible logic for intelligently not showing the selector/fields at all if a screen option is not explicitly chosen.

Tab styling that starts with a reusable base component for core. Semi-related: #17959

Icons for the tabs and smaller ones for the fields - URL, quote, quote source, embed code/URL, image, gallery (see no-JS for the last two).

I tested 19570.4.diff​. When editing an existing post with the status format, there are a bunch of undefined index notices in the other tabs. I added some defaults to get_post_format_meta() in 19570.5.diff​

Still thinking on what exactly get_post_format_meta() should do, but can go with 19570.6.diff​ for now. Was hoping to do gallery before a first run, but it's a bit complex so I'm thinking we should go ahead and get this in as-is for now and get some more alpha eyes and testing.

I still don't like the new UI. It gives the post formats too much control over the UI. So my opinion is unchanged about that this should be a plugin. I'm also curious if there are stats to show how many users do really use post formats.

I think it would be good to make it possible to remove most of the code. Like all the code added for 'post format fields' really should use the action 'edit_form_after_title'.

All themes that have post format support will have to be updated to make use of this new field, correct? Otherwise it is discarded and not used.

If a theme declares support for a format, then the_content will not be modified, so the theme should continue doing whatever it's currently doing to extract information from the_content and "do something fancy" with it (or not). Basically the meaning of "supporting" a post format has changed slightly from "show that option in the UI, and this theme will do something with it" to being "this theme will handle all output of this format, don't modify it in any way", if that makes sense.

Inserting a video in 3.5: Select video format from the meta box, paste the video URL into the post content area along with any optional text. Theme leaves it as-is (with different CSS styling) or it even uses PHP code to extract the video from the content and display it differently, such as outside the content area. Hacky, but that's the way it was done, right?

Now, inserting a video in 3.6: Select video in the new UI, paste the video URL into the new box that stores it in the post meta. Optional text goes in the old content area. Now the problem is that any theme that hasn't been updated for 3.6 will display only the optional text with the video nowhere to be seen.

Try it for yourself with Twenty Thirteen. Where's the video show up? Nowhere. :)

People are going to update to 3.6, be presented with a new UI, try to use it and have nothing happen and then blame WordPress.

user installs theme that supports new formats data and creates posts on their site with various formats - populating the new formats data

user decides to switch to a theme that doesn't support the new formats data

In this situation, the "fallbacks" functionality (proof-of-concept plugin linked in the original description above) is what would make everything work OK.

WP Core can look at the declared theme support (or lack thereof) for formats, and it can look at the data for each post. If it sees a video URL in the format meta field and the current theme doesn't declare support for the video post format, then it can be automatically pre-pended to the content.

This is the only edge case where things get tricky, but I think that a set of sane fallbacks mitigate the problem pretty efficiently.

Try it for yourself with Twenty Thirteen. Where's the video show up? Nowhere. :)

Very valid, good catch. So -- do we do something like detect that the "special data" (in this case, the URL) is *not* in the_content, and then apply the fallback filters even though the theme declares support? Or is this wandering into disaster territory?

Unless I'm not understanding something, this is dealt with already Alex. Since the UI is now displayed always (regardless of declarations of support), the same situation can effectively happen all the time, and with any formats that the current theme doesn't support (even though it might support some). The fallbacks kick in on a post-by-post, format-by-format basis.

So -- do we do something like detect that the "special data" (in this case, the URL) is *not* in the_content, and then apply the fallback filters even though the theme declares support? Or is this wandering into disaster territory?

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. 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.

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. We'll be working together (post formats and Twenty Thirteen teams) to get Twenty Thirteen working with formats and vice versa - each side putting the other through practical testing to arrive at something that actually works in use. Other themes will similarly need to update and adapt, I suppose.

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.

I don't think we allow anything like custom meta fields in the WordPress.org repository when it relates to post formats.

I think that's correct, but we can't just ignore themes in other places (shops, bespoke, whatever).

Is there something we can do to minimize this?

That's what I'm hoping more testing and eyes and brains will help figure out. :)

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.

I just realized we're discussing this on the "wrong" ticket - #23347 would be a better place, as that's where we're handling the theme compat angle.

It would be more usable, to insert the gallery shortcode directly in the Gallery Meta Field instead of copy pasting.

As the to-do list indicates, this is on the list of things to get working. Feel free to patch if you are able, otherwise it needs either somebody to commit to working on it or for me to finish up other tasks.

As the to-do list indicates, this is on the list of things to get working. Feel free to patch if you are able, otherwise it needs either somebody to commit to working on it or for me to finish up other tasks.

19570.gallery-shortcode.diff​ adds the shortcode to the gallery post format field when on the gallery post format tab (otherwise, it adds it to the editor).

Handeling galleries is ugly and the UI is laking. An user don't care about the shortcode and we don't even show it anymore in the editor. So why we now show it in the input field. Also what happens when an user just edit it to something else?

Actually, the UI is missing completely. The field is there right now to work through functionality - in reality, if this field is where we land, the input should be hidden, the way it is for the image format. Please feel free to work on the UI side. If my summaries on this ticket or on Make Core aren't enough information, I'll be happy to clarify what possible UI routes are.

I already ported the first init commit you did to a github plugin (​https://github.com/markoheijnen/post-format-ui). With my own UI flavor on it. The way I look at the current state is that the UX is there but not how it looks. But basically the UX per post status is also missing for now.

Was planning to work on the gallery part this week. I would love to see the gallery code to an hidden input and maybe showing the first image or all images in the UI.

I would love to see the gallery code to an hidden input and maybe showing the first image or all images in the UI.

I don't know how much clearer I can be that yes, that is what the wireframes have indicated and I would like to see, and that we are completely lacking when it comes to UI with what is in trunk. If you missed the wireframes, I believe the last version melchoyce put togther is here: ​http://cl.ly/0p260s3U0L3p

Just because this feature has UI in the title doesn't mean that's all there is to it. We need to figure out theme compat and data structure, or else we're going to build a UI for something that will get punted for not actually doing anything useful. At this point I'm desperately looking for help writing patches on the UI front, especially to get the bigger parts moving (gallery hookup, hiding title field, changing the layout, and some others). Not everything has be discussed in office hours, so if you want to commit to helping out with something, commenting on this ticket or Make/Core achieves the same effect. Office hours are just a helper for real-time communication and keeping things moving where tickets or P2 might stall out.

Played around some more with icon styling. @altjoen suggested making the page icon standard (instead of aside) and the post-it icon aside (instead of status), which I really like, so I tried making a new status icon (the face). I think it might work. I'm still pretty unsatisfied with the audio and quote icons.

Vertical edges of the chat bubble points are soft; make sure the shape is snapping to the pixel grid

Chat, Happy face should have a 1 pixel white inner glow like page and image icons

Quotes should be bolder; make the stroke slightly darker if you have to

Happy face needs a drop shadow. Note: drop shadows should always be 1 pixel in height; the right one on the music not is 2 pixels. Here's how I make them: make a 1px high by whatever px wide selection. Fill with black on a new layer. Deselect. Horizontal Motion blur 2 pixels or so. Set layer opacity to 10-12% or so.

Aside icons should have the text and gradient extend to within 1 px of the left and right side; now it's 2 px away on either side.

Video/movie icon arrow should be solid and slightly smaller. Corners should be crisp;they seem slightly rounded. Top corners are ok like this but bottom corners have a little bit of grey that makes it lose some crispness.

I'm having a lot of trouble getting the audio icon crisp. Anyone have any ideas?

There is always going to be problems with anti-aliasing on the round and skewed elements that will make things look fuzzy. Maybe using solid shapes instead of outlined shapes will help? I also made the "uprights" a darker grey to match the other icons, which makes them a bit stronger too. Thoughts?

EDIT: I have updated the source PSD in making this change, so let me know if you like it and I will attach the source. :)

I was testing this out on my personal site and noticed that the UI for choosing an image for an image post format is missing the filter dropdown (usually offers "images" and "Uploaded to this post"). I didn't have time to dig in and see why, but I wanted to put this here so I didn't forget. It definitely makes it harder to find the image I'm looking for (compared to the featured image flow).

Also, I don't really think this patch should be removing the .nav-tab CSS, at least, not without some replacement - it's still used on Manage/Install themes, at least.

Correct. Please do not alter any admin CSS that is not specific to post formats - I reused some existing classes just to get a first run in, so we should not be altering existing CSS like that for .nav-tab.

Cool. I've heard conflicting views on that now. Do we have this noted somewhere official?

#titlediv #title is an input and therefore should not use a pixel height, and actually, see #23189.

I knew you would bring that up! ;-) Sorry, forgot to mention that using px was the only way that I could get it to behave cross browser. If you can find a way to get it to work with em's, that would be awesome.

19570.9.diff​ is round 2 of the tab-less post format selector (based on feedback from JenMylo) Ends up looking like this:

If that pin is to become the button for the post format selector I believe it should be more emphasized that it is a button: slightly embossed, thin border, rounded corners, maybe a drop shadow. Also that arrow should communicate more obviously that clicking the button will bring up a drop-down. I don't like that there isn't a "Selct Post Format" in clear text, I think that the button's functionality should at least be emphasized as much as possible.

Remove separate meta fields for image and gallery post formats. These are proving to be more confusing and labor-intensive from both a user and dev perspective than entering into the regular content editor. We will rely on good content parsing instead. See #19570, #23347.

when a user clicks "Select Video", the Media Library opens with only Video files shown

when a user selects the Video, a video player is shown in place of the box and the "video" metdata field is populated with the attachment ID for the selected video.

when you return to the edit post page after saving, the video player will automatically be there

Here are some things to consider:

For the experience of selecting media to be "magic," the user needs to be able to select an item from Media Library easily, and hopefully never have to worry about "metadata"

It would be better to store the attachment ID in meta instead of URL, which might change in the future for any number or reasons, or may be fronted with a URL host for an environment other than production

The user needs to know the difference between using the Media Library and pasting in some embed code from the interwebs

For the audio and video post formats, we should try as hard as possible to have the user only associate 1 file - otherwise, they can put all of their code in the content, mix formats, duplicate data, and then their post is "video" or "audio" in name only

The Embed Code or URL field can be populated with quite literally anything, I feel like it should be hidden until someone clicks the "Add Embed Code" button, otherwise we can populate in the background for them when they select an item from the Media Library

At any point, the user can hit the "Add Media" button or paste a bunch of code into TinyMCE and blow all of this up - do we always want to show the "Add Media" button?

I feel like we need to have inline previews from the audio / video associated with those post formats

Anyways, thinking out loud here, but I've yet to feel any dazzle when using the new admin screen for post formats - hopefully this can help us get part of the way there. I was too scared to try to merge @lessbloat's CSS and mine, will do so tmrw. I am not married to any of my code, just wanted to throw ideas out there.

Thinking it might just be better to show the "embed or URL" option, vs. hiding it behind a link.

If the user does click "Add Media" under the audio or video format, and they attempt to paste a URL into the "Insert from URL" option, can we try to embed those? A bunch of the users we tested tried doing it this route, and failed.

When they do paste a video/audio URL, do we want to add a "fetch" button to the right? This way, they can verify that it's working within the admin UI, without having to save a draft (or publish) and preview the post.

This may still be on your list, but the gallery post format "Select an image" link takes you to the single image selection flow (which prevents you from selecting multiple images).

attachment:19570.18.diff​​ fixes display of media when the post is saved, also checks if URL in textarea is local or not - if not, runs through $wp_embed->autoembed() which will show preview of YouTubes, etc on save

There's already a post-formats-2x.png, which I repositioned to match the 16px version in HiDPI, although 2x is probably not the right name for it given that it's used in a 32px context as well. Guess we'll also need 64px versions.

The HUGE advantage to having the standard text not show at first, is that when you switch to another post format that uses the standard UI (chat, status, or aside) you can visually see that something happened because it slides down to show the text. It's not nearly as noticeable that something happened if the only change is the content of the text.

I really like the idea of pulling the post format more into the focus of the user. By playing around with the new post format selector, I may have found a small bug:

I guess that the main icon of the "new post" page should change according to the selected post format. In WordPress 3.6-alpha r23875 this is not the case, actually only half icons or even different icons are shown. It seems to me the sprite position / reference to the post format icon is not correct.

Side note( I am not sure if it is relevant), I was testing on a notebook with Retina display.

And then we update them all at once and add all on every revision and autosave? That would make the postmeta table "explode" :)

Why not one meta field that keeps all needed data? What happens when more than one format meta is set on a post? Do we need to keep all unused meta for the main post in addition to having it in the revisions?

Why not one meta field that keeps all needed data? What happens when more than one format meta is set on a post? Do we need to keep all unused meta for the main post in addition to having it in the revisions?

I think it makes sense to keep all non-empty post format meta. That way switching to a different post format and back again doesn't have the appearance of losing data (even if that data could be retrieved from a revision). They could all be put in one post meta field as a serialized array, but they you couldn't query based on them (such as "give me all quotes from xyz source" which could be easily accomplished with a postmeta query using _wp_format_quote_source that also specifies the quote term). Still, adding empty keys seems pointless.

As for what happens if more than one format meta is set...nothing. The ones that aren't used for the current format are just...not used. The format itself is determined based on a term from the post format taxonomy.

Agreed, it makes sense to keep all post formats meta on the main post when it's non-empty. However for revisions (incl. autosaves) we should probably be saving only the current post format meta when it has changed and is non-empty. Copying all existing meta to each revision doesn't make sense as we end up with a ton of identical meta values.

Thinking more about this: a post format is (should be?) something the user chooses once at the beginning of creating new post. What would be the user expectation if that post format is changed later while editing the post?

Currently any extra fields "disappear" from the UI together with any data that the user has entered there. Shouldn't we be marking the extra fields as "unused". We can keep the current data for the current editing session so the user can change his mind and revert back, but not save it or remove it on saving the post or publishing as it is irrelevant.

Also, would it make sense to "reduce" the formats UI after selecting a post format or when opening a post for editing. At the moment all the nice buttons are quite inviting to click which is good when starting a new post but doesn't make much sense when opening a post to edit. Perhaps we can hide them behind a "Change post format" button or similar. That would suggest the format is something to be decided once at starting the post.

Would it make sense to "reduce" the formats UI after selecting a post format or when opening a post for editing. At the moment all the nice buttons are quite inviting to click which is good when starting a new post but doesn't make much sense when opening a post to edit. Perhaps we can hide them behind a "Change post format" button or similar. That would suggest the format is something to be decided once at starting the post.

Yep, that sounds smart. When were you thinking this would initially happen? My guess is that on click for "Save draft", and "Publish" might work?

Would it make sense to "reduce" the formats UI after selecting a post format or when opening a post for editing. At the moment all the nice buttons are quite inviting to click which is good when starting a new post but doesn't make much sense when opening a post to edit. Perhaps we can hide them behind a "Change post format" button or similar. That would suggest the format is something to be decided once at starting the post.

Yep, that sounds smart. When were you thinking this would initially happen? My guess is that on click for "Save draft", and "Publish" might work?

Thoughts?

Note: we can't tell the difference between Standard-as-choice and Standard-as-default.

So there's the less elegant, less code approach. Just fadeout all of the non selected icons, which would shoot the remaining icon to the far left once all of the other icons are done fading out.

Or the more elegant, more code approach. Absolute position each icon with a z-index slightly lower as you go from left to right. Then on collapse, animate each icon to left:0; individually while at the same time fading them out, bringing them all smoothly to the left, with only the selected icon remaining once they are all done fading.

There are likely more options, but these are the only two I can think of at the moment. Do either sound like they'll work?

When starting a new post, we can "reduce" the UI on clicking a post format button. We know it's a new post because it has $post->post_status == 'auto-draft'. When opening a post for editing, post_status != 'auto-draft'.

We can add a class on <div class="post-format-options"> to set the initial state, then toggle that class with jQuery on selecting a post format. So when that class is present the UI will be minimal, perhaps only a "Change post format" button. Clicking that button will remove the class and show the post format buttons.

This would mean that once a post format is selected, the user will have to click twice to change it. This also suggests post formats should be set once.

We can't tell the difference between Standard-as-choice and Standard-as-default.

When starting a post all formats will be visible until the user selects one. Not selecting a format = 'standard'. When editing a post if there's no format we assume 'standard' (same as now).

Edit: don't think we need to tell the difference between Standard-as-choice and Standard-as-default. This works well as is now: new posts (post_status == 'auto-draft') have the 'standard' post format by default. If the user clicks 'standard', we hide the rest. If format is never set, all formats are visible until Save Draft or Publish. When editing a post we show the current post format, default or not.

If you have a post with a gallery in it, and navigate away to a few other tabs, and then navigate back, the galleries disappear. (Or, you will click into the post and the galleries disappear). Noticed the same issue with the “read more” bar. If you insert it into a post, and then look at a few other tabs and come back, it disappears as well. You can make it reappear by toggling between “Visual” and “Text.”

If you have a post with a gallery in it, and navigate away to a few other tabs, and then navigate back, the galleries disappear. (Or, you will click into the post and the galleries disappear). Noticed the same issue with the “read more” bar. If you insert it into a post, and then look at a few other tabs and come back, it disappears as well. You can make it reappear by toggling between “Visual” and “Text.”

This appears to be related to auto-save. I can't directly trigger the issue, but I did a screenshare with someone that could. Opening up inspector and watching the auto-save fire when TinyMCE loses focus is what caused the gallery blocks to disappear. Toggling between the visual and text editors brings them back, until you focus off the visual editor again. Really strange.

The chat post format type feels out of place as a native post format in WordPress core. Sorry I haven't followed along more closely to have brought this up earlier in the cycle, but I think there's discussion to be had over the utility of it.

The chat post format type feels out of place as a native post format in WordPress core. Sorry I haven't followed along more closely to have brought this up earlier in the cycle, but I think there's discussion to be had over the utility of it.

There was a brief discussion in ticket:23625:17. I guess removing it now is not an option.

Was there any data for the popularity of different post formats? Putting quote and aside on the end seems odd to me. Just for reference here's the popularity of the post formats we use in the WordPress.com frontend posting UI:

Standard/Aside (68%)

Image (21%)

Video (5%)

Link (4%)

Quote (2%)

As you can see there is a big drop off outside of the merged standard/aside format and image. I don't have any data, but it strikes me that the status and chat formats would be less popular than quote, maybe even the audio format too. Is there any data for this?

New tickets please - I don't really see anything actionable here. There are other tickets open / closed / committed for items related to this ticket already - #24010 for CF meta, #24046 to admin UI reboot