Handle Gutenberg Updates Live

[mikeselander]

Currently, the publishing checklist uses the backend as the source of truth for updates to the publishing checklist. However, this has severe limitations and breaks expectations in Gutenberg.

To get proper updates based on live data that the editor has currently entered, you have to either completely duplicate the logic from PHP in React, or the editor has to "Save Draft" before they can see the checklist update. This is problematic in multiple ways:

1. this is incredibly counter-intuitive for a user. Everything else inside Gutenberg updates and displays according to the currently-edited value. Publishing Checklist is important for seeing live updates to the logic and there is a dis-coungruity between having to save to see updates and the rest of the editor.
2. Developers have to duplicate their logic in Gutenberg that they've already written in PHP. This causes extra and unnecessary work to get this to work properly.
3. The publishing checklist will more often be out-of-sync with a post than in-sync with it, which reduces it's utility dramatically.

I propose that the plugin should use live, edited data as the source of truth. This could mean writing the checks in React, or it could mean sending out for updated data from PHP whenever the Publish panel is open.

[mikeselander]

@rmccue, @roborourke and I discussed potential options for this today and the conversation can be found here: https://hmn.slack.com/archives/C3CKS8LLR/p1591113944421600 (for internal HM folks)

For this feature, we have two options:

1. Expedient option: trigger and autosave whenever the PostPrePublishPanel is opened. This is the easiest option and most likely to get implemented soon.
2. Create a new checks REST endpoint that accepts all most Edited* data and receives back the check status that is triggered when the PostPrePublishPanel. This option is more complex, but has the benefit of not creating autosaves whenever the panel is opened.

[roborourke]

For option 1. can you have the panel open while making changes that could cause it to need to update?

If so then 1. is a non starter and we should aim for option 2 directly.

[mikeselander]

Ah, fair point @roborourke - you can make edits while the PrePublishPanel is open.

[goldenapples]

Short of live-polling the check status REST endpoint while the PrePublishPanel is open or subscribing to every post data update in the editor, there's no way to accurately reflect all possible updates made while this panel is open, so unless I'm missing something here, option 2 runs into the same problems as 1.

I don't see a simple solution for this, but maybe a way for checks to register the object in the content model they want to subscribe to changes on, and running a debounced REST call whenever that changes, could be a solution?

[igmoweb]

I also see the same issue with 1 and 2: You can edit the post during post saving or fetching the REST endpoint for the checks so the status could change.

Option 1 (Save draft automatically)

I believe that option 1 is the easiest as saving the post is quite easy with dispatch and this function: https://github.com/WordPress/gutenberg/blob/95e4f3f06a449b9f8dd44654b5f9443c465ba354/packages/editor/src/store/actions.js#L231. The problem is that we are enforcing an action that should be controlled by the user (saving drafts).
In anycase, the checklist could work as it follows:

1. The publication checklist opens
2. Save the draft
3. If altis.publication-checklist.block_on_failing is true, then disable publishing in the meanwhile.
4. Checks are updated.

Option 2 (REST Endpoint)

Ideally, we would want to subscribe to changes in certain fields like @goldenapples said instead of relying on the panel opening. This would add a benefit: When the panel opens, the checks could have been already been checked.

This change would involve:

• A new JS API creation: If we are trying to keep everything in the server, we may want to avoid as much JS as we can.
• Or a new field in PHP when registering a check. For instance:

PublicationChecklist\register_prepublish_check( 'article-type', [
		'type' => 'article',
		'run_check' => function ( array $post, array $meta, array $terms ) : PublicationChecklist\Status {
			...
		},
                'fields' => [ 'category', 'meta.my_meta_key', 'content' ]
	] );

This way, the check could subscribe to changes to those fields and as soon as they change and could fetch the REST API endpoint for checks.

The hardest part with this option would be sending the data to the endpoint. savePost dispatch function, which is the function that saves a draft and the one that we would want to get the code from in order to generate the changes. We want to send the post data as similar as Gutenberg does when saving a draft so we would need to mimic those transformations too.

Some considerations would involve to debounce the fetch so it's not triggered after every key stroke.

Option 3 (JS API)

There's another alternative: Allow developers to duplicate logic in JS by letting them to update live the checks. We did something like this in The Sun. Developers could even choose to pass a run_check in PHP when registering the check or not or do everything from JS or a combinations of two.

I don't think this is a bad thing per se if it's well documented and it adds a lot of flexibility.

[zsheaib]

are you guys still working on this? or should we find a workaround?