Pre-publish Checkup Extensibility - add a publish/update conditional

[adamsilverstein]

Overview

Improve the extensibility of the publish flow by letting developers control whether a post can be published or updated (with a "pre-flight" conditional).

Background

Our extensibility roadmap includes support for a pre-publish checkup: #3330

In this PR we added slot fills for developers to add information to the pre/post publish panels: #3330

Use case

In our case we would like a pre-publish checklist that requires completion before the post can be published or updated. This is a fairly common use case that is straightforward to implement in the classic editor.

In our case we are verifying that no insecure elements are in the post content. Other common use cases I have seen include required a minimum title length, requiring a featured image, disallowing certain types of content, or just requiring that editors confirm their piece meets a series of guidelines by checking a series of checkboxes.

Solution

The simplest solution I can imagine would be to apply filtering to a new selector like postPassesPreflight that works in a similar fashion to isEditedPostSavable would control the publish/update button state... plugins could then use the filter to control whether the publish/update button is active or disabled. Another less optimal option would be to provide actions plugins could dispatch to enable/disable publishing. Filtering seems more predictable, especially when multiple plugins may be involved in the logic chain.

UI/Design Review.

We already have a good UI for indicating when a post can or can't be published, however in this case we want the first publish button to work, and the second (inner pane) publish button to be enabled/disabled based on the pre-flight logic

[aduth]

postPassesPreflight that works in a similar fashion to isEditedPostSavable

Can you explain why they should not be considered one and the same? Why would we want "passes pre flight" to be conceptually different than "savable" ? Seems an unnecessary introduction of implementation details which is better served by a strict definition of what is a valid post, which should be maintained over the lifetime of the application, not specific snapshots in time.

[adamsilverstein]

postPassesPreflight that works in a similar fashion to isEditedPostSavable

Can you explain why they should not be considered one and the same?

@aduth What we really want to control is whether a post is publishable (isPublishable?) which is slightly different than if a post is savable:

Currently if a post is not isEditedPostSavable you can't reach the post publish pane where the preflight list would appear, we only want the second of the two Publish button disabled until the preflight conditions are met.

In addition, we may want different capabilities for the Update action verses the publish action - currently isEditedPostSavable controls both publish and update buttons (although with the context here a filter might be fine).

On a related note - I noticed that the update button doesn't have a clear preflight area to show warnings and provide a potential 'update anyway' checkbox. is this something we want to consider adding? Our use case is warning users about insecure content added to an https only website before they update the post (and preventing that action until they correct the content or explicitly opt in to the insecure content)

Is there a way currently for plugins to adjust the behavior of core selectors, for example the value returned from isEditedPostSavable? What do you think of using a filter approach?

[paaljoachim]

I will just link in the Publishing Flow accessibility issue in regards to the publish button:
#4187

[karmatosed]

We already have a good UI for indicating when a post can or can't be published, however in this case we want the first publish button to work, and the second (inner pane) publish button to be enabled/disabled based on the pre-flight logic

Apologies for checking but what design review are you looking for here?

[adamsilverstein]

Apologies for checking but what design review are you looking for here?

No worries I know you are busy! so for draft posts, we have a state that indicates the publish process cannot start, eg when all fields are blank:

In this PR, I am aiming to add some pre-publishing checks to ensure the post can be published, it would looks something like this:

In the pre-publish box, the user is prompted to confirm that they really wish to publish the post:

Ideally I would like to add a list of conditions that the user has to fulfil (or check a box to override) before they are able to publish.

Design goals:

• A disabled state - the publish button in this panel should be disabled until the preflight conditions are met or a the checkbox checked
• some indication of why the publish button is disabled (tooltip/alt text?)

Also important to note that we need A11y for the state: speak why the button is disabled

Technically we can use a slot fill to add the information and perhaps a filter to add the selector conditional so plugins can "disable" the button. from a design/UX perspective I would appreciate feedback about how these should be reflected in the UI.

In addition, we would ideally like to add a similar checklist for updating a previously published post. I'd love some design feedback around:

• Where should we place preflight information for a published post update? Once published there is no longer a pre-flight panel:

Thanks!

[karmatosed]

Visually just to contextualise I see something like this in publishing.

What about hooking into update though in similar way?

By hooking again into the sidebar flow you get the benefit of using the same pattern.

Let me know if that doesn't answer though.

[adamsilverstein]

@karmatosed Thanks, that is very helpful. I will work on exploring this approach.

[ayebare]

I am working on a project where the client needs the featured image to be set as a precondition for publishing. This filter will come in really handy.
any progress on it?

[adamsilverstein]

Related: #16249 which adds the ability to lock (prevent) post autosaving.