Block Library: Add a Post Featured Image block.

[epiqueras]

Description

This PR adds a new Post Featured Image block akin to the Post Title and Post Content blocks.

How has this been tested?

• Inserted Post Featured Image block in a post.
• Confirmed post featured image rendered in the editor and front end.
• Inserted Post Featured Image block in a template.
• Confirmed post featured image placeholder rendered in the editor and the relevant post featured image rendered in the front end.

Types of Changes

New Feature: There is a new Post Featured Image block for template building.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[youknowriad]

Wondering if this could use the Image block somehow to avoid duplication of features.

[epiqueras]

Wondering if this could use the Image block somehow to avoid duplication of features.

I think it should use the post featured image component from the editor, but generalizing it will be a bit more involved and should be handled in another PR.

[youknowriad]

I think it should use the post featured image component from the editor

I'm not certain about that, in the sidebar you just want to assign the featured image but in a template, you want to assign it but also show it, scale it, maybe apply it as a Cover, maybe align it. And all these features are already covered in the Image or cover blocks. So we should be thinking how can we make these work together.

[epiqueras]

I think we need a generic image-edit component.

Do you think that should block this PR though?

[youknowriad]

I'd love @mtias thoughts on this PR and that problem. I know this is something that we discussed briefly before.

[mtias]

Something that's been brewing in my mind is the possibility of using the variations system to replicate certain basic blocks while connecting them to independent data sources transparently. If it works, I consider it a bit more elegant of a solution than having to piece together a similar interface out of components (such as edit-image). I'd be inclined to see if we could turn this block into a variation of the Image block without much effort — where it takes over the src attribute (and other relevant pieces) while retaining the larger customization options.

[epiqueras]

Ooooh, I've thought about this.

We could support registering variations where you can map attributes to entity props, and the framework handles the syncing under the hood.

I held back on it because I thought the use cases were too small to warrant supporting this as a top-level API when you can achieve the same thing with minimal code.

What do you think, @youknowriad? It's kind of similar to the custom sources API that we ended up deprecating for lack of flexibility to avoid having different ways of doing the same thing.

[mtias]

Yes, exactly! I think variations have opened up such a door as it'll reduce a lot of pointless duplication while still keeping a sense of autonomy and clarity. My worry is how it might impact the internal handling of the source block (as it'd need to disable certain UIs based on presence of attributes or types of attributes: entity vs editable, etc), where it could create conditional trees that exacerbate the complexity, but it does look, at least conceptually, a good path. We should proceed with caution and see what kind of pitfalls it might create.

[epiqueras]

Can you think of other examples where this API would be useful? I think that the component approach might be better when you consider for example that most Image block variations would want to add/remove things to the UI like you said or perhaps even include it within a set of inputs.

[youknowriad]

Interesting idea 👍

I think such API could be useful in a more situations. For example, any RichText entity value (example post title) could be a variation of the Paragraph block.

I'm still not sure whether this is a block variation or something else as there's a few things we want to customize:

• The save function as we want to return "null" probably for the "entity variations"
• The server side rendering: in some ways, this is the same thing as the "save" function but swapping the "source" with the entity value.
• The source of the attributes
• Disabling UI elements sometimes and removing some attributes (alignments)

At the moment, I'm having a hard time thinking of a good flexible API for this though.

[epiqueras]

Those are the reasons that make me think an API for this would be so convoluted and seldom used by third parties that it's not worth exploring.

[epiqueras]

@youknowriad I think this PR should be merged. It cleanly implements the non-editable part of the block and is something we need to play with themes.

[youknowriad]

Yes, happy to land this as a start.

[markhowellsmead]

Semantically, this would be better wrapped with a figure tag , which should additionally have a class name so that it can be targeted by Theme and Plugin developers.

[markhowellsmead]

This tag should have a class name so that it can be targeted by Theme and Plugin developers. Also, the alt text cannot be translated if it's defined statically.

[markhowellsmead]

This text cannot be translated if it's defined statically.