Remove Post Formats and make them an optional plugin like Links

[mor10]

While I appreciate all the work done on this feature and its complicated and contentious history, I suggest removing Post Formats from core and making it a plugin along the lines of the Links feature which was removed a few years back. After the termination of Post Formats UI, it appears the feature has largely been left to pasture and implementation across themes is at best spotty and inconsistent. One example of this is how different Post Formats are treated in the default themes, culminating in the minimalist/absent inclusion in Twenty Fifteen.

Some of the key arguments that come up when discussing the removal of the feature include:

• Feature is poorly explained and understood by end-users leading to low adoption and significant confusion. This seems in part related to a lack of understanding of the term "Post Formats" itself.
• Feature support is inconsistent across themes causing users to wonder why the panel and options appear and disappear when themes are switched.
• When implemented, behavior is inconsistent between themes causing a perception of arbitrary or broken behavior in the eyes of the user.
• Specification for what exactly each post format does is vague and ambiguous giving theme developers too much room to come up with arbitrary and non-standard behaviors that cause user confusion when themes are switched.
• The use case for Post Formats seems to have gone away / been supplanted for the larger goal of making modular / Snowfall-like post editing available.
• Post Formats behavior can be mimicked by theme developers through the use of Categories or other custom taxonomies.

If we put the 80/20 rule into play here I would argue Post Formats at this point falls squarely in the 20% group (or more likely much lower). I believe it would benefit WordPress and its users to move the Post Formats feature out of core and into a plugin where it can be further developed or abandoned based on user support.

[mor10]

A thing I wrote a long time ago addressing this very subject in more detail and providing some suggestions on what to do: ​http://mor10.com/post-formats-plugin-territory/

[shooper]

I absolutely agree with this Morten. When teaching WordPress to new users, it's hard enough to get them to wrap their heads around Pages vs Posts, without getting into the Post Formats concept. This is especially true when, as you mentioned, the implementation can vary from theme to theme.

Out of curiosity I checked the themes in the wordpress.org repo - less than half of them support post formats (assuming tagging is correct). This may or may not be valuable in the conversation, but thought I'd add that data point.

[adamsoucie]

I agree with Morton entirely. I've been doing WordPress development professionally for 2+ years, and I've never once used a post format or directed a client to use one. That could be ignorance on my part, but consider this: Support for post formats is not even required by the Theme Review team.

To me, it shows that Post Formats are at best an optional enhancement for users. Given that they don't appear to be that widely used, and aren't even supported by a majority of themes (based on Shawn's research), they should not be a core feature.

[mor10]

Replying to shooper:

Out of curiosity I checked the themes in the wordpress.org repo - less than half of them support post formats (assuming tagging is correct). This may or may not be valuable in the conversation, but thought I'd add that data point.

I don't think this data point is a valid indicator. My experience is that Post Formats, when supported, are supported in a very limited way and do almost nothing. For example, in Twenty Fifteen several formats are supported, but the only format that really does anything at all is Aside. The rest seem to be there solely for taxonomy and indexing purposes.

[shooper]

Replying to mor10:

Replying to shooper:

Out of curiosity I checked the themes in the wordpress.org repo - less than half of them support post formats (assuming tagging is correct). This may or may not be valuable in the conversation, but thought I'd add that data point.

I don't think this data point is a valid indicator. My experience is that Post Formats, when supported, are supported in a very limited way and do almost nothing. For example, in Twenty Fifteen several formats are supported, but the only format that really does anything at all is Aside. The rest seem to be there solely for taxonomy and indexing purposes.

That actually makes the case for removing them from core even stronger in my opinion. If the themes that do support Post Formats don't do much at all, they serve even less of a function.

[grantpalin]

I still like to use the post formats capability on my blog, but have been disappointed by the fall-off in activity around the feature. It may be a good indicator that the feature should be extracted to a plugin so that the data and behaviour will be consistent across themes, and the plugin can evolve separately from core. I've long been using ​https://github.com/crowdfavorite/wp-post-formats to present a basic UI for when I create posts. Maybe that plugin would make a good starting point...? I'll have to look at how the current core functionality is set up.

[TechDaddyK]

I'm not sure that I have an argument unique to any of the views already expressed, but I wanted to chime in and say that I too believe Post Formats should be moved to a plugin. Maybe it could even become part of Jetpack...?

[georgestephanis]

If removed from Core, I'm not sure if I'd support putting them in Jetpack. If we did, it would only be included if a theme registered support for them or something. I'm really iffy on it, and would need to be persuaded.

[colinsp]

I too agree, these post formats fall into the display area which is part of the Theme's responsibility NOT core. I don't know of anyone who actually uses them.

[sami.keijonen]

I do use them. In my site and client sites. Mostly link and video post format. I don't mind if they are pushed in to a plugin. But I'm not sure would that solve the issues @mor10 mentioned.

• Feature support would still be inconsistent across themes.

• Behavior in the front end would still be inconsistent.

[chipbennett]

I support completing the implementation of Post Formats in core, versus removing Post Formats from core. However, if Post Formats are to be removed from core, they should only be removed to a Feature Plugin, in order to direct the completion of the implementation.

The idea here shouldn't be to remove the feature from core entirely and forever, but rather to fully bake the feature. If the best way to do that is in situ, then do that. However, if the best way is via Feature Plugin, then go that route.

[mor10]

Replying to chipbennett:

The idea here shouldn't be to remove the feature from core entirely and forever, but rather to fully bake the feature. If the best way to do that is in situ, then do that. However, if the best way is via Feature Plugin, then go that route.

My thoughts exactly @chipbennett: I put in this ticket to get the conversation started about this feature. In its current iteration it is little more than a confusing frustration. If it got built out properly it could be a great extension of WordPress, but that development would require a complete overhaul of function and functionality, something that should not happen in Core but in a Feature Plugin.

[greenshady]

Many of my users use post formats and love them. It's possible that's because my themes actually make use of the feature.

I see little point in removing the feature from core. It's a theme-supported feature, which means it's only enabled if the theme supports it. We could just as easily make a plugin for future inclusion in core to improve the feature without removing the feature in the meantime.

With that said, I'd be fine with it being a plugin, but I'd hate to see the plugin fall to the wayside and not solve the problems mentioned in this ticket. The concept of post formats was awesome way back when Matt first showed us how to do asides on his blog all those years ago. It was great that it was finally getting some attention in core. It was just implemented without enough thought to UI/UX.

The Theme Review Team is also more than willing to work with core devs if there's something we need to get theme authors to start doing.

[cais]

Even though Post-Formats may not be fully "viable" as is; and, as much as I agree with the sentiments put forward by @chipbennett and @greenshady I do not agree with Post-Formats being put into a plugin ... unless, perhaps, that plugin is auto-installed/activated with the iteration of core if/when the move is made?

Given the confusion of end-users that is being suggested here, how would they feel if all of a sudden the core functionality they relied on was no longer there at all (unless they tracked down this promised plugin)?

[TomHarrigan]

Replying to chipbennett:

I support completing the implementation of Post Formats in core, versus removing Post Formats from core.

What would complete the implementation? Part of the issue with Post Formats is that most are unsure of what its supposed to be.

Another large part of the issue in all cases I've encountered is that the feature is inherently crippled in that it's not extendable. We love WP for its flexibility, but having a feature with no wiggle room inhibits its growth and success. I understand that the reasoning in the beginning was for standardization and to allow more portability between themes, but at this point it's clear that that path wasn't successful. Not every use case fits cleanly into the pre-defined formats.

[cais]

Replying to TomHarrigan:

Not every use case fits cleanly into the pre-defined formats.

An interesting point to note, as I recall a specific project where the end-user didn't care what the post-formats were for, they just loved the idea that the theme presented the post differently and asked for it to be modified to add two more (any two, didn't matter to them) provided they followed the theme's existing layout structures.

[philiparthurmoore]

I'm not sure that moving post formats functionality into a plugin would make things better. Support for post formats is entirely dependent on post formats being supported by the active theme in use, so it's up to theme authors how post formats are handled. If they aren't supported by a theme, then the current UI for post formats is hidden.

If the goal here is standardization around post format handling, determining where the feature exists won't really change anything. What would make this better for everyone is a proper UI in the back-end for them that would force theme authors to obey back-end standardization with front-end styling.

[chipbennett]

Replying to TomHarrigan:

Replying to chipbennett:

I support completing the implementation of Post Formats in core, versus removing Post Formats from core.

What would complete the implementation? Part of the issue with Post Formats is that most are unsure of what its supposed to be.

I have ideas regarding how to answer that question (primarily regarding standardizing how content is stored and the UI for user configuration), but I believe discussing them here would be out of scope for this particular ticket.

Another large part of the issue in all cases I've encountered is that the feature is inherently crippled in that it's not extendable. We love WP for its flexibility, but having a feature with no wiggle room inhibits its growth and success. I understand that the reasoning in the beginning was for standardization and to allow more portability between themes, but at this point it's clear that that path wasn't successful. Not every use case fits cleanly into the pre-defined formats.

In order for core to define/standardize the things that need to be defined/standardized in order to make Post Formats useful, it is important that the taxonomy terms be a known set; that's why the taxonomy terms aren't extensible. Again, though: debating the finer points of that decision is outside the scope of this particular ticket.

[littlefyr]

Replying to TomHarrigan:

Replying to chipbennett:

I support completing the implementation of Post Formats in core, versus removing Post Formats from core.

What would complete the implementation? Part of the issue with Post Formats is that most are unsure of what its supposed to be.

Another large part of the issue in all cases I've encountered is that the feature is inherently crippled in that it's not extendable. We love WP for its flexibility, but having a feature with no wiggle room inhibits its growth and success. I understand that the reasoning in the beginning was for standardization and to allow more portability between themes, but at this point it's clear that that path wasn't successful. Not every use case fits cleanly into the pre-defined formats.

Agreed. Probably the most compelling use case for Post Format is one where I have a serial collection (ie Posts) of things but on any given day I'll want to have a different thing and that thing is distinguished not by its style, but by its content.

By way of example, let's pretend I have enough free time to keep up a blog where I regularly review WP plugins, themes, and also JQuery plugins and NPM modules. Now many of the entries in my blog are going to be about what I had for lunch, but when I review something, I'm going to want to have links to the Git repo, the WP page, a taxon for its license (for searching) and so on.

I could make these reviews into a simple custom post type, but if I want to make a list of all my serial content, I'd have to make two queries and combine and sort them. And I'd have to do some similar jiggery pokery to have a single common set of categories.

At least that's what I recall from the last time I looked at something like this. I seem to recall thinking it wasn't going to be easy so what's the point.

If it is trivial to have a custom post type that meshes seamlessly with posts, then this ticket has already been completed, you need only to distribute each of the current post formats as a plugin of its own.

If not, that would seem to me to be the fully baked implementation. A Post Type Format (lets keep it generalized) that seamlessly integrates with its host post type (polymorphism for Post Types). Let a post type define the values it needs (classname, excerpt, title, body, featureImage), and let the Post Type Format (through filters/actions as appropriate) supply those values from its data, or fall back to the post type's default.

This puts the bulk of the responsibility for displaying the post format on the creator of the format, and strikes me as being sufficiently flexible to cover past and future uses for post types.

[chipbennett]

Replying to littlefyr:

Agreed. Probably the most compelling use case for Post Format is one where I have a serial collection (ie Posts) of things but on any given day I'll want to have a different thing and that thing is distinguished not by its style, but by its content.

The key thing to remember - and I remember the epiphany way back when Post Formats were first introduced - is that the feature is not a custom content (i.e. post) type, but rather a custom taxonomy, for a given content (i.e. post) type.

A blog post (i.e. the content type) can have different kinds of information. How that information gets entered and stored is really what needs to be fleshed out and standardized.

For a post with the Link post format, does the user enter the link as the Post Title, or the Post Content - or maybe as post meta data? Is the link entered as a raw URL, or does it have a link title for constructing a fully formed HTML link? Does a post with the Link post format also allow for descriptive content?

Does a post with the Aside post format have a Post Title?

Are videos, audios, and images configured as post attachments? Post meta?

Those are the kinds of questions that really need to be answered, in and by core, in order for Post Formats to be truly useful.

I think those things can be answered with the feature remaining in core. Others may disagree.

[helen]

I am having some serious 3.6 déjà vu here, except I know we haven't gone back in time because I am no longer pregnant and there is a toddler yelling something about Thomas the Tank Engine at me. :) Here is some more of that painful history - I could probably enumerate more specifics at some point, just perhaps not today. My biggest takeaway from having served as the feature lead was that handling existing content is hard, and we're backed into a corner because different data formats have proliferated and meta is not the same as content.

• Original tickets (a selection): #19570, #23347, #24010, #24046.
• Removal post and ticket: ​https://make.wordpress.org/core/2013/05/29/post-formats-ui-is-exiting-core-will-live-as-a-plugin/, #24452
• Make/Core updates about post formats, including the vast majority of the discussions around topics that have started to be rehashed on this ticket, such as what data needs are: ​https://make.wordpress.org/core/tag/post-formats/

I don't think we should pull post formats (as in the taxonomy) from core. I think experiments around them could be done in plugins, with the warning that storing into meta is probably not a good route and that existing content must be considered, as well as migration paths for those who currently use plugins/themes that store into meta. This may include things like auto-detection in Press This, modular content building, creation-only UI affordances, and so forth.

[courane01]

Replying to chipbennett:

I am envisions HG this the same manner. Possibly letting custiomizer handle design differences among post format options.

Replying to littlefyr:

Agreed. Probably the most compelling use case for Post Format is one where I have a serial collection (ie Posts) of things but on any given day I'll want to have a different thing and that thing is distinguished not by its style, but by its content.

The key thing to remember - and I remember the epiphany way back when Post Formats were first introduced - is that the feature is not a custom content (i.e. post) type, but rather a custom taxonomy, for a given content (i.e. post) type.

A blog post (i.e. the content type) can have different kinds of information. How that information gets entered and stored is really what needs to be fleshed out and standardized.

For a post with the Link post format, does the user enter the link as the Post Title, or the Post Content - or maybe as post meta data? Is the link entered as a raw URL, or does it have a link title for constructing a fully formed HTML link? Does a post with the Link post format also allow for descriptive content?

Does a post with the Aside post format have a Post Title?

Are videos, audios, and images configured as post attachments? Post meta?

Those are the kinds of questions that really need to be answered, in and by core, in order for Post Formats to be truly useful.

I think those things can be answered with the feature remaining in core. Others may disagree.

[mor10]

As @chipbennett and others have pointed out, there are several conversations going on here:

1. Should Post Formats be moved to a feature plugin for further development? (the main topic of this ticket)
2. What is the scope and function of Post Formats, and should it be reworked?
3. How do we standardize the implementation of Post Formats on both front and back end.

I think questions 2 and 3 are the most important ones, and they can only be addressed and fully explored if the feature is broken out into a Feature Plugin. You all remember that it was this feature that caused the new policy of Feature Plugins, but for whatever reason it never got the new treatment it spurred on. That was to its detriment.

One possible solution to all this is to leave Post Formats in core as is and then start development on a Post Formats Redux feature plugin on the side. That way backwards compatibility and existing themes won't be affected, and users can choose to add the new and improved version of the feature as its being developed. This would also leave ample room to discuss questions 2 and 3 and reevaluate the function, functionality, and use cases for Post Formats in the future.

[mor10]

Also, regardless of the outcome of this ticket, we need the documentation on what a specific post format means in terms of front-end implementation to be less ambiguous so as to avoid significant behavioral changes between themes. The current definitions in Codex are too vague to produce consistent output across themes. This is out of scope for this ticket, but worth mentioning if any new work is done on the feature.

[grantpalin]

Replying to mor10:

I think questions 2 and 3 are the most important ones, and they can only be addressed and fully explored if the feature is broken out into a Feature Plugin. You all remember that it was this feature that caused the new policy of Feature Plugins, but for whatever reason it never got the new treatment it spurred on. That was to its detriment.

Some irony in that...

One possible solution to all this is to leave Post Formats in core as is and then start development on a Post Formats Redux feature plugin on the side. That way backwards compatibility and existing themes won't be affected, and users can choose to add the new and improved version of the feature as its being developed. This would also leave ample room to discuss questions 2 and 3 and reevaluate the function, functionality, and use cases for Post Formats in the future.

Agree that this would be a better interim solution than just yanking the feature from core. Leave it as-is (for now) and work on v2 of the concept as a feature plugin, to possibly be re-integrated later.

[helen]

yurivictor moved the code into a plugin while we were at WCSF, and it looks like they tinkered some more afterward, but I don't think anybody ever really said they personally wanted to keep working on it. ​https://github.com/yurivictor/post-formats-ui

[peterwilsoncc]

+1 on revisiting the UI feature plugin and assigning a feature lead for the purpose.
-1 on removal altogether, even if implementations are subtle.

[mor10]

Replying to helen:

yurivictor moved the code into a plugin while we were at WCSF, and it looks like they tinkered some more afterward, but I don't think anybody ever really said they personally wanted to keep working on it. ​https://github.com/yurivictor/post-formats-ui

That's part of my argument: Since this is a core feature that has issues, we either have to do something to improve it or figure out a way of phasing it out. I think Post Formats could be valuable to WordPress and its users, but it would require some rethinking of the use case and more robust documentation and UI implementation. Currently it feels like the remnants of an abandoned dream more than a core feature. I'd be willing to contribute to high level thinking and reevaluation of what the formats do and how they should be implemented to meet current user needs and demands while ensuring consistent behavior. As for actual code implementation, others would do a better job than me.

[dshanske]

Speaking as someone who created a plugin that mimics the functionality of post formats with a different goal(Post Kinds), I have given this issue a lot of thought.

I am in favor of doing a Press This feature plugin revamp to address the issues with Post Formats including the UI.

Coming from the perspective of my agenda, while it isn't exactly the same situation, these notes in the below link discuss the idea of implied types based on content, which might be something that could be considered for post formats.

​http://indiewebcamp.com/posts#Inferring_post_kinds_from_properties

For example, a post becomes an aside if we don't supply an explicit title. A post with an embedded gallery is a gallery post. Etc.

The chooser requires the user to decide on the format. Sometimes that is necessary. But what if the properties of the post did that?

That may be a bit too radical a departure.

[littlefyr]

Replying to chipbennett:

Replying to littlefyr:

Agreed. Probably the most compelling use case for Post Format is one where I have a serial collection (ie Posts) of things but on any given day I'll want to have a different thing and that thing is distinguished not by its style, but by its content.

The key thing to remember - and I remember the epiphany way back when Post Formats were first introduced - is that the feature is not a custom content (i.e. post) type, but rather a custom taxonomy, for a given content (i.e. post) type.

This is a confusing distinction given that a taxonomy is already a concept in WP. If post formats are the same sort of thing as a category or tag, then it should should be the same sort of thing. And in that case, we can ask the same sorts of questions you ask below about tags and categories.

But if you mean in an abstract sense, then the collections of Post Types within a particular WP installation forms a taxonomy as well. That understanding does not impart any further information IMHO.

A blog post (i.e. the content type) can have different kinds of information. How that information gets entered and stored is really what needs to be fleshed out and standardized.

The kinds of information that something has is what defines a type. How that information is arrived at is neither here nor there. "how that information gets entered" is a UI question and the Rest API already means one can create whatever UI one might want invalidating any such fleshing and standardization.

For a post with the Link post format, does the user enter the link as the Post Title, or the Post Content - or maybe as post meta data? Is the link entered as a raw URL, or does it have a link title for constructing a fully formed HTML link? Does a post with the Link post format also allow for descriptive content?

Does a post with the Aside post format have a Post Title?

How is it that this is necessarily a Post, and not a different Type altogether? What possible reason would I have not to create a custom post type except to hack around the fact that you cannot (easily) mix the multiple post types in a list of "latest posts" (where post is 'things I wrote', not Post), for example.

I think those things can be answered with the feature remaining in core. Others may disagree.

I think the question is whether or not the thing currently known as "post format" should be an abstract concept within WP Core for which specific instances may live either within or without the Core (just as post types are an abstract concept that is defined in the WP Core that also includes two specific instances... Page and Post, and myriad custom instances exist outside the Core) OR should it be a fixed way of doing things defined only within the WP Core

There is a further issue. A Post is a specific Post Type. The definition and behaviour of Formats ought to be done within the context of defining a Post Type, and not as a special case.

[helen]

I spent months of my life poring over this as the feature lead, and interestingly nobody has ever stopped to ask me directly about post formats since. We went through use cases, documentation, real-world usage, UI implementation, all of the above. There are significant hurdles to overcome, and yes, further development would be best handled in some manner that can exist outside of a single release cycle, which is where feature plugins came in. At the end of the day, though, somebody needs to own that plugin, and frankly, I can understand why nobody would want to step up to something that attracts so much polarized commentary (not necessarily here, but elsewhere).

The feature was called "Post Formats UI" in 3.6, but that is by no means all that we tackled, or even the majority of it. We even kept some improvements that came directly from those efforts, like has_shortcode() and MediaElement.js for audio/video players. I think that history needs to be reviewed before recreating the past, because so far that is what is happening on this ticket, from pondering auto-detection (yes please do, that would be very cool, especially in Press This) to conflating post types with post formats. I linked several resources in comment 21.

As for the premise of the ticket: removing post formats outright from core - that is a wontfix right now. Discussion can and should continue even on a closed ticket, but given that many seem to be seeking clarity on what is or is not a possibility in core, I'll make it clear that this isn't.

[mor10]

Replying to helen:

I spent months of my life poring over this as the feature lead, and interestingly nobody has ever stopped to ask me directly about post formats since.

I'll make sure to ask you next time we are in the same physical location. This is a feature I have a great interest in both historically and for the future, and I would love to have a conversation with you about both where you would like to see it go and how we can move the feature forward.

I stand by my original claim that in its present state this feature creates serious confusion and frustration for users, but I am equally sure we can not only fix it but improve it to the point where behavior is consistent. It's possible that process starts with more clearly defining what the different post formats should do on the front end, and I have ideas on that front, but I'm not entirely sure where to start.

[greenshady]

@mor10 - I've built a number of scripts to help theme authors out in this regard. It's mostly various methods of standardizing some things. I'd happily kick around any ideas. This is a feature that I'm particularly passionate about and invested in.

[avcascade]

I agree that post formats needs to be improved, not removed from core. That would be a step backward. I'm glad to see this ticket closed as wontfix.

It is because of WordPress' support for post formats that I was able to migrate the tumblelog I publish from Tumblr to WordPress near the end of 2013. That was something I'd been wanting to do for years prior to that point, because Tumblr simply wasn't innovating.

It's true WordPress contains features that not everyone uses, and there's nothing wrong with that. There are ways to easily hide or remove post formats from the editor if they're not needed or wanted in a WordPress site.

By all means let's have a discussion about how to make post formats work better. In the meantime, keep post formats in core.

[dshanske]

When I started fiddling with themes, I started reading about Post Formats. There is a curious lack of material. Specifically, while I could find discussions, I couldn't find much material discussing the different formats in detail or pondering their use and styling.

It wasn't until @Helen posted some of the trac tickets from a few years ago that I realized the full extent of what had been discussed at the time, partly because the discussion had been abandoned.

The question is where to begin with a new discussion of improving post formats? For me, that would be going into a discussion of each post format individually, which I think would lead to discussing the most useful enhancements.

[matt]

@mor10 I'd love to see your thoughts on what an iteration on the UI could be less confusing for users. Outright removal is a deceptively easy but in-practice complicated solution to the problems you thoughtfully outlined.

[klosi]

I'm all with you on the removal of post formats, tho I would like to see a feature like page templates instead. I am happy to use custom Post types, but often it's just overkill. The idea of post formats was exactly like this I believe, tho the execution isn't versatile enough. Page templates seem to work out rather well for the community...

[fredhead]

As a web producer of small brochure and news sites for 10 years with WordPress, I'd offer a couple points if useful input:

-- I don't use post formats due to rigidity and complexity. Instead, I use ACF (always) and Custom Post Type UI (in some cases) with categories and page names to trigger display of fields in the Add/Edit screen. For me, coding templates for this approach is less complicated and confusing than sorting out the canned template code for post formats. It's also more flexible site to site.

-- Post formats at the template code level is one area where beginners probably struggle. With documentation and searching online, it's not hard to figure out how to adjust templates then grow into more complex coding. Post format code, however, I find difficult to sort out visually and would guess it's a barrier to entry for beginners. WordPress is successful in part because it has avoided needless code complexity for newbies.

Post formats would be useful to me but not as implemented. A parallel plugin development effort likely is the least disruptive approach. For my needs, post formats would include ACF and Custom Post Type UI capability in a simple flexible way. Complexity is added only as needed for a project.

[swinggraphics]

The implementation of post formats has always bothered me as a developer; they're page templates with an arbitrary limitation on number and nomenclature. I'd like to see post formats and page templates rolled into a single core feature that doesn't discriminate based on post type or "hierarchical" nature.

[dshanske]

@mor10 I want to try and devise a preliminary proposal. You want to collaborate on trying to synthesize the issues and come up with something?

[Keiser Media]

The issue that I see is that Post Formats feel like a half thought out idea. The attitude towards it is that it is a complete feature but at the moment, it is only half a feature. The issue, in developing themes, is what if you have a video post format but you also want to have content? You can have one or the other, not both. However, the reality is most people want a video plus content. Without a UI structure that supports this option (emphasis on option), post formats are half a working system.

[klosi]

Another thing to add about the post formats: It is REALLY cumbersome to develop a theme supporting the post formats and then have TinyMCE reflect that. A thing to think about might be how to improve the development experience so you only have to design the ux once, not twice. Tho, this is probably a much bigger issue since now also TinyMCE needs to play along better :-/

[colorful tones]

+1 for removing from core, and making Feature Plugin with assigned lead. I believe the current implementation is confusing to users, and could be improved. Certainly Post Formats UI was a nice addition.

[mor10]

Replying to matt:

@mor10 I'd love to see your thoughts on what an iteration on the UI could be less confusing for users. Outright removal is a deceptively easy but in-practice complicated solution to the problems you thoughtfully outlined.

I'm going to put my thoughts into words and graphics over the next little while. I have high hopes we can get this feature to work for the user.

Just to be clear, the reason this ticket was so ... direct ... was that I felt we needed to have this conversation out in the open. I hear it too often and it has been hanging around like a bad memory. Maybe the way things ended in 3.6 left people too frustrated to want to keep going, or maybe the project just lost steam or got outshone by other more pressing matters, I don't know. Regardless, if we all agree to keep Post Formats in core, we can move forward and get the ball rolling again.

[kjodle]

Replying to TechDaddyK:

I'm not sure that I have an argument unique to any of the views already expressed, but I wanted to chime in and say that I too believe Post Formats should be moved to a plugin. Maybe it could even become part of Jetpack...?

No. Jetpack is already bloated and lots of people choose not to use it.

[kjodle]

Replying to Keiser Media:

what if you have a video post format but you also want to have content? You can have one or the other, not both.

You can have both, if you code your theme appropriately.

[georgestephanis]

Replying to kjodle:

Replying to TechDaddyK:

I'm not sure that I have an argument unique to any of the views already expressed, but I wanted to chime in and say that I too believe Post Formats should be moved to a plugin. Maybe it could even become part of Jetpack...?

No. Jetpack is already bloated and lots of people choose not to use it.

I don't think we'd want it in Jetpack -- but the fact of the matter is that taking it out of core would be a backwards compatibility concern, so some level would likely need to remain.

[kjodle]

Categories won't work. Categories are about the subject matter. Post formats are about the content users can expect to see in that post. Here's how I handled them: ​http://techblog.kjodle.net/2015/09/19/make-wordpress-post-formats-all-they-can-be/