#19570 closed task (blessed) (fixed)
Post Formats: admin UI + fallbacks for themes that don't support them
Reported by: | 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)
Change History (202)
#3
@
13 years ago
- Cc dromsey@… added
Oh please yes.
The UI + standardization of fields is such a great combo.
#10
@
12 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?
#16
@
12 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.
#33
@
12 years ago
- Type changed from enhancement to task (blessed)
Spun off #23347 for theme output fallback
#34
@
12 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.
#35
@
12 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
@
12 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
@
12 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
@
12 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 thantype="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?
#39
@
12 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
@
12 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
#42
@
12 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.
#44
@
12 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.
#46
@
12 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.
#48
@
12 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'.
#51
@
12 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:
↓ 53
@
12 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
@
12 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:
↓ 56
@
12 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.
#55
follow-up:
↓ 57
@
12 years ago
The situation that needs to be addressed is the following:
- 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.
#56
in reply to:
↑ 54
;
follow-up:
↓ 58
@
12 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
@
12 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:
↓ 59
@
12 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:
↓ 60
@
12 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
@
12 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.
#64
follow-up:
↓ 65
@
12 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:
↓ 66
@
12 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
@
12 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:
↓ 69
@
12 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:
↓ 71
@
12 years ago
After hooking up all of the compat fallabacks, I like the idea of metadata way less
#69
in reply to:
↑ 67
@
12 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.
#70
follow-up:
↓ 72
@
12 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
@
12 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
@
12 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.
#74
@
12 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:
#75
@
12 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
@
12 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.
#79
in reply to:
↑ 78
@
12 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?
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. :)
#80
@
12 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
@
12 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.
#82
@
12 years ago
19570.7.diff is my experimental first-pass at removing the tabs, and doing something more inline.
#83
@
12 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).
#84
follow-up:
↓ 85
@
12 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:
↓ 86
@
12 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 usingwp_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:
↓ 87
@
12 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
@
12 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.
#89
@
12 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."
#92
in reply to:
↑ 91
@
12 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.
#94
@
12 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):
#97
follow-up:
↓ 100
@
12 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
@
12 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!
#99
@
12 years ago
19570.13.diff adds a description line for each format:
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
@
12 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).
#102
@
12 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.
#104
@
12 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:
#105
@
12 years ago
attachment:19570.17.diff makes my code work better with @lessbloat's
#108
@
12 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
#111
@
12 years ago
19570.24.diff: wording improvements for audio and video format labels, discussed in IRC.
#113
@
12 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.
#114
@
12 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.)
#118
@
12 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
#120
follow-up:
↓ 121
@
12 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.".
#121
in reply to:
↑ 120
@
12 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
@
12 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
@
12 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
@
12 years ago
19570.27.diff adds alt attribute for the selected image.
#126
@
12 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
@
12 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:
↓ 130
@
12 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?
#129
@
12 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
@
12 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
@
12 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:
↓ 133
@
12 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:
↓ 134
@
12 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:
↓ 135
@
12 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
@
12 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
@
12 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.
#137
@
12 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.
#138
follow-up:
↓ 139
@
12 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.
#140
in reply to:
↑ 139
@
12 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.
Didn't see that and didn't search trac first. Totally my fault (obviously). Thanks.
#143
follow-up:
↓ 144
@
12 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.
#145
follow-up:
↓ 149
@
12 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
@
12 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.
#148
@
12 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.
#149
in reply to:
↑ 145
@
12 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:
↓ 152
@
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
@
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
@
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.
#154
@
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:
- 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?
+1