Size Change: +132 B (+0.01%)

Total Size: 2.37 MB

_{compressed-size-action}

Flaky tests detected in be2f49d.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18915118688
📝 Reported issues:

• [Flaky Test] ensures List View global shortcut works properly #51533 in /test/e2e/specs/editor/various/list-view.spec.js

I wonder how this relates with the idea of block attributes being the same thing as "dataviews field API" and also the same thing conceptually as JSON Schema.

How do images get represented in JSON Schema is something we should be looking at. Maybe it's a type (current approach in DataViews), maybe it's something else.

There's some consolidation to think about it here.

Interesting exploration. Enforcing some structure for content attributes is becoming more critical as we scale the block editor capabilities.

@ockham did a bit of different but related research on how to map an image object properties to the Image block or Featured Image block attributes through Pattern Overrides or other forms of Block Bindings to support native functions like get_the_post_thumbnail_url or custom post meta:

• Block Bindings: Try using __default for generic bindings #71002

My only comment is that this proposal is very specific to a small number of blocks, so it's worth considering generalizing it to content where media is only one of several formats.

I wonder how this relates with the idea of block attributes being the same thing as "dataviews field API" and also the same thing conceptually as JSON Schema.

How do images get represented in JSON Schema is something we should be looking at. Maybe it's a type (current approach in DataViews), maybe it's something else.

@youknowriad can you elaborate a bit on these?

This is a cool exploration, useful regardless of outcome. You got me thinking about a couple of things: the possible overuse of role: content that you mentioned, and the semantics of "media blocks". By the latter, I mean questions like: Are there blocks that are solely about media, mainly, or secondarily about media? Does that distinction matter? How does "content" and "media" relate? And so on.

If, like me, you're curious about what roles are currently used in the core block library:

{
  "core/accordion-heading": {
    "title": "content"
  },
  "core/audio": {
    "blob": "local",
    "src": "content",
    "caption": "content",
    "id": "content"
  },
  "core/button": {
    "url": "content",
    "title": "content",
    "text": "content",
    "linkTarget": "content",
    "rel": "content"
  },
  "core/categories": {
    "label": "content"
  },
  "core/code": {
    "content": "content"
  },
  "core/cover": {
    "url": "content"
  },
  "core/details": {
    "summary": "content"
  },
  "core/embed": {
    "url": "content",
    "caption": "content",
    "type": "content",
    "providerNameSlug": "content",
    "responsive": "content",
    "previewable": "content"
  },
  "core/file": {
    "blob": "local",
    "href": "content",
    "fileName": "content",
    "textLinkHref": "content",
    "downloadButtonText": "content"
  },
  "core/form-input": {
    "label": "content",
    "placeholder": "content"
  },
  "core/gallery": {
    "caption": "content"
  },
  "core/heading": {
    "content": "content"
  },
  "core/home-link": {
    "label": "content"
  },
  "core/html": {
    "content": "content"
  },
  "core/image": {
    "blob": "local",
    "url": "content",
    "alt": "content",
    "caption": "content",
    "title": "content",
    "href": "content",
    "id": "content"
  },
  "core/list-item": {
    "content": "content"
  },
  "core/list": {
    "ordered": "content",
    "values": "content"
  },
  "core/math": {
    "latex": "content"
  },
  "core/media-text": {
    "mediaAlt": "content",
    "mediaId": "content",
    "mediaUrl": "content",
    "href": "content",
    "mediaType": "content"
  },
  "core/more": {
    "customText": "content"
  },
  "core/navigation-link": {
    "label": "content"
  },
  "core/navigation-submenu": {
    "label": "content"
  },
  "core/paragraph": {
    "content": "content"
  },
  "core/post-author-name": {
    "isLink": "content",
    "linkTarget": "content"
  },
  "core/post-author": {
    "isLink": "content",
    "linkTarget": "content"
  },
  "core/post-date": {
    "datetime": "content",
    "isLink": "content"
  },
  "core/post-excerpt": {
    "moreText": "content"
  },
  "core/post-featured-image": {
    "isLink": "content",
    "rel": "content",
    "linkTarget": "content"
  },
  "core/post-navigation-link": {
    "label": "content"
  },
  "core/post-terms": {
    "prefix": "content",
    "suffix": "content"
  },
  "core/post-title": {
    "isLink": "content",
    "rel": "content",
    "linkTarget": "content"
  },
  "core/preformatted": {
    "content": "content"
  },
  "core/pullquote": {
    "value": "content",
    "citation": "content"
  },
  "core/quote": {
    "value": "content",
    "citation": "content"
  },
  "core/read-more": {
    "content": "content"
  },
  "core/rss": {
    "feedURL": "content"
  },
  "core/search": {
    "label": "content",
    "placeholder": "content",
    "buttonText": "content"
  },
  "core/shortcode": {
    "text": "content"
  },
  "core/site-logo": {
    "isLink": "content",
    "linkTarget": "content"
  },
  "core/site-title": {
    "isLink": "content",
    "linkTarget": "content"
  },
  "core/social-link": {
    "url": "content",
    "label": "content"
  },
  "core/table": {
    "caption": "content"
  },
  "core/verse": {
    "content": "content"
  },
  "core/video": {
    "caption": "content",
    "id": "content",
    "blob": "local",
    "src": "content",
    "tracks": "content"
  }
}

jq -s '
	map(
		{
			key: .name,
			value: (
				.attributes
				| to_entries?
				| map(select(.value | has("role")))
				| map({key: .key, value: .value.role})
				| select(length > 0)
				| from_entries
			)
		}
	)
	| from_entries
' packages/block-library/src/*/block.json

Some generalisations from this:

• The content role absorbs a lot of data that could be re-modelled as media
• The content role feels more like an annotation that says "preserve me" (e.g. over a transformation). If it has any real meaning left, I'd argue that it's content = ⌐ design

Could this be useful in some way to pattern content only editing?

Thanks for the ping! I can't say for sure, but I'd wager such metadata would be useful, for example, to target bespoke behaviour for various media blocks in content only mode. The first thing that comes to mind is editable fields.

cc @talldan

• The content role feels more like an annotation that says "preserve me" (e.g. over a transformation). If it has any real meaning left, I'd argue that it's content = ⌐ design

This distinction is central to contentOnly mode, because the attributes that have the content role are still editable in that mode (this should apply not only to the contentOnly patterns experiment but also to the templateLock)

I'm not sure a media role would solve any specific problems we have with contentOnly mode, because generally we want media to be editable similarly to text: you should be able to replace it, and edit text attributes such as alt, captions etc. In other words, there hasn't been a need so far to treat media in any way differently from text content.

Thanks for the ping! I can't say for sure, but I'd wager such metadata would be useful, for example, to target bespoke behaviour for various media blocks in content only mode. The first thing that comes to mind is #71557.

It's still quite an early draft, but agree it could be helpful for that - I added some very similar 'mapping' code in the PR, which I planned to make optional, but this would hopefully allow me to remove that completely for media fields.

Another use case might be related to an idea I had - being able to surface all the 'attachments' that are used within a post.

One thing I'll mention is that the mediaRoles feels quite specific for the one use case. For example, a wp/block also maps to pattern post types in a similar way to images mapping to attachments. Navigation blocks, template parts and probably others also map to entities.

So I wonder if this can be made more general to map any kind of entity or resource. That way it could allow for discovering any kind of entity usage within block content and support parsing values. It might contribute to solving this - Tracking and providing insights about consumption of global elements, and also be useful for things like preloading entities.

For example, a wp/block also maps to pattern post types in a similar way to images mapping to attachments. Navigation blocks, template parts and probably others also map to entities.

@talldan can you expand a bit on this? What kind of config would be useful to handle the wp/block to pattern post types for example?

@talldan can you expand a bit on this? What kind of config would be useful to handle the wp/block to pattern post types for example?

Something like this to indicate that the wp:block block loads the 'block' post type, with the 'ref' attribute being the post id?

resources: {
    block: { id: 'ref' } // maps to `postType/block` resource
}

getBlockResource( 'block' ) // { id: 12 }
getBlockResource( 'attachment' ) // { id: 32, src: 'https://example.com/cover.png', mediaType: 'image' }

Though I'm not sure the more I think on it, this is quite different to what others are discussing and maybe it's not the right use case to solve with this API.

What has been mentioned in other comments is the config is more related to dataview fields. So I think it's similar to what I'm working on in #71730. In that PR I'm trying to generate a 'form' (I plan to make it a DataForm at some point) for editing blocks in the inspector. At the moment it's only concerned with content attributes, and across our core blocks that's really only Text, Links and Media field types. Link and Media are the two that have very inconsistent attribute definitions so need some kind of mapping.

I think for your use case in List View, you could possibly render a 'read only' version of a media field.

I shared here what I think about the connection of this PR with the formats+type PRs for fields API and block attributes. I'll past the part that is relative to this PR.

Regarding my media roles experiment, it seems it's also a different thing from JSON format and types. In general it tries to add semantic info in some attributes, which I cannot see how they fit in these format+type approaches. Sure, we could have some kind of convention that for example a mediaAlt prop should always be type:string and use that info for whatever we'd need.

So, to answer @youknowriad's question, I don't think the semantic info we want should be part of type or format. We could have conventions/mappers about the roles to match a specific type (mediaAlt->string), but probably that would be it.

So maybe this exploration, expanded to support more things other than media roles, with some kind of mapping with specific roles to attributes might be helpful for more cases besides the media roles. If that would be the case, @talldan could your example about resources be part of such a config in block.json, and actually be helpful?

Sorry for the delay in responding @ntsekouras, I had some AFK and missed the ping.

I think it's pretty difficult to predict right now what's going to happen as there's a lot of work happening in parallel. I would say what's known is that there's going to be a way in the near future to map block attributes to dataviews fields. There is already a rudimentary API that's being explored as part of the contentOnly experiments (Pattern fields in the inspector panel: use the DataForms API). I think that needs to becomes a lot more mature, and I think it'll need to expand to more block attributes.

Whether that's enough to satisfy your use case, I'm not sure. I think there will be a way to associate attributes with their purpose for a media field. MediaUpload particularly, but perhaps it's also enough to show a MediaThumbnail in List View. I guess the field type might be loose enough that you could use different field implementations, or the same field could appear in different ways for different contexts.

@oandregal is the fields expert, so might be able to help with interpretation. 😄

TBH, the proposals feel quite closely associated, so maybe it's worth waiting to see how the block fields develop.

Just noting, for the purposes of traceability, that this work is also very related to #73845.