Create a generic Field block to display and edit post meta data

[bobbingwide]

Requirements

• A generic block to display the value of post meta field
• Optionally to display the field's description
• Optionally, to allow the value to be edited and saved

Proposed solution

• Use an attribute which accesses post meta data
• Dynamically alter the attribute's fields to refer to the chosen field
• Use the REST API to determine which fields can be displayed

attributes: {
		seenBefore: {
			type: 'string',
			source: 'meta',
			meta: '_seen_before'
		},
	},

Note: I don't yet know how to dynamically alter an attribute's fields,
nor do I know how to obtain each field's properties from the REST results.

Note: Even though I purchased ACF Pro in 2019, I've never been an ACF user.
I'm going to develop the block with server side rendering using oik-fields functionality.
If this can be extended to work with other methods of defining post meta data then that's a bonus.

Background to the requirement / proposed solution

In oik-blocks, the Fields block ( oik-block/fields ) is a Server Side Rendered block that displays post meta data and virtual information about a post. See https://www.oik-plugins.com/block/fields-oik-block-fields/
When the display option is All, it displays the values of all of the Fields associated with the post, including Taxonomy terms and virtual fields.

In order to display an individual field I still need to use a shortcode:

• [bw_fields _field_name] to display a field with a label
• [bw_field _field_name] to display a field without a label

An example is the home-body.html post template part in SB.

Here's the progression of development of the Seen before field.

[bw_field _seen_before]
[bw_fields _seen_before]
<!-- wp:oiksb/sb-field-block /-->
<!-- wp:bigram/seen-before /-->

Example result displayed:

1108
Seen before: 1108
Seen before:1,107 times
Seen before:1,108 times

The _seen_before field is now delivered as the bigram/seen-before block.
And Yes! I can explain why the value is 1107 in one place and 1108 elsewhere.
It's to do with the order of execution; blocks are expanded before shortcodes.

1. oiksb/sb-field-block - increments the post meta value
2. bigram/seen-before - also increments the post meta value
3. bw_field just displays the current value
4. bw_fields just displays the current value

Also from home-body.html, copied from Fizzie's metadates.html this uses [bw_field] since we're displaying properties of the post, rather than post meta.

<p>Published: [bw_field post_date] | Last updated: [bw_field post_modified] [post-edit]</p>

The [post-edit] shortcode is another candidate for a separate block.

Using shortcodes still has some advantages.

1. They can be typed inline in paragraph blocks
2. They don't need additional block development

Dynamic blocks have pros and cons relative to shortcodes

• If a dynamic block is not supported then nothing is displayed.
• If a shortcode is not supported then the unexpanded shortcode is displayed.

Whether not it's a pro or a con depends on your viewpoint.

Given that the way forward is to use blocks, block templates or block patterns and to eventually eliminate meta boxes
it makes sense to attempt to develop a generic field block that can be used to display and edit post meta data.

[bobbingwide]

Note: I don't yet know how to
obtain each field's properties from the REST results.

But I do know that the data is available in response to wp-json/v2/

bobbingwide/bigram#23 (comment)

[bobbingwide]

I copied the relevant part of the comment below

The meta data that has been registered is available in the REST API output.

URL	What you can see
wp-json/v2/	The properties for each meta data field associated with each post type
wp-json/v2/bigram	The actual value(s) for the meta data
wp-json/v2/bigram/ID	The actual value(s) for the meta data

Property definitions

Value for post

[bobbingwide]

I tried using

function getMetaFieldsAlt() {
	wp.apiFetch( { path: '/wp/v2',} )
		.then( data => {
		console.log( 'response:', data );
		}
	);
} 

to get this data but, unless I'm reading it incorrectly, the data that was visible when using /wp-json/wp/v2 in the browser is not in data. This doesn't make much sense to me.

I also note that this information is already being passed back to the browser in the editor.
It's in the $preload_data returned to the editor as the parameter to wp.apiFetch.use( wp.apiFetch.createPreloadingMiddleware()

So how do I get access to it myself?

[bobbingwide]

Note: I don't yet know how to dynamically alter an attribute's fields,

I asked these questions in #core-editor ( https://wordpress.slack.com/archives/C02QB2JS7/p1616951678463900 )

Can anyone point me to code in Gutenberg source that uses wp-json/wp/v2 to get access to the properties of meta fields for each post type? And perhaps some other code that will enable me to change the properties for an attribute with source: meta . Better still some documentation. Pretty please.

I got answers from Timothy Jacobs. He convinced me that since I was using setMeta I didn't need to have used an attribute to display the current value. This is the relevant code.

const [ meta, setMeta ] = useEntityProp(
		'postType',
		postType,
		'meta'
	);
	const metaFieldValue = meta['_seen_before'];
	function updateMetaValue( newValue ) {
		setMeta( { ...meta, '_seen_before': newValue } );
	}

So in the return I can replace {attributes.seenBefore} with {metaFieldValue}.
Therefore, I don't need to be able to change the seenBefore attributes meta value to refer to a different post meta key
I just need to change the hardcoded value in

const metaFieldValue = meta['_seen_before'];
	function updateMetaValue( newValue ) {
		setMeta( { ...meta, '_seen_before': newValue } );
	}

to be the attribute which will contain the name of the field being displayed.

[bobbingwide]

With regards to loading the mapping of field names to the description
eg { name: '_seen_before', value: 'Seen before' }
the REST request to perform uses the OPTIONS method.
This, I believe, is what discovery is all about.

My original code was something like this.

function getMetaFieldsAlt() {
	wp.apiFetch( { path: '/wp/v2/posts', 'method': 'OPTIONS'} )
		.then( data => {
		console.log( 'response:', data );
		var properties = data['endpoints'][1]['args']['meta']['properties'];
		console.log( properties );
		var propertyNames = Object.getOwnPropertyNames( properties);
		console.log( propertyNames );
		}
	);
}

Had I continued to use /wp/v2 then the data would have been differently structured.
Extracting the properties would have been something like this.

//var routes = data['routes'];
//var post_route = data['routes']['/wp/v2/posts'];
// var properties = post_route['endpoints'][1]['args']['meta']['properties'];

[bobbingwide]

Update to the requirements and proposed solution.

Requirements

1. Need an initial display to choose the post type then the field.
2. Once chosen the block should not need to list the fields.
3. Unless the user wants to change the field name
4. We have to cater for fields which don't have a description
5. And fields which aren't post meta fields, such as taxonomies
6. We need to cater for multi select fields
7. And fields which aren't actually strings - eg serialised fields

Proposed solution - for this sprint

• Implement the server rendering for the front end
• Add input fields for postType and fieldName as overrides to the selection list
• Add a post type selection list ( see oik-block/content )
• Improve the loading of the lists

[bobbingwide]

It didn’t take me long to realise how little you can actually achieve if you only know the meta key or name for a field. The REST API provides the Description, the data type ( string, numeric or Boolean) and whether or not the field is single but not much else to explain how to validate or display the value.

The difficult challenges are not going to be resolved by a plugin agnostic solution

1. How to cater for the different field types? Eg
2. What to do with post meta boxes? How to synchronise data?

[bobbingwide]

2. What to do with post meta boxes? How to synchronise data?

Assuming we can detect field block in the post content when the post is opened for editing, it should be possible to disable meta boxes that would otherwise duplicate the editing capability for post meta data.

This assumption is based on the fact that post meta boxes can be registered with a couple of options
In oik-block I recently used __back_compat_meta_box.

add_meta_box( 'oik_block', __( "Editor selection", 'oik-block' ), 'oik_block_meta_box', $post_type, 'normal', 'default',
        [ '__back_compat_meta_box' => true ]
        );

Setting it to true means that the meta box is only used in the Classic editor.
The alternative is to set __block_editor_compatible_meta_box to false.
See bobbingwide/oik-block#18 (comment)

The further assumption is that the meta box's registration can be amended at run time, just prior to the editor attempting to display it.