Open draganescu opened 1 year ago
I am considering these as an MVP in a default theme, and what could be iterated upon in future themes @mtias.
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.
Would you think an option to solve the quick posting could leverage the pattern modal? Would the implementation be to present the pattern modal when a user creates a post OR to make Tumblr-like buttonsakin to @Alexkingorg's vision here
- title-less seems orthogonal and something you should be able to do regardless of content type.
Are you indicating the ability to display the heading on the front of site, or the lift needed to omit titles in conjunction with storing posts to the database?
- giving customization options for posts that have a single or primary block type present.
My initial vison was to have the relevant format > block be first, with paragraph and headings permitted after.
- instead of soft-suggesting a format it can be switched automatically.
Yes, if the first block is _ then the format is __. This could help the POSSE efforts as well. cc:
I am also thinking about how Twenty Thirteen has unique template per format as well that shows in the full blog loop, as well as on single posts. Connecting the first block to save the format with the template selected would be helpful, so long as users could override the automated selection upon save.
Could this get off the ground for Twenty Twenty Five?
cc: @pfefferle
Traditionally, post formats are chosen after you have already created a new post. What I mean is that you select "Add new post", and then select the format. How would selecting it before you create it work? What should happen if I want to change the format while I am editing?
What if I have created a new standard post already and added content, and then switch to the image post format, does WP automatically insert an empty image block?
There are many questions that needs answering and exploring.
@courtneyr-dev's push for in-built POSSE features is a huge marketing win for the advancing of WordPress (for both hobby users as well as orgs, brands, and agencies), not to mention it finally brings parity to various efforts kicked off within the past year to integrate with the Fediverse.
@carolinan does it have to be an either/or binary? Seems like giving people the ability to choose up front and switch formats after the fact makes the most sense. I get there could be some complications in terms of migrating content appropriately in the "post facto" scenario, but content authors are undoubtedly going to encounter situations where they want to switch formats, and we already more or less had that ability before. How was it addressed back then?
Other points to consider:
UPDATE:
Seems like the pattern transform capabilities rolling out in 6.6 can handle post format switches.
Apologies if this isn't relevant to the discourse and for the unsolicited tagging of people in — but as a matter of efficiency and to avoid retreading perfectly good wheels, I believe there is merit in referencing prior art along these lines:
I have read all the comments and there seems to be three suggestions, not mutually exclusive:
Just sharing some quick thoughts while fresh on my mind.
I think it's helpful to break down just exactly what post formats are:
Primarily, they are an identifier, a way for users to say, "e.g., my post is an aside." This information is then conveyed to the theme, and the theme decides how it should be displayed on the front end (e.g., whether it should show the title, a change of colors, etc.).
The fundamental problem that was introduced with block themes is the lack of conditionally displaying different designs based on the assigned format. There are two primary areas where themes need control:
Block theming has introduced a new hurdle that was not present in classic themes: Query Loop patterns. In most classic themes, you had one Query Loop design. It was easy to call get_template_part('content', get_post_format() ? : 'standard')
and load a "content" template part for all queries.
Today, block themes can potentially ship dozens of Query Loop patterns, each with unique layouts and potentially each with the need for handling post formats so that they fit within that context.
There are also entire libraries/scripts that themers built for pulling things like featured media (e.g., audio, video) within Query Loops. WordPress does not have blocks for those situations or Block Bindings support for the Audio and Video blocks.
When displaying formatted posts inside of the Query Loop in the past, here is how I treated them (list broken down by similarities):
<blockquote>
tag, I'd display it. Otherwise, I'd wrap the entire output in a <blockquote>
. I'd also remove the title.Hello! I found this discussion while searching for relevant discussions related to "post formats." I help run a civics blog in Chapel Hill and Carrboro, North Carolina called Triangle Blog Blog. We are a group of volunteers who basically provides news and commentary about our region. We are very interested in "kottke.org-ifying" our stream, that is, we would like to switch to a theme that allows us to easily post:
I used to run the NPR Fresh Air tumblr, and we envision something like that. Most of the volunteers I work with are not tech savvy. It would be wonderful if they could hit a Tumblr-like button from within Wordpress and have their "post type" automatically appear.
This is a long way of saying we'd be happy to kick the tires on this concept, and think it would be extremely useful for our use case, which is basically to provide ongoing news about our region to our community, in a variety of formats that are not always using the "regular post" view.
@justintadlock Thanks for sharing your thoughts. Today, I've commented on #PostFormats in #WordPress' new default theme here.
I agree with the initial purpose of post formats, but with the Ephemera widget in Twenty-Fourteen, you could already display post format posts in your sidebar. So, already back then, post formats could be used as a third (design-baed) taxonomy (besides the content driven categories and tags). This was furthermore supported with the slug /type/ for post formats.
What I would suggest is to concentrate on the low hanging fruits first. So:
Concentrate on the design restrictions (e.g. what content should be stripped not allowed?) of post formats in a second phase. This way, it could be analyzed how post formats are used in a Gutenberg world. Based on the obtained data, decisions could be made more easily.
So to allow the archive and single templates, I come back to the comment posted last year:
I think it is a matter of adding post formats to the template hierarchy.
And I think they need to be added for all theme types not only block themes.
And I think they need to be added for all theme types not only block themes.
I agree, even though Twenty-Thirteen already had content-PostFormat.php templates. Link to core.
This may be a difference in all our communication styles, but following up on what @melodykramer was articulating, I believe it's critical to state the Query block (or a similar variation) should serve as a catch-all or firehose for post formats. This would allow each format to render appropriately and enable site owners to include or exclude any combination of formats in the firehose feed.
From my perspective, it’s not enough to just envision “what it does”—it’s also about understanding the why. My use cases align with Melody’s, where the core handles post formatting, so my writers don’t have to worry about it. A plugin like ActivityPub or something similar would then handle multiplexing to federated networks. From my decade-plus experience in various verticals and agencies, what would delight many people is the ability to post an image on their site and have it automatically appear on Instagram, or a text post on Mastodon or Bluesky, without leaving their site. The actual connection and broadcasting out to external networks part of the process should definitely fall under plugin territory.
Creating a WordPress framework/API to make this multiplexing dream a reality is what I suspect this resurgence of post formats is about for many of us, as much as just having a low-stakes "social" feed of our own. It would significantly help publications and businesses save valuable time and make the process enjoyable and effortless for hobbyists. That’s democratizing publishing—empowering people to own their content on their site first and foremost, and optionally establishing a bidirectional relationship with external digital properties.
I agree with @tomfinitely. Right now, our default is to post to X for links/graphics/etc - and there's no great alternative. (And many of our writers/readers are no longer on X and have no place to put these 'bits.') That's become the catch-all. I would much rather post all of these "bits" to Wordpress and have them go everywhere.
Here's an example: - would have loved to make that a graphic + caption.
What I would suggest is to concentrate on the low hanging fruits first. So:
- Allow querying the "standard" post format.
- Add post formats as a fourth filter to the query loop block.
- Allow / create archive templates (e.g. archive-image.html) and single post templates (e.g. single-image.html) for post formats
@nickbohle Oh, absolutely, these are big foundational items that are necessary before we can get true block theme support.
The query is possible now but requires you to write JS and PHP for a block variation. That would be an easy win, I'd think, to add to Core.
Archive templates are already supported: taxonomy-post_format-post-format-image.html
. The name is not pretty, and it'd probably be worth stripping the post-format-
prefix from the slug in get_taxonomy_template()
for a nicer developer experience. I don't think this is a "registered" template in the UI, so it might just show the filename instead of a label. Supporting these in the UI would be huge.
Single templates do not currently support post formats without a custom filter, and this would be a relatively straightforward thing to add in the get_single_template()
function.
I'm going to do some experimenting to just try adding some baseline support for these things to see what it looks like. Good callout to refocus on the basics. 💯
@justintadlock, thank you very much for your reply.
The query is possible now but requires you to write JS and PHP for a block variation. That would be an easy win, I'd think, to add to Core.
I used the following patch for the standard post query for serval years. Link to trac.Yes, it is quite old.
Archive templates are already supported:
taxonomy-post_format-post-format-image.html
. The name is not pretty, and it'd probably be worth stripping thepost-format-
prefix from the slug inget_taxonomy_template()
for a nicer developer experience. I don't think this is a "registered" template in the UI, so it might just show the filename instead of a label. Supporting these in the UI would be huge.
I could not wait and just tested it by copying the archive.html and renamed it to taxonomy-post_format-post-format-image.html
. Yes, the name in the template table is not pretty, but it works like a charm. Also edited the template that it only shows the featured image and the title, but no content. See: /type/image(
Single templates do not currently support post formats without a custom filter, and this would be a relatively straightforward thing to add in the
get_single_template()
function.
Well, what I already did before is to create a custom single post template with no featured image, then I bulk edited all post format image posts and assigned the new template to them. So, so archive shows the featured image now but no duplicate image on the post itself.
I'm going to do some experimenting to just try adding some baseline support for these things to see what it looks like. Good callout to refocus on the basics. 💯
Thanks again!
I don't think this is a "registered" template in the UI, so it might just show the filename instead of a label. Supporting these in the UI would be huge.
For informational purposes, after editing and saving the template file, the unattractive name in the UI „taxonomy-post_format-post-format-image.html“ is updated to „Format: Image“ with the description „Template for Image.“.
And @justintadlock, thanks again. My new archives for posts with the type image or quote in Twenty Twenty-Four. More details here.
I second what @carstingaxion says about Post Kinds, a plugin that was created with similar intentions to Post Formats.
https://github.com/dshanske/indieweb-post-kinds/
Reintroducing post formats & merging post kinds with default support in WordPress core would be a big win for the open web and fediverse.
I found that all that was needed to be able to create archive templates for the post formats, using the "Add new Template" button in the Site Editor, was to to enable 'show_in_rest' for the post format taxonomy.
I am setting show_in_rest
to true in 64167.
I found that all that was needed to be able to create archive templates for the post formats, using the "Add new Template" button in the Site Editor, was to to enable 'show_in_rest' for the post format taxonomy. I am setting
show_in_rest
to true in 64167.
In review of 64167, setting show_in_rest to true is discouraged, so this can not be used as a solution for enabling creating the templates.
I know this is a long conversation, but want to add into this that the entire reason why I'm using post formats is because it is the only way to create different types of content on a website using the mobile app.
I use my entire site as a central hub, and that means that I'm posting everything through that first. Tweets, videos, blog posts, all of it. This means that I'm frequently using the mobile app to publish.
If it were possible to make custom post types display in the app, I'd probably be more open to using them instead of post formats, but since that's not the case, I really think we need to have better support for post formats in themes.
I think it should be possible to turn a blog archive into a "feed", where different formats appear differently in the feed based on the format. This might mean extending the post template blog so that you can specify how a post looks for different formats - that would be awesome.
It would also be great if there was a way to customize the layout of single post pages based on post format.
Edit:
In the meantime, I've been able to solve most of the problems related to limitations with support for post formats using a couple block plugins, and a PHP snippet that makes post formats readable as post metadata.
What is already possible with plain vanilla WordPress, default theme Twenty Twenty-Five and a simple plugin that activates Post Formats in TT5?
I think it should be possible to turn a blog archive into a "feed", where different formats appear differently in the feed based on the format. This might mean extending the post template blog so that you can specify how a post looks for different formats - that would be awesome.
A combined feed of different post formats is not yet possible, but you can create separate archives templates for the different post formats. They will have the slug /type/ and even have their own RSS feed, e.g. /type/image/rss. A lot of dev time (#64167 thank you all) is invested to filter the post formats with the Query Loop Block, when it is implanted, you can have different „format“ feeds on one template.
It would also be great if there was a way to customize the layout of single post pages based on post format.
This is also already possible when the respective templates are created and applied to the new post (unfortunately, the second step is not yet possible in the iOS WP app but it works in the mobile browser. )
More details on the How can be found here
@alexstandiford Yes. I think the need of what you describe is clear. I hope block themes will offer some way to implement that.
I consider post format as sort of a post type light thing, without the trouble of formalizing the content by adding custom fields. Both are basically a way to mark an entry for some kind of formatting, but post types are often extended with custom fields and some custom functionality (from a plugin or theme). Post formats are always meant to show, where post types often can be supportive of a main post type too.
Since using different post-formats in themes normally come with guidelines (or assumptions) on how to setup the content so it will be formatted as intended, it was really not only about formatting, but also about content structure. That makes them a bit like a post-type too, rather than only a format driven marking. Probably it was just an easy way to utilize what was already there with minimal impact on the data model. But the possibility of differentiating different formats in a blog or archive page, was a nice thought.
But having a block editor means the formatting within the post is now as flexible as blocks allow and themes can just offer block styling. So what remains are only the pages that list posts in some way.
You need some way to differentiate different posts types en formats on an archive level and if that archive shows more than one format or post, how to do that in a theme? No problem for conventional themes and hybrid themes that can just program a template part, but how to do that in block themes without the need of programming?
So I agree about the need you state of this kind of functionality, if query blocks are the replacement of queries in conventional theme templates using template parts to do this kind of differentiation. If this is basic functionality in WordPress, then themes will probably use it, or otherwise the admins may use it to enhance the chosen theme.
I don't use the app like you do, but it seems a way of formatting the archive summary of different post types and post formats is a need to be met, at least if block themes want to replace that kind of formatting too. Otherwise block themes may never be able to fully replace the needs of what conventional themes have offer and perhaps will be limited in use. Then the question needs to be asked to the theme devs instead.
Problem for admins is that a basic theme often needs some customization if a plugin/functionality is added to a website at some point. F.i. WooCommerce is often part of premium themes styling, but perhaps events calendar is not, or some course plugin.
When you add such functionality the singles page is often taken care of (mostly) by the plugin, but a custom format for an archive page using a block theme might not be that easy without this functionality. They can add a block for an archive only showing the plugins post_type, but then f.i. the search results are still not displayed in the right formats.
It's a nice challenge, but it's enough of a need to having kept me from using block themes on production websites that I maintain. Courses, products, tickets and events need to differentiate themselves in search results and archives.
Just getting back into WP and I love post formats. I don't know a lot about blocks yet, so there might be some ways to achieve what I'm talking about. I know, at least, that it's possible to iterate over the blocks and extract information about them.
I was thinking about how one of the recommendations for link post formats is to get the first link in the post body to use that as the intended link for the post.
In the same way, one could check the first block in the post and assign the post format that way. It would be super cool if blocks themselves could define their own post formats and if a post could be restricted to have a single block. If I remember correctly, there's a way for a block to contain other blocks, so it would be a "post format block" that contains whatever inner blocks one wants.
But anyway, the idea here is get the first block, see if that block is what we want for the post format, then set the post format based on the block. Ideally there would be some way to use the block's metadata to determine the post format.
What do y'all think about this approach? Not sure how this would square with the mobile app, but I think it would be a cool approach to using blocks to set the post format.
@draganescu @justintadlock Can you help me narrow down what the next actionable steps are, so that separate issues can be created where the technical solutions can be discussed. This issue is getting more difficult to manage.
After having implemented post formats in TT4 and WP 6.7 beta1 (and higher), please let me extend the list with the following thoughts (not only block theme related):
@nickbohle I am not sure I understand what you mean with point two. I am reading this comment literally, and if you are creating a new page template and adding a query loop to it, it will indeed behave like a page template, not an archive template.
The standard is not a type of format, rather it is the "lack of" format.
@nickbohle I am not sure I understand what you mean with point two. I am reading this comment literally, and if you are creating a new page template and adding a query loop to it, it will indeed behave like a page template, not an archive template.
The standard is not a type of format, rather it is the "lack of" format.
@carolinan, thank you for your prompt response. Yes, I understand that „standard“ isn’t a real post format. In fact, I used to run a plugin that generated the slug type/standard/ before switching to TT4.
I’d like to have the „Standard“ permalink integrated into the core so that all posts can be accessible not only through the Query Loop block but also through the permalink structure. Since this isn’t feasible at the moment, I created a page with a custom query loop as a (temporary) solution. Apologies for any ambiguity in my previous response.
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?
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.