Core blocks Image and Gallery should provide easy access to their data

[markfinst]

Text blocks, like paragraph and blockquote, can be styled just via CSS and would rarely need customizations of HTML markup.

Unlike text blocks, "Gallery" and "Image" might need advanced customization of HTML from the backend side.

Use cases

• Replace <img> with <picture>
• Replace <img> with entirely different markup for the purpose of lazy-loading.
• Add special sizes attribute for responsive images.
• Add special attribute required by lightbox or another script (for example path to large image or dimensions of a large image)
• Specifically for the gallery - wrap a group of images with a specific element to create a specific layout (for example carousel or advanced grid).

Surely, all this would be applied by theme or by a plugin, so nothing should break when turning them on and off.

Current Status of Image Block

Stores attachment ID in JSON.

<!-- wp:image {"id":2253} -->

Which is good. But it does NOT store:

• Caption
• Textual Alternative option
• Image Size option (full, thumbnail, medium etc.)
• Link URL option (stores only linkDestination option)

Current Status of Gallery Block

Gallery block does not store any data about images or their captions. The only way to retrieve it is to parse HTML via regex (specifically data-id attribute). Which is slow and unreliable.

Solution Proposal

1. Store gallery attachment IDs in JSON

<!-- wp:gallery { "items": [ {"id":1}, {"id":2}, {"id":3} ] }   -->

The Gallery should store an array with data about every image so it can be fully recreated on backend, specifically: attachment ID or image URL (if custom URL is added).

It should also use the same filters as [gallery] shortcode and gallery widget that was added to WordPress core recently.

2. Do not separate native caption and alt from "Write caption" and "Textual Alternative" within Gutenberg

When editing Image caption in Gutenberg it should change the native WordPress Attachment "Caption" field too. Same for "Textual Alternative" (alt) option. They should also be named the same to avoid confusion.

3. Image Block - store Link URL option and Image Size option in JSON

Developer might need to recreate markup of image on backend.

Related issues

• Filter {post_gallery} does not work with Gutenberg #9001, Gallery Block doesn't apply the 'post_gallery' filter, causing incompatibility with WP Gallery Custom Links #5972, Gallery: figure out way to fallback to shortcode #1451 Filter {post_gallery} does not work with Gutenberg
• Filter Image Block attributes (or markup) when image is selected in Media Library #8472 Filter Image Block attributes (or markup) when image is selected in Media Library
• Gallery Block: The "Edit Gallery" modal is unaware of any captions added within Gutenberg.  #8310 Gallery Block: The "Edit Gallery" modal is unaware of any captions added within Gutenberg

[pento]

For get_post_galleries() to function correctly (WP#43826), we're going to need to store the attachment IDs and image URLs in the JSON blob.

[mcsf]

I'll reply to @markfinst's items separately:

1. Store gallery attachment IDs in JSON
2. Image Block - store Link URL option and Image Size option in JSON

These are equivalent and just require us to switch away from sourcing Gallery and Image attributes in the HTML. It's technically an easy change and we can make that happen. I'll just note that I regret doing it, because it is a reflection of the current shortcomings in the server-side block API — ideally we wouldn't duplicate into the block boundary information that can be found in a block's HTML.

---

2. Do not separate native caption and alt from "Write caption" and "Textual Alternative" within Gutenberg

This is IMO a separate issue. I understand the need for it, but it's a little harder to prioritise it at the moment. Here's my perspective: WordPress attachment and attachment pages are very idiosyncratic concepts that have come to be to solve a very WordPress-specific set of problems — they allow developers to leverage the template hierarchy to overload the notion of attachments, effectively treating media items as CPTs in disguise, etc. This doesn't map very well to the editor-centric experience in Gutenberg, which arguably encourages different flows; I'm notably looking at reusable blocks to create "Attachment details" blobs, etc. I argued something very similar for ID-less galleries here.

That's not to say we can't accommodate classic media attachments. Probably so, but I'd ask you to open a separate issue to discuss that, because I find it hard to prioritise that into WordPress 5.0.

[mcsf]

I see that you've commented about point no. 2 in #8310, so that issue is enough.

[Intervik]

Please dont: Do not separate native caption and alt from ... Native caption field is media component and their data. Gutenberg caption field is presenting media data in an article - caption related to the content. Editorial companies might using same image e twice, where in a "fader" for example, using saved caption (attachment excerpt) BUT within a post news article using the image with article related Gutenberg added caption. This is very important that Gutenberg doesnt cludder with attachment saved data!