Make WordPress Core

Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#19570 closed task (blessed) (fixed)

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

Reported by: alexkingorg's profile alexkingorg Owned by:
Milestone: 3.6 Priority: normal
Severity: normal Version: 3.3
Component: Post Formats Keywords: has-patch ui-feedback needs-codex
Focuses: Cc:

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.

https://github.com/crowdfavorite/wp-post-formats

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:

https://github.com/crowdfavorite/wp-post-formats-fallback

This looks at custom field data and the current theme's post format support, and where appropriate adds content to the post body.

For now I've kept the code in GitHub instead of attaching it here, so that pull requests can be created easily.

There was a great response to this from the community when we released it, so hopefully it can be considered for inclusion in core.

Attachments (47)

19570.diff (5.9 KB) - added by helen 11 years ago.
19570.2.diff (8.8 KB) - added by helen 11 years ago.
fields
19570-w-meta-func.diff (8.5 KB) - added by wonderboymusic 11 years ago.
19570.3.diff (8.6 KB) - added by helen 11 years ago.
19570.4.diff (11.6 KB) - added by helen 11 years ago.
19570.5.diff (11.7 KB) - added by aaroncampbell 11 years ago.
19570.6.diff (11.5 KB) - added by helen 11 years ago.
19570.gallery-shortcode.diff (870 bytes) - added by lessbloat 11 years ago.
post-formats-sprite.png (4.8 KB) - added by melchoyce 11 years ago.
post-formats-sprite.psd (141.9 KB) - added by melchoyce 11 years ago.
post-formats-sprite.2.png (4.8 KB) - added by melchoyce 11 years ago.
post-formats-sprite.2.psd (145.5 KB) - added by melchoyce 11 years ago.
post-formats-sprite.3.png (4.8 KB) - added by melchoyce 11 years ago.
audio-format-alt.jpg (17.3 KB) - added by JerrySarcastic 11 years ago.
19570-icons.patch (3.2 KB) - added by rachelbaker 11 years ago.
Adding icons to Post Format UI tabs
19570.7.diff (10.7 KB) - added by lessbloat 11 years ago.
19570.8.diff (10.9 KB) - added by ryelle 11 years ago.
19570.9.diff (10.8 KB) - added by lessbloat 11 years ago.
19570.9.images.zip (105.6 KB) - added by lessbloat 11 years ago.
19570.10.diff (10.4 KB) - added by lessbloat 11 years ago.
19570.11.diff (8.6 KB) - added by lessbloat 11 years ago.
19570.12.diff (8.9 KB) - added by lessbloat 11 years ago.
admin-ui.diff (16.8 KB) - added by wonderboymusic 11 years ago.
19570.13.diff (10.0 KB) - added by lessbloat 11 years ago.
19570.14.diff (10.1 KB) - added by lessbloat 11 years ago.
19570.15.diff (19.2 KB) - added by lessbloat 11 years ago.
19570.16.diff (24.4 KB) - added by lessbloat 11 years ago.
19570.17.diff (24.4 KB) - added by wonderboymusic 11 years ago.
19570.18.diff (24.0 KB) - added by wonderboymusic 11 years ago.
19570.19.diff (26.2 KB) - added by wonderboymusic 11 years ago.
19570.20.diff (26.2 KB) - added by wonderboymusic 11 years ago.
19570.21.diff (27.3 KB) - added by wonderboymusic 11 years ago.
19570.22.diff (29.8 KB) - added by wonderboymusic 11 years ago.
19570.23.diff (29.4 KB) - added by DrewAPicture 11 years ago.
String improvements.
19570.24.diff (892 bytes) - added by sabreuse 11 years ago.
19570.25.diff (2.9 KB) - added by wonderboymusic 11 years ago.
19570.26.diff (3.3 KB) - added by wonderboymusic 11 years ago.
19570.27.diff (550 bytes) - added by SergeyBiryukov 11 years ago.
19570.28.patch (5.6 KB) - added by ocean90 11 years ago.
post-format-tip.diff (518 bytes) - added by kopepasah 11 years ago.
Patch for displaying the current post format on the post format tip.
post-formats-sprite.3.psd (170.4 KB) - added by melchoyce 11 years ago.
post-formats-sprite-32.psd (206.2 KB) - added by melchoyce 11 years ago.
post-format-meta-filter.diff (417 bytes) - added by alexkingorg 11 years ago.
Add a filter to the returned meta values
post-formats-sprite-64.png (25.0 KB) - added by melchoyce 11 years ago.
post-formats.psd (169.4 KB) - added by aaroncampbell 11 years ago.
post-formats32.psd (204.0 KB) - added by aaroncampbell 11 years ago.
post-formats64.psd (347.4 KB) - added by aaroncampbell 11 years ago.

Download all attachments as: .zip

Change History (202)

#1 @iandstewart
12 years ago

  • Cc iandstewart added

#2 @DrewAPicture
12 years ago

  • Cc xoodrew@… added

+1

#3 @goto10
12 years ago

  • Cc dromsey@… added

Oh please yes.
The UI + standardization of fields is such a great combo.

#4 @mcgaritydotme
12 years ago

  • Cc mcgaritydotme added

#5 @jkudish
12 years ago

  • Cc joachim.kudish@… added

+1

#6 @21cdb
12 years ago

Please add this!

#7 @21cdb
12 years ago

  • Cc 21cdb added

#8 @downstairsdev
12 years ago

  • Cc downstairsdev added

#9 @Mamaduka
11 years ago

  • Cc georgemamadashvili@… added

#10 @jtsternberg
11 years ago

  • Cc justin@… added

Any word on this? I think it would be a nice core asset, especially for client work (vs commercial themes). Maybe an option or theme_supports?

#11 @williamsba1
11 years ago

  • Cc brad@… added

#12 @helenyhou
11 years ago

We should talk about it post-3.5. Have had discussions about it recently.

#13 @beaulebens
11 years ago

  • Cc beau@… added

#14 @melchoyce
11 years ago

  • Cc melissachoyce@… added

#15 @mercime
11 years ago

  • Cc mercijavier@… added

#16 @matveb
11 years ago

I'm excited that things are in motion! Posting this just as initial food for thought.

Replying to alexkingorg:

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.

#17 @sennza
11 years ago

  • Cc bronson@… added

#18 @rachelbaker
11 years ago

  • Cc rachelbaker added

#19 @jaredatch
11 years ago

  • Cc jared@… added

#20 @slobodanmanic
11 years ago

  • Cc slobodanmanic added

#21 @dh-shredder
11 years ago

  • Cc dh-shredder added

#22 @helen
11 years ago

  • Milestone changed from Awaiting Review to 3.6

#23 @lessbloat
11 years ago

  • Cc lessbloat added

#24 @sabreuse
11 years ago

  • Cc sabreuse added

#25 @ocean90
11 years ago

  • Cc ocean90 added

#26 @ocean90
11 years ago

  • Keywords needs-patch added; has-patch removed

#27 @ramiy
11 years ago

  • Cc r_a_m_i@… added

#28 @apeatling
11 years ago

  • Cc apeatling@… added

#29 @rachelbaker
11 years ago

  • Cc rachelbaker removed

#30 @rachelbaker
11 years ago

  • Cc rachelbaker added

#31 @synapticism
11 years ago

  • Cc synapticism added

#32 @jeherve
11 years ago

  • Cc jeremy+wp@… added

#33 @helen
11 years ago

  • Type changed from enhancement to task (blessed)

Spun off #23347 for theme output fallback

@helen
11 years ago

#34 @helen
11 years ago

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.

@helen
11 years ago

fields

#35 @helen
11 years ago

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.

#36 @wonderboymusic
11 years ago

Refreshed, can use the meta func from #23347, also the JS was looking for data('wpFormat'), changed to data('wp-format') as per the tabs

#37 @helen
11 years ago

W3C HTML5 spec says data attributes convert dash separated to camelcase and as far as I know, jQuery respects that. It was working fine, you know. :)

#38 @helen
11 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

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).
  • Format-specific layouts for image, gallery, video, audio, and possibly status.
  • Post content label (e.g. "Transcript" for chat format).
  • Optional title for some formats - should always be able to edit, even if it's "click to edit" for the optional ones.
  • Auto-generation of post titles when it's not required. Should try to be smart with ones that may not contain any text, e.g. image (use caption or alt?).
  • Fetching of an inline preview for video/audio.
  • If we do #23282, also wiring up the media modal to video/audio.
  • Responsive layout considerations.
  • No-JS: selecting one should save a draft; query arg should select format on load (also useful beyond no-JS); image and gallery input, since there's no media modal.
  • Accessibility: tab ordering, particularly coming from the title, and any other considerations.
  • Help text.

Anything in the second list or otherwise that should absolutely be done before a first-run commit?

Last edited 11 years ago by helen (previous) (diff)

@helen
11 years ago

@helen
11 years ago

#39 @helen
11 years ago

19570.4.diff adds image selection, although without "Insert from URL" for now. Next step: gallery. And then I think we can go for a first run commit.

#40 @aaroncampbell
11 years ago

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

#41 @greenshady
11 years ago

  • Cc justin@… added

@helen
11 years ago

#42 @helen
11 years ago

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.

#43 @aaroncampbell
11 years ago

.6 looks ready for a first pass commit to me.

#44 @helen
11 years ago

In [23449]:

Edit screen UI for post formats: a first run for functionality.

  • Adds a very basic tabbed interface for selecting a post format (requires JS).
  • Extra fields, which are post meta, are shown/hidden based on the selected format.
  • Introduce a helper function for retrieving formats-specific metadata: get_post_format_meta().
  • Image selection uses the media modal, although without filtering or from URL support at the moment.

props rachelbaker, wonderboymusic, aaroncampbell, helen. see #19570.

#45 @JerrySarcastic
11 years ago

  • Cc fittingsites@… added

#46 @helen
11 years ago

All notes/to-dos from comment:38 still apply, except for strings and wiring up the modal for the image format. Also:

  • Should the image format support usage of the caption shortcode?
  • Image selection preview in the admin should probably use the medium size first, falling back to full.

#47 @helen
11 years ago

  • Keywords needs-patch added; has-patch needs-testing removed

#48 @markoheijnen
11 years ago

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

#49 @coenjacobs
11 years ago

  • Cc coenjacobs added

#51 @helen
11 years ago

Also: acknowledging that the no-JS links are totally wrong. They were meant as a placeholder/reminder to work on no-JS and I left them in the commit :(

#52 follow-up: @Viper007Bond
11 years ago

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.

#53 in reply to: ↑ 52 @beaulebens
11 years ago

Replying to Viper007Bond:

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.

#54 follow-up: @Viper007Bond
11 years ago

Let me better explain:

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.

Last edited 11 years ago by Viper007Bond (previous) (diff)

#55 follow-up: @alexkingorg
11 years ago

The situation that needs to be addressed is the following:

  1. user installs theme that supports new formats data and creates posts on their site with various formats - populating the new formats data
  2. 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.

#56 in reply to: ↑ 54 ; follow-up: @beaulebens
11 years ago

Replying to Viper007Bond:

Let me better explain...

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?

#57 in reply to: ↑ 55 @beaulebens
11 years ago

Replying to alexkingorg:

The situation that needs to be addressed is the following:

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.

#58 in reply to: ↑ 56 ; follow-up: @helen
11 years ago

Replying to beaulebens:

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.

#59 in reply to: ↑ 58 ; follow-up: @greenshady
11 years ago

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

#60 in reply to: ↑ 59 @helen
11 years ago

Replying to greenshady:

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.

#61 @kwight
11 years ago

  • Cc kwight@… added

#62 @helen
11 years ago

  • Component changed from Editor to Post Formats

#63 @lancewillett
11 years ago

  • Cc lancewillett added

#64 follow-up: @hchouhan
11 years ago

  • Cc hchouhan added

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

#65 in reply to: ↑ 64 ; follow-up: @helen
11 years ago

Replying to hchouhan:

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.

#66 in reply to: ↑ 65 @lessbloat
11 years ago

Replying to helen:

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

#67 follow-up: @markoheijnen
11 years ago

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?

#68 follow-up: @wonderboymusic
11 years ago

After hooking up all of the compat fallabacks, I like the idea of metadata way less

#69 in reply to: ↑ 67 @helen
11 years ago

Replying to markoheijnen:

Handeling galleries is ugly and the UI is laking.

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.

Last edited 11 years ago by helen (previous) (diff)

#70 follow-up: @markoheijnen
11 years ago

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.

#71 in reply to: ↑ 68 @helen
11 years ago

Replying to wonderboymusic:

After hooking up all of the compat fallabacks, I like the idea of metadata way less

All ears for what you like better. Now's the time.

#72 in reply to: ↑ 70 @helen
11 years ago

Replying to markoheijnen:

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.

#73 @melchoyce
11 years ago

Took a first shot at making 16x16 post format icons based on empireoflight's original icon style:

http://core.trac.wordpress.org/raw-attachment/ticket/19570/post-formats-sprite.png

#74 @melchoyce
11 years ago

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.

Preview:

http://core.trac.wordpress.org/raw-attachment/ticket/19570/post-formats-sprite.2.png

#75 @empireoflight
11 years ago

These look great! Couple recommendations:

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.

Nice work Mel!

#76 @melchoyce
11 years ago

Thanks for the great feedback Ben, it's super helpful! I'll work on refining these tomorrow and getting another version posted up then.

#77 @kopepasah
11 years ago

  • Cc justin@… added

#78 follow-up: @melchoyce
11 years ago

Updated the icons based on Ben's feedback:

http://core.trac.wordpress.org/raw-attachment/ticket/19570/post-formats-sprite.3.png

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

#79 in reply to: ↑ 78 @JerrySarcastic
11 years ago

Replying to melchoyce:

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?

http://core.trac.wordpress.org/raw-attachment/ticket/19570/audio-format-alt.jpg

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

Last edited 11 years ago by JerrySarcastic (previous) (diff)

#80 @melchoyce
11 years ago

It feels a little dark — one or two highlights could help — but it's definitely on the right track!

Ben, any more thoughts on the design?

#81 @empireoflight
11 years ago

Hey, sorry for being MIA on this-I think it's right on, looks good; I like the one on the right better.

@rachelbaker
11 years ago

Adding icons to Post Format UI tabs

@lessbloat
11 years ago

#82 @lessbloat
11 years ago

19570.7.diff​ is my experimental first-pass at removing the tabs, and doing something more inline.

#83 @aaroncampbell
11 years ago

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

@ryelle
11 years ago

#84 follow-up: @ryelle
11 years ago

  • Cc kelly.dwan@… added

19570.8.diff is two fixes to lessbloat's patch - dropped the z-index on the inline switcher, and added a check for post formats when adding the container HTML.

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.

#85 in reply to: ↑ 84 ; follow-up: @helen
11 years ago

Replying to aaroncampbell:

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

There's quite a bit missing for that modal - filter, current selection, and insert from URL.

Replying to ryelle:

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.

Other notes on the patch:

  • var currentPostFormat = '<?php echo esc_html( $active_post_type_slug ); ?>' - should be using wp_localize_script() for that.
  • Hex values should use shorthand where possible.
  • #titlediv #title is an input and therefore should not use a pixel height, and actually, see #23189.

#86 in reply to: ↑ 85 ; follow-up: @lessbloat
11 years ago

Replying to helen:

  • Hex values should use shorthand where possible.

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.

#87 in reply to: ↑ 86 @DrewAPicture
11 years ago

Replying to lessbloat:

Replying to helen:

  • Hex values should use shorthand where possible.

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

I could've sworn the not-yet-finalized CSS coding standards called for 6-char, lowercased hex codes. You probably got that conflicting information from me. When in doubt, check the doc.

#88 @ramiy
11 years ago

  • Cc r_a_m_i@… removed

#89 @helen
11 years ago

I wrote the standards :) "Use hex code for colors, or rgba() if opacity is needed. Avoid RGB format and uppercase, and shorten values when possible: #fff instead of #FFFFFF."

#90 @saltcod
11 years ago

  • Cc saltcod@… added

@lessbloat
11 years ago

#91 follow-up: @lessbloat
11 years ago

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

http://f.cl.ly/items/421t3Z2E241k2G1F2O0m/post-format-selector.jpg

#92 in reply to: ↑ 91 @pseudoxiah
11 years ago

Replying to lessbloat:

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.

#93 @helen
11 years ago

In 23753:

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.

#94 @lessbloat
11 years ago

19570.10.diff​ is a refresh of .9, plus an experiment into adding a button style around the post format selector (It's not there yet, still needs some love):

http://f.cl.ly/items/3C1y2d353G2M1w1v0b1Q/pf-button.jpg

Last edited 11 years ago by lessbloat (previous) (diff)

@lessbloat
11 years ago

@lessbloat
11 years ago

#95 @lessbloat
11 years ago

19570.11.diff​ offers another take on the selector:

http://f.cl.ly/items/272a2y3T1l3K2p262T0G/post-format-selector-11.jpg

Props to JoenAsmussen for the concept.

@lessbloat
11 years ago

#96 @lessbloat
11 years ago

19570.12.diff​ shows a visual title of the current post format (and updates on mouseover). It also updates the RTL CSS:

http://f.cl.ly/items/1I0V3k1z1r0o292q113P/post-format-title.jpg

#97 follow-up: @wonderboymusic
11 years ago

attachment:admin-ui.diff is not "done" but exposes code for the admin that does the following:

Moves post format-specific edit-form-advanced.php code to wp-admin/includes/post-formats.php

For audio posts, adds a "Select an Audio File" box - http://cl.ly/image/3a0l2i3x0S40

  • when a user clicks "Select Audio", the Media Library opens with only Audio files shown
  • when a user selects the Audio, an audio player is shown in place of the box and the "audio" metdata field is populated with the attachment ID for the selected audio.
  • when you return to the edit post page after saving, the audio player will automatically be there

For video posts, adds a "Select a Video File" box - http://cl.ly/image/2w2E22080l3J

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

#98 @lessbloat
11 years ago

@wonderboymusic - Don't worry about it. I've got some pending stuff I'm still working on. I'll merge my patch into yours once I'm done. Thanks!

@lessbloat
11 years ago

#99 @lessbloat
11 years ago

19570.13.diff adds a description line for each format:

http://f.cl.ly/items/3D072o460u0C282H1K3b/post-format-description.jpg

Without this description, after selecting a post format the users is left wondering, "Okay... What next".

I also reorganized the order in which the formats appear, giving weight to the more popular ones. For now, they are hard-coded.

As for the descriptions, I'd like to keep these short. Help with the copy here would be much appreciated:

  • Standard - Add a title and description for your post below.
  • Image - Select an image using the Add Media button below.
  • Gallery - Use the Add Media button below to select images for your gallery.
  • Link - Add a link URL below.
  • Video - Paste a video embed URL below, or click Add Media to upload a video.
  • Audio - Paste an audio embed URL below, or click Add Media to upload an audio file.
  • Chat - Paste a chat transcript below.
  • Status - What are you up to? Enter your status message below.
  • Quote - Enter a quote below.
  • Aside - Enter a quick thought or side topic below.

#100 in reply to: ↑ 97 @lessbloat
11 years ago

Replying to wonderboymusic:

A couple of thoughts:

  • Excellent start on the video & audio media selections.
  • 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).

#101 @wonderboymusic
11 years ago

the descriptions are the right idea

@lessbloat
11 years ago

#102 @lessbloat
11 years ago

19570.14.diff​ hides the default "standard" post format description on load (minimizing vertical space), then slides down the description once a post format is selected.

@lessbloat
11 years ago

#103 @lessbloat
11 years ago

19570.15.diff​ merges 19570.14.diff​ with admin-ui.diff.

#104 @lessbloat
11 years ago

19570.16.diff​ is an attempt to get something committable today (there is still plenty to improve, but this is a good start):

  • Yanked gallery format UI, can use "Add Media" flow until it is commit worthy.
  • Modified image, video and audio post format descriptions
  • Removed link to show embed text box. Made it into a text area, and displayed it beside the media library selector:

http://f.cl.ly/items/1e190E1q1c2H1G3K2R3h/show-embed.jpg

Last edited 11 years ago by lessbloat (previous) (diff)

@lessbloat
11 years ago

#105 @wonderboymusic
11 years ago

attachment:19570.17.diff makes my code work better with @lessbloat's

#106 @wonderboymusic
11 years ago

  • Keywords has-patch ui-feedback added; needs-patch removed

#107 @lessbloat
11 years ago

I kicked the tires with 19570.17.diff​. Looks good to me.

#108 @wonderboymusic
11 years ago

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

#109 @DrewAPicture
11 years ago

  • Keywords needs-codex added

@DrewAPicture
11 years ago

String improvements.

#110 @markjaquith
11 years ago

In 23843:

Post Format UI.

  • Icons
  • Selection
  • Prompt text
  • Special fields
  • Styling
  • Sparkles

This is going to need testing, polish, and love.

see #19570. props melchoyce, helen, wonderboymusic, lessbloat, rachelbaker, aaroncampbell, DrewAPicture, ryelle.

@sabreuse
11 years ago

#111 @sabreuse
11 years ago

19570.24.diff: wording improvements for audio and video format labels, discussed in IRC.

#112 @markjaquith
11 years ago

In 23845:

Post Format prompt copy tweaks. props sabreuse. see #19570

#113 @helen
11 years ago

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.

Last edited 11 years ago by helen (previous) (diff)

#114 @lancewillett
11 years ago

.26 looks good, and Image post format now works as expected.

Note for later, revisit the 'image' case in post_formats_compat() to see if we can further improve or simplify the output. (Not a blocker for beta, though.)

#115 @markjaquith
11 years ago

In 23847:

Add compat code for 'image' post format.

see #19570. props wonderboymusic.

#116 @markjaquith
11 years ago

In 23853:

Use jQuery.on() properly. Add some slideUp()/slideDown() transitions to ease post format switches. see #19570

#117 @markjaquith
11 years ago

In 23854:

Do not attempt a slide transition if the current and switched-to post
formats both have no UI. Do not slide if clicking on the current format.

see #19570

#118 @kovshenin
11 years ago

In wp-admin/includes/post.php the gallery format is listed twice in $format_keys: http://core.trac.wordpress.org/changeset/23843/trunk/wp-admin/includes/post.php

#119 @SergeyBiryukov
11 years ago

In 23861:

Remove duplicate array keys. props kovshenin. see #19570.

#120 follow-up: @markoheijnen
11 years ago

When you add anew post you don't have text for standard post but when you click on a post format and go back you will see "Add a title and use the editor to compose your post.".

Last edited 11 years ago by markoheijnen (previous) (diff)

#121 in reply to: ↑ 120 @DrewAPicture
11 years ago

Replying to markoheijnen:

When you add anew post you don't have text for standard post but when you click on a post format and go back you will see "Add a title and use the editor to compose your post.".

We talked about this briefly in IRC last night, though I agree with you that this is inconsistent. @markjaquith seems to think you should have to click the Standard icon to show the text.

Definitely worth discussing.

#122 @aaroncampbell
11 years ago

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.

#123 @markoheijnen
11 years ago

Why not just removing the text for standard post. Mainly since it's not a post format. I would describe it as no post format so the text seems unnecessary to me.

#124 @SergeyBiryukov
11 years ago

19570.27.diff adds alt attribute for the selected image.

#125 @alex-ye
11 years ago

  • Cc nashwan.doaqan@… added

#126 @nickbohle
11 years ago

  • Version changed from 3.3 to trunk

Hi all,

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.

#127 @sabreuse
11 years ago

  • Version changed from trunk to 3.3

The "version" field should be used for the version where an issue was first raised -- in this case, 3.3

#128 follow-up: @azaozz
11 years ago

I may be missing something but a post can only have one post format, right? Why do we have all the different formats related post meta:

'_wp_format_url',
'_wp_format_quote',
'_wp_format_quote_source',
'_wp_format_image',
'_wp_format_gallery',
'_wp_format_audio',
'_wp_format_video',

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?

Last edited 11 years ago by azaozz (previous) (diff)

#129 @wonderboymusic
11 years ago

I would describe that as "awful" - I doubt it was intended, I think we need to switch on format and only add format meta that is relevant

#130 in reply to: ↑ 128 @aaroncampbell
11 years ago

Replying to azaozz:

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.

#131 @azaozz
11 years ago

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.

#132 follow-up: @azaozz
11 years ago

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.

#133 in reply to: ↑ 132 ; follow-up: @lessbloat
11 years ago

Replying to azaozz:

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?

#134 in reply to: ↑ 133 ; follow-up: @markjaquith
11 years ago

Replying to lessbloat:

Replying to azaozz:

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.

How would you imagine the UI collapsing?

#135 in reply to: ↑ 134 @lessbloat
11 years ago

Replying to markjaquith:

How would you imagine the UI collapsing?

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?

#136 @azaozz
11 years ago

When were you thinking this would initially happen?

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.

Last edited 11 years ago by azaozz (previous) (diff)

@ocean90
11 years ago

#137 @ocean90
11 years ago

Somebody asked, why it's not possible to use an embed code for images. Not sure if there was a discussion yet, but think of instagram or flickr.

19570.28.patch is a first pass. I'm not sure about wp_format_image_id, but I think it makes it easier to get attachment details. It doesn't include the front-end part yet.

@kopepasah
11 years ago

Patch for displaying the current post format on the post format tip.

#138 follow-up: @kopepasah
11 years ago

Upon load of the post editor, the current format is not displayed on the post format tip.

The above attachment contains the patch necessary to display the current format on the post format tip.

#139 in reply to: ↑ 138 ; follow-up: @SergeyBiryukov
11 years ago

Replying to kopepasah:

Upon load of the post editor, the current format is not displayed on the post format tip.

See #23911 and #23503.

#140 in reply to: ↑ 139 @kopepasah
11 years ago

Replying to SergeyBiryukov:

Replying to kopepasah:

Upon load of the post editor, the current format is not displayed on the post format tip.

See #23911 and #23503.

Didn't see that and didn't search trac first. Totally my fault (obviously). Thanks.

#141 @melchoyce
11 years ago

Adding the updated post format icon sprite psds.

#142 @azaozz
11 years ago

In 23928:

Revisions:

  • Store the post format as meta on revisions (including autosaves).
  • Add post formats data (post meta) when autosaving.
  • Only add non-empty post formats data to revisions.
  • Correct the post format when previewing a published post.

Props kovshenin, see #19570, see #20564.

#143 follow-up: @ryan
11 years ago

  • Go to post-new.php
  • Select Image Post format
  • Pick an image from the Media Library
  • Leave the title blank
  • Click Preview
  • Resulting window says "Preview not available. Please save as a draft first."

Saving as a draft does not fix preview. If you publish the post it will 404. Adding a title avoids these problems. Previewing and publishing a standard post without a title works just fine.

Also, previewing a post without a title triggers Chrome's pop up blocker. Previewing a post with a title does not.

#144 in reply to: ↑ 143 @SergeyBiryukov
11 years ago

Replying to ryan:

Saving as a draft does not fix preview. If you publish the post it will 404. Adding a title avoids these problems.

Related: #23887

#145 follow-up: @ryan
11 years ago

A report that came my way:

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

#146 @lessbloat
11 years ago

I ran 2 more users through our post formats scenarios (testing the UI we currently have in trunk). They are both worth watching/reviewing.

#147 @SergeyBiryukov
11 years ago

In 23940:

Add alt attribute for selected image. see #19570.

#148 @alexkingorg
11 years ago

Can we please add a filter to the data returned by get_post_format_meta()? I'm trying to find some path to backward compatibility for everyone that was using the original code/data submitted here.

Patch attached.

@alexkingorg
11 years ago

Add a filter to the returned meta values

#149 in reply to: ↑ 145 @johnjamesjacoby
11 years ago

Replying to ryan:

A report that came my way:

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.

#150 follow-up: @ericlewis
11 years ago

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.

#151 @melchoyce
11 years ago

First shot at a 64px version of the icons. Would love some feedback! I don't think these are quite there yet.

#152 in reply to: ↑ 150 @SergeyBiryukov
11 years ago

Replying to ericlewis:

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.

Last edited 11 years ago by SergeyBiryukov (previous) (diff)

#153 @SergeyBiryukov
11 years ago

In 23993:

Remove unused variables introduced in [23843]. see #19570.

#154 @apeatling
11 years ago

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:

  1. Standard/Aside (68%)
  2. Image (21%)
  3. Video (5%)
  4. Link (4%)
  5. 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?

Last edited 11 years ago by apeatling (previous) (diff)

#155 @wonderboymusic
11 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.