Screen option for post formats UI

[johnbillion]

As discussed in IRC, there should be a screen option for the post format UI on the post editing screen.

Nacin would like the UI to be hidden by default when the current theme does not support post formats and there are no non-standard format posts in the database. In this case, the UI would have to be enabled by the user. The UI would need to be automatically enabled when a theme that supports post formats is activated.

Willing patchers, make yourself known.

See also #23929

IRC logs:

​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-02-18&sort=asc#m558297

​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-04-03&sort=asc#m588002

[nacin]

To check if there is a format in use, it's pretty easy: if ( get_terms( 'post_format', array( 'number' => 1 ) ) ). Note that 'number' is a LIMIT. get_terms() also has a default hide_empty = true, to hide terms without any posts (based on the cached count). So if one term gets returned, we know at least one post has a format.

We can also check if formats have ever been used, even for a second, even if no posts currently use them. Just set hide_empty = false.

MarkJaquith seems to also be on the same page re: when to hide the UI by default, per IRC.

[travisnorthcutt]

Nacin would like the UI to be hidden by default when the current theme does not support post formats and there are no non-standard format posts in the database.

+1

[williamsba1]

I completely agree. Having the Post Format buttons show by default is going to lead to a lot of confusion. It should be hidden by default if the theme does not support Post Formats. A simple Screen Option to hide/show would solve that problem.

+1

[husobj]

+1 for this.

@nacin Also, just to clarify, are you therefore saying that if the current theme does NOT support post formats BUT there ARE posts that have been assigned post format (maybe when using a previous theme), then in this case the UI would still show?

I'm not sure it makes sense to show it at all if the current theme doesn't support it?
Or maybe you could just show it on posts that had previously been assigned a format - maybe that's more confusing?

[nacin]

Replying to husobj:

+1 for this.

@nacin Also, just to clarify, are you therefore saying that if the current theme does NOT support post formats BUT there ARE posts that have been assigned post format (maybe when using a previous theme), then in this case the UI would still show?

Yes.

Because of the new post formats compatibility code added in 3.6, even when a theme does not support a particular format (or any format), structured data will be compiled into HTML to be injected into the content. That's huge, because it means anyone can use post formats.

[cais]

I agree with the potential confusion this UI can/will create especially with the number of changes "under the page" that are related to the UI.

Is the best approach an all or nothing for the interface; or, simply show which Post-Formats, if any, the theme author has decided to support directly or indirectly as the case may be.

[aaroncampbell]

I'd prefer "shown by default with screen option to hide" for several reasons:

1. It's a great new feature that I think people should be exposed to.
2. If a theme doesn't support a certain format...that's OK. We put a lot of work into fall backs that handle this.
3. Having users start to create content using these formats will both spur on theme developers to better support it
4. Having users start to create content using these formats will help assure that as theme developers DO start support this, the user's content is prepped for it. The fallbacks for this situation, while they do exist, are not as simple at the other way around and will likely miss several edge cases.
5. Seeing something new in your post edit screen immediately following a WordPress upgrade seems like it would be less jarring than seeing the same thing after a theme update (when your theme starts supporting these).

[jbobich]

Without something like this implemented, does adding theme support for post-formats currently really do anything, other than just registering globally that the theme supports them? -- Meaning does registering that your theme supports post formats have any kind of tangible effect on the site?

This is something I've found kind of confusing with post_formats_compat() and Post Formats UI all being enabled by default.

[nathanrice]

Ideally, from a theme developer's perspective, it's not great that this be a user opt-in feature. If the theme isn't prepared to handle the data then this feature shouldn't be available (Menus and featured images, anyone?)

I understand there's a clever fallback system in place to make sure that, even if the theme doesn't know about the new fields, they get output through the_content, and that's all find and good, but it still doesn't address the numerous outlier cases where this could be tremendously confusing.

What happens if a theme supports certain post formats and styles them appropriately, but not others? Do all the post formats suddenly get activated? Won't the user be somewhat confused that they have a new post format available, but apparently it gets styled just like a blog post?

Seems the 3 big scenarios we have to prepare for are:

• No post format support in the theme at all
• Support for the old post formats
• Support for the new structured post formats

(and some cases where a theme had post format support without the structured stuff, and has now enabled structured stuff, etc.)

But I don't see how that justifies moving this from a theme activated feature to a user option. Again, menus are awesome, but we don't force them on people just because they're awesome.

If a theme doesn't support a certain format...that's OK. We put a lot of work into fall backs that handle this.

No doubt, the fallbacks keep it from completely breaking. But there's an expected behavior here ... if a post format is supported, the theme does something special with it. That's what people expect to happen, and when it doesn't, you won't be the one answering those support requests demanding an explanation. Theme authors will.

Seeing something new in your post edit screen immediately following a WordPress upgrade seems like it would be less jarring than seeing the same thing after a theme update (when your theme starts supporting these).

I don't think so at all. Post formats are theme enabled currently. People expect the theme to control what formats are and are not supported.

But that's irrelevant, because people don't update their themes, typically. Even in cases where they do (as with Genesis), it's the child themes that actually come with the CSS to style post format data (which really don't ever get updated by the user).

[saracannon]

@nathanrice - A theme might not support a format or three (stylistically altering the post format on the front end) but at the same time, because no data will get dropped - the user will have a nice place to put their content into meta boxes that is a much better experience then fumbling through the add-media modal that is geared towards inserting images into specific locations in posts. Therefore, I think it is good to have all the formats on even though the theme doesn't change the look of all the formats in the front end. Which do we think would be a more prevalent response in that scenario: "hey why doesn't my video post look different, or have a different icon / color" or "hey look that post has a video because I entered info in the meta boxes which is way easier than like it was before" I think formats are a great start to a content-tailored user experience when posting, and the front end / themes will follow suit visually because of all the icredibel thing that they can do to tailor this meta! (I'm so excited about this) - but even if themes do not have certain formats styled differently: there is great benefit in the improved ease of use in the admin.

[saracannon]

General thoughts on this ticket: I agree with this ticket, but I question using screen options to do accomplish the goals here. I have always viewed screen options as more of a "power user" setting. No typical clients that I have had ever known that the pull down exists or what it is for. It kind of is one of those "hidden secrets" of WordPress. I would argue that this should be more of a settings-level type switch due to its impact on the workflow of composing a post - rather than a casual "lets hide this in this hiden pull down" Maybe screen options is more prevalent of a tool than I think, but I know I have heard developers sigh when they finally realize that they can enable css classes on the menus screen - but I could be wrong.

[helen]

Given that post formats can technically be turned on for any post type, I'm not sure a separate setting (assuming with UI) is a great idea, as a setting would have to be created for each post type. Also, a screen option is a user preference, which is really what this should address - whether or not the given user wants this mechanism each time they start a new post. Also, the screen option actually already exists, although at the moment it just toggles the metabox with the radio buttons.

There's already a filter for turning the UI off on a code level site-wide, which is what I think of as the setting, just without a UI for the setting itself: #23929.

[nacin]

23930.diff​ is a rough cut. It creates a "Post Formats" screen option that is stored in usermeta, in a way that is per post type, per site, and per user.

A few things that should be done:

• Consider storing all post types in a single meta key. It is likely this will only occur for 'post' anyway, but no reason to have multiple keys otherwise.
• Create some unit tests for update_user_option(). I can't think of a reason why this would break back compat - rather, it would make it possible to deal with three states (true, false, and not stored).
• The logic for "should the UI be shown" should be abstracted into show_post_format_ui(), which returns a boolean through a filter.
• There should be a way to disable the screen option and force post formats to be on, probably with a filter in screen.php.

[markjaquith]

In 24092:

Screen option for Post Format UI.

props nacin. see #23930.

[kovshenin]

23930.3.diff​ removes a leftover debug call to error_log introduced in [24092].

[SergeyBiryukov]

In 24231:

Remove debug cruft. props kovshenin. see #23930.

[ocean90]

See comment:15

[SergeyBiryukov]

[24388] / #24452