Bring post formats to block themes

[draganescu]

What problem does this address?

WordPress supports post formats since version 3.1 (year 2011). In block themes one can use functions.php to add support for post formats, but then that's about it.

What is your proposed solution?

• Add a new type of template which is aimed at displaying a post of a specific format - basically, add built in support for formats in the site editor
• Introduce fomat specific archives (all asides, all videos) - this has to be specific for block themes as the archive itself does not exist in WP by default.

Formats are a powerful feature. They do have overalpping purposes with custom post types and custom templates, but as a user experience they sometimes make a lot more sense, for example if you want a simple log (not blog, nor magazine, not shop) website.

[Mamaduka]

Related #45866. cc @courtneyr-dev

[jasontucker]

This need to happen

[carolinan]

I think it is a matter of adding post formats to the template hierarchy.

[boogah]

I am dying to get this feature into Gutenberg — and eventually WordPress core. Happy to do whatever I can to help!

[draganescu]

Having had separate discussions with folks from the @WordPress/gutenberg-design here is what I learned:

• post formats are overlapping with many current features such as CPTs and CPT templates, block patterns and block templates, block templates which work only in specific template types
• post formats were originally aimed at rendering certain posts differently in the loop less so for rendering a different template, although that was possible
• one item that seems missing in the site editor is not so much post formats as conditional rendering which is available in classic themes
• a post with one block, say a quote, and no title is effectively a post format. So is appears what we should focus on is improving:
  • handling of title less posts in the loop and in templates
  • the new post flow where one should be able to start with a pattern
  • the specific formatting of the post content bloc in the query loop

[SaxonF]

@boogah could you tell us a little bit about when you last needed post formats? As @draganescu mentioned we are thinking through whether there are more flexible, alternative ways to solve some of the problems post formats did.

[boogah]

My biggest use case for post formats has been one that hasn't really come up yet. At least not in this conversation. 😉

Link posts.

Video, audio, quotes, asides, and status posts (as well as the others I didn't bother listing off) would all benefit from improved handling of titleless posts, I agree. As would a post flow where a user can pick the pattern for the post they're trying to craft.

Link logging is something that I enjoy doing. On the days that I don't feel like writing a full post, I usually have a link in my back pocket that I'd like to be able to share. It'd be great to have a way to natively do that in WordPress as it is today instead of falling back to a classic theme or hack something to make link posts work.

[Ipstenu]

Video posts, for me, has been the biggest one. Sure I could make a CPT but if I want a video post to show up in the normal post tags and categories, archives etc, and NOT have to worry about training editors, it’s post formats all the way.

Last used last week.

[janboddez]

Got the same—I think?—issue with CPTs, despite Site Editor support for them.

In search results or when they share tags with regular posts, it’s not uncommon to see the different types listed on one and the same page. Yes, in the loop!

(At the moment I use a super convoluted “hack,” i.e., several strategically placed instances of a dynamically rendered custom block, to display post meta for that exact post type, where I want it for that specific post type. Or format, if you like.)

As for titleless posts, I do a lot of those (using those same CPTs, but they could as well be post formats). The way I deal with them, and “outgoing link titles,” in the case of link posts/bookmarks/“likes,” is I override the Post Title block’s render callback!

(To merely hide a certain format’s titles, one could probably fall back to CSS-based solutions.)

Anyway, it’d be nice (or at least somewhat easier) if there could be several instances of the Post Template—not entirely sure that’s what it’s called—“block” (for one and the same query), one for each format (well, or post type) you would like to support.

[carstingaxion]

In addition to the mentioned use cases, I‘d like to add post-kinds like the #fediverse uses them and all kinds of indieweb POSSE apps.

I have found this many times a nice use-case for the built-in post_formats as they are almost 100% fitting the open-web recommendations.

[jordesign]

One thing i've appreciated in themes that use Post Formats well is within the index page (so equivalently the Query Block) where they have different treatments within the index for different formats (ie. including the video, or a blockquote in the loop instead of title/excerpt).

Like Baskerville (for example).

[mtias]

Also for reference, there's a bunch of things we already do when handling post formats that don't seem captured here. For example, when the theme supports formats and you only have a single block type in the post content:

Both in post publish and the settings panel:

Also if you go to Settings > Writing and select a default post format:

Then the editor will render that block by default when you create a “new post” instead of an empty paragraph:

---

I think the areas to explore are:

• the ability to create posts with a default block already inserted before you get to the editor — so quick posting for images, links, asides.
• title-less seems orthogonal and something you should be able to do regardless of content type.
• giving customization options for posts that have a single or primary block type present.
• instead of soft-suggesting a format it can be switched automatically.

[MaggieCabrera]

@mtias should post formats be enabled by default on block themes? If the answer is no, should we move that option to theme.json, instead of needing the PHP function?

[draganescu]

Yea same question as @MaggieCabrera what's holding us back from enabling formats in block themes by default?

[mtias]

Mostly the fact that by default they don't do anything, so it'd be pretty confusing to select something that doesn't have a meaningful impact on anything in your site.

[janboddez]

(Just a side note: I was under the impression that "asides" were the original "titleless posts.")

The "Baskerville" example up there is exactly what I'd love to be able to do when I said target different types of posts in a single query loop.

In a PHP theme, you'd just drop an if statement checking for a certain post format, for instance, or use partials (or whatever they were called) cleverly, and then you could generate entirely different HTML for each format (or type). Super handy for things like adding microformats, too, so it goes beyond just styling.

I guess "better" default blocks are a step in the right direction, but they only get shown (on index or archive pages) when the full post content is displayed. Sometimes you want title and excerpt, or no title, or apply a different class to these (theme) blocks, or show different theme blocks (like, maybe you want an author avatar for asides but not for standard posts) based on the post format. Or lay post meta out in columns. And so on. Such a thing (for block themes) currently requires very "hacky" solutions.

[draganescu]

I made an exploratory plugin which aims to see how defaulting to always on formats impacts content creation flow and the assumptions of the block themes loop.

I think it's pretty impressive how well it works with such little effort. Please test it out just to form some ideas :) - it's not meant for production.

This simple plugin is meant to explore via hacking how post formats can work with block themes from two perspectives:

1. How the creation flow for the quick no title content types could work
2. How the loop could handle quick no title content types

The plugin when activated does the following, if a block theme is active:

• Enables support for post formats (all)
• Adds one admin sidebar new post link to a special editor configured for each format
• Adds a dashboatd widget which contains a new post link to a special editor configured for each format
• Hooks into the rendering of the post template block and renders full content if the currently rendered post is any format other than standard
• Customizes the post editor for format posting by presenting a default template per format type and hiding the title input (via CSS).
• Uses format name as title in WP admin for title-less posts

Demo

https://github.com/draganescu/wp-format-enabler/assets/107534/02d6bda7-cf46-44da-94ff-a0c60e8f776f

[bph]

Thank you, @draganescu The plugin is sooo helpful to visualize what could be happening with post formats. I took if for a spin and here are my first impressions:

While using it on a test site. I created a separate category 'updates' for quotes, status, image and it was great to see how a post template works without the title in an Archive template. The only think, as a content creator I found odd, was the read more link hard-coded in the php render part on the front end. I replaced it with --> short of deleting it from the plugin

It worked almost immediately with the Blue Note theme

I would still need to link to the single post for users who would want to comment on such a post, so I probably would prefer the 'Read more link' feature from the Post template block and call it "Comment here". I'd also add a bubble for the number of comments to the archive page.

single post

I didn't do any single post template modification, so the Admin Title also showed on the Single post, but that would be the next step.

Should there be a single template and conditional rendering as you provided with your plugin or single template for each format?

• single-quote
• single-image
• single-status etc.

For end user control, I am leaning towards a single template for each post format.

Post formats in post list

I like the Admin title identifying the post format for title-less post. There are other options on how to change this:

• add a column for post format to the list of posts
• use the first few characters of the title less post to identify it in the post list.

  creator entrance.

  How the creation flow for the quick no title content types could work

I am a total fan of the single link for each post format. It's not pretty in the Admin right now, but highly functional.

I do like a Tumblr's row of icons.

• It could be made more WordPress-y and be a drop-down from the 'New post' link in the Admin bar - provided that doesn't trigger major accessibility flags.
• It would also be cool to have some a Dashboard widget right on top after login, so a user can get their work done without having to find the new post link etc.

it's pretty impressive how well it works with such little effort.

Totally agree! Awesome work.

[jameskoster]

title-less seems orthogonal and something you should be able to do regardless of content type.

Title-less posts essentially works already. When no title is supplied nothing is rendered on the frontend.

One awkward consequence is that you end up with a bunch of "Untitled" posts on the backend which isn't ideal for searching/managing. So one question is whether it should be possible to supply a title but stipulate that it isn't displayed on the frontend.

giving customization options for posts that have a single or primary block type present. Partially synced patterns are a potential solution here, and for the quick-post UI too. A self-contained flow might look like:

1. "Quick post image"
2. Upload the image
3. Select a design from available partially synced patterns containing only an Image block
4. Add categories/tags
5. Publish

instead of soft-suggesting a format it can be switched automatically. Agreed, this seems like something that can be implemented now.

On the technical side, one issue to address is how the Excerpt block handles images and other embeds. Currently, if the Query Loop includes an Excerpt (rather than Post Content), and a post contains only an image, then the Query will not output that image. Did you have any ideas how to handle this @draganescu ?

[draganescu]

@jameskoster #53465 is an exploration on making the excerpt block outputt the 1st block if there is no title.

In my plugin exploration however I look at the format itself and output the content if the format is not standard, thus circumventing the issue with excerpts in query loop.

Quick post image"

I think the idea to discard formats for flows is promising but we'll always want to do things different for these one off content types and missing a flag to denote them being "different" is gonna cause limitations.

I agree that there should be a way to post title-less content even for standard formats. I think the work of @ockham with block hooks could be a path to "turning off" title.

[jameskoster]

The flag would not be missing, just not so prominent in the UI. Post formats would be assigned automatically based on the blocks in the post, like Matias suggested above. The benefit to this is that the user is no longer burdened with choosing the appropriate format – posts fluidly move between formats automatically so that you don't end up with an Image post that contains an Video.

[draganescu]

Hm, that would require us to define the template that makes a post each format:

• one video, video format
• one image, image format
• one quote, quote format
• one gallery, gallery format
• one link (we could detect), link format
• one audio, audio format

This leaves status, chat and aside as hard to figure out. I think - we can deprecate, not support in block themes, chat, makes little sense anyway in core.

Status and aside seem to kinda be the same (considering that even the original inventor of "status" X.com turned them in asides via larger char limit). So how could we figure out asides? Asides are generally titleless text only posts? 🤷🏻

Post formats would be assigned automatically based on the blocks in the post,

This is already happening if the theme supports formats. What I want is to land in the block editor and have the format blocks for that format already there.

so that you don't end up with an Image post that contains an Video.

This shouldn't happen already.

I wonder how formats could be also extended. In a future where wordpress becomes more social (see https://indieweb.org/WordPress and https://wordpress.org/plugins/indieweb-post-kinds/) we still need formats that are composed of preset "templates" so it's easy for decentralized consumers to know what's being posted.

[jameskoster]

So how could we figure out asides? Asides are generally titleless text only posts? 🤷🏻

I think there's a reasonable argument to be made that things like aside / status are just title-less posts. But if we did want to perpetuate them it would be relatively simple to do if we utilised the partially synced pattern approach – patterns categorised as 'status' would appear as design options in the "Add aside" flow.

This is already happening if the theme supports formats.

It is? I only see a soft suggestion to change the format. This one:

What I want is to land in the block editor and have the format blocks for that format already there.

I suppose this could be a good v1. A dedicated quick-post UI could come later (or not at all!).

[jasmussen]

I would caution against inceasing the surface area of the post format selector, or even locking you in to one, because one of the primary benefits of the block editor is that you can actually mix and match post formats if you so please. IMO a great user experience would be that you never had to pick the actual post format — but that the visual appearance met your expectations in terms of asides, titleless, etc.

To that end, I'd just caution against moving too fast on this one, we do risk resurfacing some of the issues that led to the block editor initially.

[aristath]

I'm confused... If I remember correctly, for the past few years there have been lots of discussions to completely deprecate post-formats, and the argument was that now that we have blocks, the "post-type" can be derived from the content itself (so if a post has just an image it should be treated as an image post-format and so on). Is that no longer the case? Do we need post-formats? Or should we derive them from the content? 🤔

[draganescu]

Everybody agrees we should derrive them from the content - but this derrivation needs to result in some definition for each format, which is basically post formats a taxonomy on top of a post - this is an "image format" because it has an image, instead of selecting from a dropdown. So what we improve is the UX but the underlying system, if we conclude multiple post kinds are needed (given the overlap with CPTs) we still need to keep the taxonomy.

[aristath]

Thank you for the response @draganescu! Admitedly this is a long thread 😅 I was under the impression that we'd just use a filter instead of actually setting the terms, in order to be able to dynamically determine the post-format per-post without requiring the user to set it... So something like this:

add_filter( 'get_the_terms', function ( $terms, $post_id, $taxonomy ) {
    if ( 'post_format' !== $taxonomy ) {
        return $terms;
    }
    $content = get_post( $post_id )->post_content;
    // TODO: Derive the post format from the content.

    return $terms;
}, 10, 3 );

[annezazu]

It seems we have too much to figure out design wise ahead of 6.4 so I'm going to move this larger piece out of the 6.4 board. Let's keep https://github.com/WordPress/gutenberg/issues/28564 in for now in case that more scaled back piece can get in.

[draganescu]

I think https://github.com/WordPress/gutenberg/issues/28564 should be moved out of 6.4 as well.

[draganescu]

I thought about how to resolve two things in one go:

• the formats that core supports are a limited, not extendable set, and some of them are quite weird (e.g. chat)
• for the user, formats are an underlying implementation, what they see is the flow of posting quick preset content without a title

In the wp-formats-enabler plugin I also demo a dashboard widget that shows one button for every core format. Click one of them and land on a new post preset for that format with the right block added. Then, the query loop is altered so that when it meets a format other than standard it renders the content instead of the query loop post template.

I think we can apply that in a way in which:

• we do away with core formats
• we enable an UX that is based on blocks

Introducing: “New from pattern”

This feature enables users to pick any pattern from the pattern library and create a post from that pattern. The post would contain the pattern right from the start - no blank page.

The "new from pattern" flow enables users to create their own custom formats and also solves a lot of UX challenges regarding flows. The posts that are created via this flow can be flagged via some term e.g. quick-post, or we can reuse the core formats implementation and create the format on the fly from the name of the pattern.

The query block would be updated in its UI to exclude or include quick posts. When it includes them, it defaults to rendering the post content. Quick posts from patterns would have no title. If people want a title they can always add a pattern with a heading in it.

One cool thing about this direction is that a WP client could request a list of patterns and then just offer the content of the patterns. To put in in other words, a WP client will not have to implement a block editor to be able to create quick posts, any WP client could do it. A photo app just sends the photo and the name of the pattern and the post is made. A text editor sends the text and the name of the aside pattern and it posts an aside. The photo and the aside can contain other blocks such as spacers, groups, columns, but the client does not need them or care about them.

In terms of the WP UX we can start with a basic flow from the pattern library. Then this can evolve and be lifted up higher up in the UI depending on future ideas.

What do you think?

Thanks @richtabor for the inspiration from demoing your “feed” theme to me.

[scruffian]

This is already a feature pretty similar to this in core. If you create a pattern and put this in the meta data for it:

Block Types: core/post-content

This will suggest the pattern when you create a new page. Here is an example with the Stacks Theme:

[MaggieCabrera]

This is already a feature pretty similar to this in core. If you create a pattern and put this in the meta data for it:

Block Types: core/post-content

This will suggest the pattern when you create a new page. Here is an example with the Stacks Theme:

I think having both flows is good! I create a new post: I get a suggestion from the patterns my theme has. I check the patterns my theme has: oh, I want to make a post that looks like this, click here and I can make one.

[draganescu]

The new from pattern would complete this stub flow. But we also need to mark certain posts so we can display full content in the loop.

[draganescu]

Assuming the new from pattern is a good idea, we'd need to:

• add a pattern flag to say "this pattern is good for quick posting"
• automagically make the pattern a reusable (partially synced) block
• figure out if we can lean into the current core feature of "formats" and maybe create formats on the fly from the pattern used, or drop that altogether in block themes and create some new quick-post taxonomy.
  • Either way posts created from patterns with the intent to make feed-like content should be marked so that we can handle them in the loop.

[hansschuijff]

Not sure if I can add something useful to the already expanded discussion here, and apologies if I have missed something that is already possible. For what it's worth I just wanted to share some thoughts and a longing for a solution.

My interest in this issue is mainly be the ability of the query loop to somehow control how different types of postings are uniquely displayed. For that post formats could be useful, or some other marker that can be set to connect some pattern or template. But also post_types should be able to differentiate in the loop so they are recognizable for what they are. Just having one format or template for all posts might be limiting its usefulness.

For individual pages and posts, blocks and patterns already offer lots of ways to format the content. For me that doesn't seem to need something like post formats anymore. But building some kind of archive using a query loop, perhaps still could have a role for a marker like post format, although that implementation could also be replaced by some other marker.

In general it would be great if Gutenberg offers an easy way to setup a grid that adapts on an individual post level to markers like the post_type and/or something like post format to determine how each type of post is displayed.

F.i. a search result on our websites could display a mix of courses, lessons, events and woocommerce products next to pages and blog posts. Just showing all of them like they are a blog post would not be clear to the user and doesn't make much sense to me. An event should show an event start-date and price and perhaps a ticket link, while a product needs a price, availability and buy button and a blog post may need an excerpt and a read more link.

Post formats had the promise of helping that too, by offering further differentiating within a post_type based on the intended post content, although my experience is that most theme's haven't done much with it in practice. But it makes sense to be able to show a post that contains only a video by showing an image first and when it is clicked opening and starting the video, and so on.

In legacy templates we can just make template parts and code conditions in a loop and use get_template_parts(), or something comparable, to get the structure in which the different posts are displayed based on the conditions. But to implement that I need to step out of FSE and have to code again building a less flexible solution to add more flexible outcomes.

So I wonder, how should that kind of flexibility work in Gutenberg? If it's already there, I haven yet found it, but I do need it for the kind of integrated websites we maintain.

A solution would need some sort of pattern or templating mechanism that connects the type of post (however defined and marked) to how it is displayed in a list. Post format was such a marker for blog posts, but it could and perhaps should be a wider mechanism. Such functionality would be extremely useful for me (and probably many others).

So perhaps each type of post needs two templates. One for the full post and one to instruct how a post is displayed in an archive/query loop. To me that would make sense. Just the ability of having an archive part template that can be connected to a post_type or even an individual post, would make something like post format perhaps completely redundant.

After that it is just a question of how different types of posts are marked for that templating system. Post formats are in that sense just a way to further define types within types, in the end just markers and reusable structures however called.

And having the ability for plugins or themes to just setup default templates for different kind of posts to be used in query loop, would open up a lot of possibilities for offering customized solutions and default patterns.

I hope this issue and discussion will add to such a possibility, since it is something I would need even if Gutenberg doesn't offer it.

Thanks for the good work in advancing Gutenberg and this topic.

[jameskoster]

I still see partially synced patterns (https://github.com/WordPress/gutenberg/issues/53705) as foundational to the solution here. Posts that contain a single partially synced pattern are assigned a 'format' automatically behind the scenes. Updating the design for all posts in that 'format' is then just a case of updating the partially synced pattern.

There remains a question about semantic formats. IE if there are two partially synced patterns for displaying quotes (you might have one for long quotes and one for short), should those be connected somehow for the purpose of archives etc?

What's still missing in terms of design is:

1. A way to specify that the title of a given post should not appear in templates. Currently you can leave the title empty and that works, but there should still be a way to set a title to avoid a sea of "Untitled post"s in management views.
2. A quick-post flow.

The "New from pattern" flow proposed above is interesting and could be a secondary option, but I don't know that I'd be drawn to the pattern section when looking to quick-post a quote. The modal could work.

[draganescu]

@jameskoster the other missing thing is figuring out how to show quick posts in the query block's loop in a way in which it's clear for the user when they're setting up the query block that these title less one pattern blocks will display their content.

[jameskoster]

Do you mean: how should Post Title behave in Query Loops, accounting for the fact visibility can be toggled on a per-post basis?

[draganescu]

@jameskoster no, I mean that the idea of "formats" is to be a sort of "single function content" the type of content you find in social media feeds. This content is not meant to be read after a click, but read while scrolling the feed.

Quotes, asides, one image or one video posts, they should appear in the query loop with their content alongside the longer traditional posts which have titles, excerpts and lots of content, multi media etc.

The UX to solve is how to make the building of a query via the query block in a way which is friendly with this kind of content appearing next to titles/excerpts. The implementation to solve is how to make the query block output content when posts are quick posts (or formats, or single function whatever we want to call them: titleless short contet).

[jameskoster]

They still use the same template (Post Template block) though. The only consideration is that some posts will hide the title. What am I missing?

[SaxonF]

WordPress supports post formats since version 3.1 (year 2011). In block themes one can use functions.php to add support for post formats, but then that's about it.

I think its worth taking a step back here by listing out exactly what jobs post formats help to solve. There is a risk we lean too heavily into existing concepts when there might be a better solution out there. Would we come up with the same solution if post formats were never a thing?

Off the top of my head:

• The need to share short form content that can be consumed quickly and doesn't require further reading
• Creating of that content in a low friction way
• Optimising how that content is displayed in the feed (e.g. emphasising images)
• Certain users may only care about certain types of content (e.g. images, links etc)

Related jobs

• The need to keep site visitors informed of any type of activity or content. e.g. a new product, new piece of work, new event.
• When a user searches my site, I want to show them anything that might be relevant in the most optimised way, so that I don't miss out on engagement. (@hansschuijff use case below)

F.i. a search result on our websites could display a mix of courses, lessons, events and woocommerce products next to pages and blog posts. Just showing all of them like they are a blog post would not be clear to the user and doesn't make much sense to me. An event should show an event start-date and price and perhaps a ticket link, while a product needs a price, availability and buy button and a blog post may need an excerpt and a read more link.

Personally this is a direction I would like to at least explore further as it opens up possibilities extending beyond short form content. Leaning more heavily in to post types resolves most/all of the needs listed above. I know its a little difficult to mentally wrap your head around using post types in this way but that might just be because of our existing ideas of how post types should be used by people vs how they can use them.

I don't think any approach we've explored so far is perfect and perhaps there will never be a perfect solution for core. Blocks give us the flexibility we need , but we just don't have a way of 1/ low friction way of creating content 2/ switching up how its displayed depending on conditions. I'd honestly be fine with this being plugin territory. I'd love to see more opinionated ways of creating content built on top of the Gutenberg data model.

[hansschuijff]

@SaxonF Yes, thank you.

Of course it could be plugin or theme territory to add such functionality, although it seems that extending such functionality in Gutenberg often seems to mean having to copy or rebuild an entire block instead of adding to an existing one. And why not rather build something that is flexible and can be extended upon then that has to be replaced? I would think that's the WordPress way.

The whole idea of post_types is that they are not the same, so why would we think their content should be presented the same, even if only in an archive or list? It seems that we're searching for a way to vary the template that is used to display posts of certain types in the query loop and in thinking about that it could be resolved if templates could be conditionally used on the results of it.

Having al that alternative templates in the document would not be to pretty, depending on how many templates are needed, although it would solve the problem, but I could imagine a way to pre-program a conditional template structure somewhere that can be used in a query loop as well. Right now it seems you need hybrid themes for that, but perhaps it doesn't have to.

Perhaps something like a pattern (or a black box) could be part of a solution that hides any complexity of having perhaps 5 or six different templates and can just be selected in the document. But it would imply the ability of using multiple templates in a query loop and conditioning them on post_types and or different formats (however defined).

Giving themes and plugins the ability of pre-programming that layouts, using patterns and blocks, or something else, would then add to usability for the content editors, since it could mean they could just choose the basic presentation (grid, list, etc) they want in a doc and the setup and details could be handled by the plugin or theme.

It would make sense for an event plugin or shop plugin to provide one or more default archive templates for their post_types and it would make sense for themes to build on that or even to add their own templates to cater to their own way of presenting the specific content. When themes are not build for the plugins post_type then the plugin might still offer a base template for use in the query loop.

Being able to connect one or more archive display templates (or patterns, or some other layout pre-programming) to a post_type would then make it easier for a layout to be build, since then the query loop could use a default template based on the post_type and revert back to the general default template when there is none.

But just having several templates that can be used wrapped in a condition block in a query_loop would build the base functionality too.

However implemented, it only needs some mechanism in which either plugins, themes, and the editor could use conditional templates in a query loop block. Having more templates in the query loop block and giving them at least the ability to select post_types as a condition, would allow such functionality.

And having the ability to just connect a (default) query loop template to post_types would make it easier to build such a grid without concern or care for the post_type in the document itself. Perhaps the query loop then could just make me choose to either use the post_type templates or not.

The condition could be a separate parent block, or part of the template itself in some way, but such functionality would be nice for all kinds of reasons. For me the post_format discussion is just a question of conditionality added to the query_loop block template. That conditionality can be hardcoded base on post criteria, but that would only solve one specific cases, instead of offering a structure that themes and plugins can build upon.

In the end, having conditionality in query loop and the ability of using multiple templates, would mean post formats would not be needed anymore as a concept. The question then becomes how to implement such a thing and how to manage the complexity in a way that leaves the block editors content relatively clean.

[draganescu]

@SaxonF the main feature that formats and themes with support for formats offered to users is an attempt at the experience of single function content websites - such as big name social networks - where the act of sharing was nearly instantaneous and the act of consuming removed all hoops.

Sure for WordPress - missing the actual network and and the client being, mostly, "just the browser" there was never a replacement for that experience, however for those who did not need the sort of interaction on the ever growing graph, there are parts of that experience which should at the very least be offered by a software that democratizes publishing - and which you've named prefectly:

• The need to share short form content that can be consumed quickly and doesn't require further reading
• Creating of that content in a low friction way
• Optimising how that content is displayed in the feed (e.g. emphasising images)
• Certain users may only care about certain types of content (e.g. images, links etc)

By leaving this sort of experience to plugin territory we're sabotaging the most popular publishing software considering that quick low friction experience is the standard, almost not a deviation, to the walled gardens we want to democratize, where 5 billion people use the Internet to, well, publish.

By trying to convert or adapt CPT to this task we may find ourselves in another multi year project where all the major platforms continue to close even harder and "the web" continues to drift more into yesterday tech.

So, from a product perspective, this part:

I'd honestly be fine with this being plugin territory.

is the one where I strongly disagree.

I do not want to work with the implementation of core's post formats neither because I can't wrap my head around CPTs, nor because I am stuck in old concepts, but because post formats have the needs above baked in, while CPTs have other needs baked in. Sure, we could land on a solution that solves everything - but low complexity in the current environment is of essence in my opinion.

If working with CPTs solves this in any way - let's go :) I am more than happy to dive into a CPT based implementation in core if that would solve:

• a way to publish frictionless
• a better mobile publishing experience
• a way to display a mix of standard posts and titleless quick posts (of any format)
• a way to create a loop in a theme that resembles a feed with various kinds of content

[nickbohle]

I think it is a matter of adding post formats to the template hierarchy.

I have not tested it, but would a template type-quote.html work? The url works. I mean mysite.com/type/quote works on my site, running twenty twenty-four. (Even before I added support for post formats to #TT4). It shows all posts with the post format quote, and the (archive) title displays the German translation for quotes -> Zitate.

[nickbohle]

Mostly the fact that by default they don't do anything, so it'd be pretty confusing to select something that doesn't have a meaningful impact on anything in your site.

On the other hand, I just installed Twenty Twenty-Four yesterday after using Elmastudios Uku theme for some years. I was shocked, when the post format dropdown was missing on the new/edit post page. First, I thought that 6.4 skipped support for post formats (that is how I found this thread), but then, I remembered that themes have to register them. Added some lines of code and a post can be labelled with a certain post format again.

[draganescu]

@nickbohle yes, this is the issue here: formats do work but in a block theme environment they're not implemented through and through - you can't style their archives, you can't mix them in them query block loops, you can'd style their single template. Also it is a matter of missing UX in terms of how do users discover them - if I have to make a "post" to publish a quote it's still cumbersome and hard to figure out.

[annezazu]

With no efforts taken for 6.5, I'm going to remove this from the board due to the short timeframe we have before beta 1 of the release.

[lee-costa]

@draganescu I really like your plugin and would love to use this simply for the image format. Any plans for a production release?

[colorful-tones]

Hi folks, We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.

[nickbohle]

• Introduce fomat specific archives (all asides, all videos) - this has to be specific for block themes as the archive itself does not exist in WP by default.

A quick addition, IMO, format specific archives already exist, but not for „standard“ posts. The post format base in the permalink structure is /type/. So, type/image/ or type/quote/ link to the specific post format archives (using the standard archive template).

It is worth to mention, that in Twenty Twenty-Four the archive title is the translated name of the post format. Category or tag archives have the title „term: Name“ in TT4.