Full Site Editing: Investigate options to make Publish button clickable on site block changes [5+5]

[gwwar]

As originally reported by @mmtr the Save/Publish button should be clickable in the block editor when a change is made to a site block like Site Title or Site Description.

To reproduce this case:

1. Make sure there are no other post content changes
2. Edit the site title with a new value
3. Publish/Save button should be clickable.

Internally, these are dynamic blocks that are represented the template_part as <!--wp:a8c/site-title /-->. When a user updates the title from say "Hello World" to "Foo Bar", this is not serialized as a part of the block, because this should be updated via API in the site option instead. (Values would quickly get out of sync if we tried to serialize this).

[mmtr]

Props to @glendaviesnz for actually identifying this behavior when he was setting up the FSE environment! I only reported what he found :)

[mmtr]

Seems that withChangeDetection could be useful here.

[mmtr]

Another thing to consider (either on this issue or on a new one) is the draft status. If a user changes a site setting within a block and the template is not published but saved as a draft, we shouldn't save the setting until the template is published. But we should store somewhere the draft value of the site setting and use it on the template draft.

Example:

• The current title of my site is "My Site Title".
• I start creating a new template and insert a Site Title block.
• I change the title on the block to "My New Site Title".
• I save the template as a draft.
• The title of my site should still be "My Site Title".
• If I reload the template editor with the template draft previously saved, the content of the Site Title block should be "My New Site Title".

[glendaviesnz]

I have looked for an option to get the editor to see content as dirty if an FSE block is updated without duplicating the site option data in the block attributes. The following options were explored:

• hooking into hasActiveMetaboxes value somehow, as if this is set to true the editor save button is made active. However, giving the site options block a type of meta also automagically hooks any changes of data into saving back to post meta data, which is not what we want.

• Would be ideal if there was a hasSiteOptions flag in the editor store which could be used in conjunction with hasActiveMetaBoxes to help indicate need for save, but this would require changes to core gutenberg. There is a issue open related to this at Block API: Allow blocks to specify attributes that map to site options WordPress/gutenberg#2759, and a rejected PR exploring a possible approach at https://github.com/WordPress/gutenberg/pull/3112/files

It looks like the only easy way currently to indicate to the editor a need for update is using setAttributes - but using this for the actual site block data leaves the data needlessly serialised in the block page content .... so I explored the approach of instead using a generic attribute that would be shared by all FSE blocks.

I started with a simple boolean, eg. siteOption: boolean - but the setAttribute() method needs to detect that the value has changed in order to flag content as dirty - and toggling this value doesn't make sense.

Instead I tried updated: number, and set this to Date.now() with each update to the FSE block, and this seems to work, and just leaves
<!-- wp:a8c/site-description {"updated":1560830767104} /-->
serialised in the content.

With this approach each block would have attributes set as:

	attributes: {
		updated: {
			default: null,
			type: 'number',
		},
	},

The actually site specific data for the given FSE block would be handled in local component state, eg.

	state = {
		description: 'default placeholder',
	};

And the update handler would then update local component state, and run setAttribute for the updated property:

	handleUpdates(description) {
		const { setAttributes } = this.props;
		this.setState( {
			description,
		} );
		setAttributes( { updated: Date.now() } )
	}

[gwwar]

From early feedback, @apeatling noted that the extra save buttons would be too rough as a user experience. It is however super helpful to have them in the plugin as we work on a better solution. Let's get #34112 in a good state and landed into the plugin.

We can then follow up with an investigation on better long term options. It's very likely we need to add some core Gutenberg contributions. I've added an extra five points here for the second round of options.

[glendaviesnz]

Have put up a draft PR at WordPress/gutenberg#16254 of one possible approach to exposing a forceIsDirty flag in the core editor code

[glendaviesnz]

After wider discussion at at paAmJe-tF-p2 it was decided to:

• Use temporary attribute updates on the FSE blocks to indicate dirty state to the editor (Full Site Editing: Replace save buttons with temporary attribute changes [1] #34287)
• Assist where possible with the work on generalisation of custom sources in the core editor (Simplify meta attribute sources and attempt to prepare a generalization of custom sources WordPress/gutenberg#16075), and the subsequent adding of a site options source as a more permanent solution.