Largo-specific photo credit metadata is not output in image block

[benlk]

The media credit metadata added by the Navis Media Credit plugin (included in Largo) in https://github.com/INN/largo/blob/v0.6.1/lib/navis-media-credit/navis-media-credit.php isn't output on Gutenberg image blocks.

• can Image Block output be modified?
• if it can, add the media credit output.

[benlk]

This might be possible, via the server-side function https://developer.wordpress.org/reference/functions/render_block/ which would allow modifying the wp:image block markup before it's output by do_blocks( $the_content ).

Here's what an image block's markup looks like:

<!-- wp:image {"id":98709,"align":"center"} -->
<div class="wp-block-image">
    <figure class="aligncenter">
        <img src="https://example.test/wp-content/uploads/2018/01/TEDx3.png" alt="" class="wp-image-98709"/>
    </figure>
</div>
<!-- /wp:image -->

And here's what the output of the_content() looks like:

<div class="wp-block-image">
    <figure class="aligncenter">
         <img src="https://example.test/wp-content/uploads/2018/01/TEDx3.png" alt="" class="wp-image-98709" srcset="https://example.test/wp-content/uploads/2018/01/TEDx3.png 731w, https://example.test/wp-content/uploads/2018/01/TEDx3-210x140.png 210w, https://example.test/wp-content/uploads/2018/01/TEDx3-336x224.png 336w" sizes="(max-width: 731px) 100vw, 731px">
    </figure>
</div>

Note the addition of srcset and sizes.

[benlk]

Can we look at the list of do_block handlers and to see if there's a PHP handler there that would let us more-easily write the image credits into the markup, rather than using regular expressions to parse HTML?

[joshdarby]

@benlk So far it looks like we only have two options here other than regex.

1. Use DOMDocument to parse html elements and insert the metadata after each image. Something like this

function add_media_credit_to_content_images( $content ){

	$content = mb_convert_encoding( $content, 'HTML-ENTITIES', "UTF-8" );
	$document = new DOMDocument();
	$document->loadHTML( utf8_decode( $content ) );

	$imgs = $document->getElementsByTagName( 'img' );

	foreach ($imgs as $img) {

		$attachment_id = attachment_url_to_postid( $img->getAttribute( 'src' ) );
		$attachment_credit = get_post_meta( $attachment_id, '_media_credit', true );

		$img_credit_element = $document->createElement( 'figcaption', $attachment_credit );
		$img->parentNode->appendChild($img_credit_element);

	}

	$html = $document->saveHTML();
	return $html;

}

add_filter( 'the_content', 'add_media_credit_to_content_images' );

2. Use the render_block filter to find any core image block, get their content, and do an ugly str_replacce to remove the ending </figure> tag, insert the caption, then insert a new ending </figure> tag, like this:

function add_media_credit_to_content_images( $block_content, $block){
	
	if ( 'core/image' === $block['blockName'] ) {

		if( !empty ( $block['attrs']['id'] ) ){

			$attachment_id = $block['attrs']['id'];
			$attachment_credit = get_post_meta( $attachment_id, '_media_credit', true );

			$block_content = str_replace( '</figure>', '', $block_content ) . "<figcaption>" . $attachment_credit . "</figcaption></figure>";

		}
	}
	
	return $block_content;
	
}

add_filter( 'render_block', 'add_media_credit_to_content_images', 10, 2 );

[joshdarby]

Another option would be to use the block filters API and actually add the credit into the editor when the image is selected.

[benlk]

That does sound better; it would avoid confusion between the editor depiction of the content and the frontend depiction.

[benlk]

• try out the block filters API
  • where is JS loading the metadata from?
• generate an estimate for this issue
• implement in all relevant image blocks

[joshdarby]

An update for this issue:

It's pretty easy to replace the caption in the Gutenberg image block in the editor. All you need to do is enqueue a JS file for Gutenberg edits, load the correct elements, and do props.attributes.caption = "My caption".

The hard part is grabbing metadata, which is where the media credit is stored. It doesn't look like you can choose what data to load for a block. Here's what you get back from props.attributes for an image:

attributes:
alt: ""
caption: ""
id: 366
link: "https://largo.dev/uncategorized/hello/attachment/screen-shot-2019-04-22-at-12-25-26-pm"
linkDestination: "none"
url: "https://largo.dev/wp-content/uploads/2019/04/Screen-Shot-2019-04-22-at-12.25.26-PM.png"

I suppose we could do a query to the WP API to grab the media credit?

[benlk]

If querying the API works, let's do that.

[joshdarby]

Querying the API works pretty well using something like this after registering the _media_credit meta field as a field for the API:

var attachment = new wp.api.models.Media( { id: attachment_id } );
var attachment_response = post.fetch().then( function( attachment ){
   var media_credit = attachment.media_credit;
}

The last thing I need to figure out is what filter to fire it on. Currently I have it set to editor.BlockEdit but that fires on every instance of the block being edited, such as hovered over, moved, updated, removed, etc. which we don't want.

[joshdarby]

Also, looks like there's no default way of achieving this sort of thing just yet: WordPress/gutenberg#8472

[benlk]

Maybe on blocks.getSaveElement?

[joshdarby]

Maybe on blocks.getSaveElement?

@benlk Probably something like that. blocks.getSaveContent.extraProps seems to be working.

[joshdarby]

To-do still:

• Figure out how to display inserted caption in block before reloading page after saving. Maybe blocks.getSaveContent isn't the correct filter to use?
• Add in media credit url also.

[joshdarby]

Figure out how to display inserted caption in block before reloading page after saving. Maybe blocks.getSaveContent isn't the correct filter to use?

Turns out you don't need to reload the page after saving, you just need to hang tight for a second.

[benlk]

We should open a companion issue here for the Gallery Block, and whatever other image blocks Core provides that we'd want to use image credits for.

We will also need to update the helpdesk docs for the changes introduced in #1733.

[joshdarby]

@benlk Should that be one issue or two separate (one for gallery, one for everything else)?

[benlk]

I think one for Gallery, one for Cover, one for Media and Text. Kinda taking the same approach as #1701