Better handling for plugin modification of core blocks

[danielbachhuber]

A plugin can use the blocks.getSaveElement to modify the saved output of a Gutenberg core block. I started documenting this here: #8470 (review)

For instance, I may want to write a plugin which adds a data-pin-description attribute to an Image Block:

<!-- wp:image {"id":33863} -->
<figure class="wp-block-image"><img data-pin-description="My Pinterest description" src="http://tastyrecipes.test/wp-content/uploads/2018/03/food-dinner-pasta-broccoli.jpg" alt="" class="wp-image-33863" /></figure>
<!-- /wp:image -->

However, if the plugin is deactivated after the user adds a Pinterest Description to their Image Block, the Image Block, the block will enter into an invalid, crashed state.

The Classic Editor permits manipulation of any HTML5 element, in accordance to the entire spec. It would be ideal of Gutenberg permitted the same: #6878 (comment)

Related #7811
Related #8472

[danielbachhuber]

My workaround for this was to store my plugin data in post meta instead. There were a couple of notable downsides:

• Because the data is stored in post meta and filtered into post_content, it won't persist as the user expects it to persist when the plugin is deactivated.
• Storing JSON-serialized data in post meta feels quite dirty. See https://core.trac.wordpress.org/ticket/43392 for a related conversation.

On the plus side, register_meta() worked surprisingly well in tandem to registering the Block attribute.

Some partial code snippets:

/**
 * Register our Pinterest meta attributes after we know all post types in the REST API.
 */
public static function action_init_late_register_meta() {
	foreach ( get_post_types( array( 'show_in_rest' => true ), 'objects' ) as $post_type ) {
		$class = ! empty( $post_type->rest_controller_class ) ? $post_type->rest_controller_class : 'WP_REST_Posts_Controller';

		if ( ! class_exists( $class ) ) {
			continue;
		}
		$controller = new $class( $post_type->name );
		if ( ! is_subclass_of( $controller, 'WP_REST_Controller' ) ) {
			continue;
		}

		if ( ! post_type_supports( $post_type->name, 'editor' ) ) {
			continue;
		}

		register_meta(
			$post_type->name,
			self::TEXT_KEY,
			array(
				'show_in_rest' => true,
				'single'       => true,
				'type'         => 'string',
			)
		);
	}
}

/**
 * Register 'data-pin-description' attribute to 'core/image' block.
 */
hooks.addFilter(
	'blocks.registerBlockType',
	'wp-tasty/tasty-pins',
	function( settings, name ) {

		if ( 'core/image' !== name ) {
			return settings;
		}
		settings = lodash.assign( {}, settings, {
			attributes: lodash.assign( {}, settings.attributes, {
				pinterestText: {
					attribute: 'data-pin-description',
					default: '',
					type: 'string',
					source: 'meta',
					meta: tastyPinsBlockEditor.text_key
				}
			} ),
		} );

		return settings;
	} );

// Because we share one post meta for all stored values,
// we need to keep the meta value in sync between blocks.
var descriptionValues = null;

/**
 * Register a control for editing 'data-pin-description'.
 */
hooks.addFilter(
	'editor.BlockEdit',
	'wp-tasty/tasty-pins',
	wp.compose.createHigherOrderComponent( function( BlockEdit ) {
		return function( props ) {
			if ( 'core/image' !== props.name || ! props.attributes.id ) {
				return el( BlockEdit, props );
			}

			if ( null === descriptionValues ) {
				if ( props.attributes.pinterestText ) {
					descriptionValues = JSON.parse( props.attributes.pinterestText );
				} else {
					descriptionValues = {};
				}
			}
			var descriptionValue = '';
			var valueKey = 'image_' + props.attributes.id;
			if ( typeof descriptionValues === 'object' && typeof descriptionValues[ valueKey ] !== 'undefined' ) {
				descriptionValue = descriptionValues[ valueKey ];
			}

			return el(
				wp.element.Fragment,
				{},
				el(
					wp.editor.InspectorControls,
					{},
					el(
						wp.components.PanelBody,
						{ title: 'Tasty Pins' },
						el(
							wp.components.TextareaControl,
							{
								defaultValue: descriptionValue,
								onChange: function( newValue ) {
									descriptionValues[ valueKey ] = newValue;
									props.setAttributes( {
										pinterestText: JSON.stringify( descriptionValues ),
									} );
								},
								label: 'Pinterest Text',
								placeholder: '',
							}
						)
					)
				),
				el( BlockEdit, props )
			);
		};
	} ) );

[chrisvanpatten]

Thanks for leaving the code sample @danielbachhuber I have a feeling this will come in handy on some client projects.

This also relates to #10444 which suggests allowing blocks to rebuild themselves automatically if they are able to do so.

[danielbachhuber]

I ran into an odd edge case with how I implemented this with a second register_meta() call.

register_meta(
	$post_type->name,
	self::TEXT_KEY,
	array(
		'show_in_rest' => true,
		'single'       => true,
		'type'         => 'string',
	)
);
register_meta(
	$post_type->name,
	self::NOPIN_KEY,
	array(
		'show_in_rest' => true,
		'single'       => true,
		'type'         => 'string',
	)
);

When I hit "Save draft", I'd see an "Updating failed." message:

The source of the error was rest_meta_database_error, which I tracked down to:

1. Gutenberg sends both meta attributes, even when only one has updated.
2. Because one of the meta attributes hasn't changed, the REST API fails with its update_metadata() call: https://github.com/WordPress/WordPress/blob/56c162fbc9867f923862f64f1b4570d885f1ff03/wp-includes/rest-api/fields/class-wp-rest-meta-fields.php#L332

My amazingly hacky solution was to set a random value on both blobs each time the value for one attribute is changed:

// Set all property attributes at the same time.
// Doing so ensures new values present in the REST request
// and avoids 'rest_meta_database_error' failure.
function propsSetAttributes() {
	descriptionValues['int_random'] = Math.random();
	noPinValues['int_random'] = Math.random();
	props.setAttributes( {
		pinterestText: JSON.stringify( descriptionValues ),
		pinterestNoPin: JSON.stringify( noPinValues ),
	} );
};