Gutenberg Image Block does not allow for editing of attachment_fields_to_edit

[Ipstenu]

Currently when you add an image to the TinyMCE editor, you get immediate access to the Media Editor:

What this means is that it's possible to add attachment_fields_to_edit to your media (complete with required fields) so you can enforce certain standards.

With Gutenberg, this field is only viewable via 'Editing' the image, which can be confusing and hard to find, as its nested down and no longer obvious. Also you can no longer require a field be filled in before saving the image to the post, which can cause issues with current flows.

This is a feature used by (just for one example) news media in order to have some data required and keep from falling afoul of legal messes.

Possible solutions:

1) Add the attachment_fields_to_edit to the image sidebar - This is SUPER crazy hard, but would logically be where people look. (It also increases the 'arrrrg'-ness of the perpetual confusion between what's post meta for the post, and what's post meta for the IMAGE itself - see the history of "Why did editing the TITLE of an image in Post A change it for Post B?") This is probably a terrible idea, and is only included here for the sake of completeness.

2) If attachment_fields_to_edit is detected for the post-type, have the Gutenberg Image Block (or the drag/drop add) pop open the Media Editor instead of just inserting the image. This was @karmatosed's idea, and I think it would at least get us to where the flow for those images are the same as today.

[joemcgill]

Just to make sure I'm clear about the issues here:

These fields are still visible in the media modal in Gutenberg. I've created this reduced test case that adds a location field to the media sidebar and saves the data to the attachment's post meta.

https://gist.github.com/joemcgill/dbec1854cd02d63b731c583f4a751e7c

These fields are most often used to save data to attachments themselves and not only to the display of those images in the current post being edited. The block settings in the sidebar, however, currently only affect the specific instance of an image in the current block. This is a good thing from a UX perspective because it avoids situations where someone would edit data for an image in one post and have it affect that same image in a completely different post — something that can happen quite easily in the current editor.

The main remaining issue seems to be that handling of required fields is no longer consistent since people can upload images directly to the post without opening the media library at all. @Ipstenu can you provide an example of that use case?

Also, is there anything else that I'm misunderstanding or have missed here?

[Ipstenu]

These fields are still visible in the media modal in Gutenberg.

By which you mean, once an image is uploaded, I can get to those fields by clicking to edit the image. They're no longer immediately available and required for ~upload~ insertion into the post, however. That's the change.

The main remaining issue seems to be that handling of required fields is no longer consistent since people can upload images directly to the post without opening the media library at all. @Ipstenu can you provide an example of that use case?

You mean like 'adding an image to a post'? Seriously that's literally all this is. I can add images to posts via drag/drop in Gutenberg. In doing so, I'm NOT prompted to fill in the required fields, which can result in information missing.

I don't know what use case you want, but I'll give you the legal one I'm currently facing. When using promotional photos from media (CBS, Fox, Getty, etc), you have to credit them beyond just alt-tags, so we added in an attribution field (see my screenshots in the issue). We go the extra step and then include that data in the alt information, but also in other meta data they require for full legal compliance. Without that field being obvious, people absolutely will make mistakes, getting us in trouble.

Numerous news sites use similar tactics (which I know because I showed them how to do it).

The 'right' fix would be to separate the meta data per-upload (not per image) but that's a kettle of snakes in a gordian knot that I wouldn't presume to attempt for WP in general, let alone Gutenberg. It's well out of scope. All I'm looking at is the reality that today I can ensure people use that attribution field by making it required, but I can't in Gutenberg.

[joemcgill]

I completely understand the use editorial goals you're describing. The specifics of how it's implemented is what I would like to test. I don't think there is an official API for enforcing that an image can't be inserted into a post without first filling out fields, so I'd like to be able to review a code sample.

Another possible solution for people who need to enforce this flow is to disable the file uploader and force uploads through the media modal instead, but I'm unsure if that will work without reproducing and comparing against the current expected behavior.

[Ipstenu]

https://code.tutsplus.com/articles/how-to-add-custom-fields-to-attachments--wp-31100 has a good explanation of how it all works, but you use attachment_fields_to_save (which is the other half of edit) to do it.

[fclaussen]

I have the same situation as @Ipstenu. A news outlet that needs to add the photographer credit to images. Without it, we get into a potential legal situation.

I can easily do it with the featured image but for images added to the_content, it's so much harder and seems to be even harder now with Gutenberg.

I've been searching for several hours if it is possible to filter the image block markup so I can add my extra data in there but no luck so far. The only thing I could find was how to add extra attributes.

[fclaussen]

By the way @Ipstenu I figured it out this morning. This is what I did.

On PHP I did:

function sbi_core_image_block_render( $attributes, $content ) {
    $photo_credit = sbi_get_photo_credit( $attributes['id'] );
    if ( $photo_credit ) {
        if ( strpos( $content, '<figcaption>' ) !== false ) {
            $content = str_replace( '<figcaption>', '<figcaption><span class="photo-credit">' . esc_html__( 'Photo:', 'sbi' ) . ' <strong>' . esc_html( $photo_credit ) . '</strong></span>', $content );
        } else {
            $content = str_replace( '</figure>', '<figcaption><span class="photo-credit">' . esc_html__( 'Photo:', 'sbi' ) . ' <strong>' . esc_html( $photo_credit ) . '</strong></span></figcaption></figure>', $content );
        }
    }

    return $content;
}
function sbi_register_core_image_block() {
    register_block_type( 'core/image', array(
        'render_callback' => 'sbi_core_image_block_render',
    ) );
}
add_action( 'init', 'sbi_register_core_image_block' );

This overrides the rendering of images. $content contains the html string and $attributes is an array with [id] which is the image ID. Then I get the image attribution and do a str_replace on the markup. If figcaption is present, just add my span in it, if not then add the figcaption with my span. This can be improved further, but it's ok for now.

Hope this helps.

[ldinkla]

Is there a good way solve this for taxonomies, i.e. to make the tags of an image (added and now visible in the media library ) available in gutenberg without leaving the flow?