Allow pre-publish sidebar to be forcibly shown or hidden

[ethitter]

Description

The pre-publish sidebar provides a valuable, dedicated place to present
one-time information to users ahead of publishing an item, but its value is
limited if its use cannot be relied on. For example, if a pre-publish checklist
is implemented in the pre-publish sidebar, the sidebar should always be enabled
otherwise an author may miss important notifications.

Without this filter, the pre-publish sidebar can only be forcibly enabled using
a subscribe callback to override the user's selection, an approach that
raises performance concerns. In basic testing, the subscribe callback fired
approximately 80 times to ready the editor, compared with one or two times
for the filter callback.

How has this been tested?

Testing was performed by adding the following snippet to a script enqueued for
the editor. I then attempted to change the display setting for the pre-publish
sidebar, both in the sidebar itself and through Gutenberg's Preferences modal,
and confirmed that the filter's value took precedence.

import { addFilter } from '@wordpress/hooks';

addFilter(
	'editor.userPreferences.isPublishSidebarEnabled',
	'ethitter-force-enable-publish-sidebar',
	() => true
);

Types of changes

Adds a filter to override a user setting without the use of a subscribe callback.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @ethitter! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[talldan]

Thanks for the pull request.

For example, if a pre-publish checklist is implemented in the pre-publish sidebar, the sidebar should always be enabled otherwise an author may miss important notifications.

Are we just talking about when the user toggles it off? That introduces a more subjective question of whether the user's selection should be overridden in such a manner. Won't it be confusing for users that they can turn this option off, but it has no effect? What's the ideal user experience?

In terms of the implementation, I'd have concerns over the correctness of implementing a filter in a selector. Thinking more about the general pattern rather than this specific use case, a selector will only run if a component uses it, so it seems a dangerous pattern to start. If every component stops using a selector the filter becomes worthless and won't ever run. If a separate selector is written that pulls from the same or related store state there's then a question of whether the filter should be honoured, and that becomes a grey area.

So I don't think this is a pattern that should be introduced. It'd be good to think about what alternatives are and whether this might be a good user experience.

[ethitter]

Are we just talking about when the user toggles it off?

Not exactly, at least not for the use case that led me to create this PR. In my case, I'm porting a feature from a Classic Editor experience into Gutenberg. The feature in question includes certain warnings that the user must accept before an item can be published (or updated, if already published). In the Classic Editor, we were able to bind to the publish button to trigger our warnings, but since Gutenberg does not fire a cancellable event when the publish/update button is clicked, and to improve the user experience, we've opted to move the warnings into the pre-publish panel and to lock publishing until the user accepts the notices. If we can't rely on the pre-publish panel's presence, it loses its value and we'll have to change how we handle notifications that the user is required to accept, but that aren't required to be so intrusive that we interrupt their workflow.

In terms of the implementation, I'd have concerns over the correctness of implementing a filter in a selector.

I opted to put the filter in the selector after reading the Redux doc on derived data: https://redux.js.org/recipes/computing-derived-data; as I understood it, the selector was the Redux-appropriate place for the filter. That said, the selector also appears to be the only place where a filter can be introduced currently, on account of the default preference that the selector falls back to.

Thinking more about the general pattern rather than this specific use case, a selector will only run if a component uses it, so it seems a dangerous pattern to start. If every component stops using a selector the filter becomes worthless and won't ever run.

In this case, the filter is added in a function that, as far as I know, represents the only way to check whether or not the pre-publish panel is enabled, so I'm not sure if this concern applies. If a component was refactored to reference state.preferences directly instead of using the isPublishSidebarEnabled() selector, this would represent a regression since the default preferences would be ignored. In other words, without refactoring how default preferences are applied, I'm unaware of any other place where this filter could be added.

[ethitter]

@talldan Any thoughts on my comment? I'm curious if I should continue with this PR, or if I have to live with the overhead of the subscribe callback.

[Mamaduka]

I think this was resolved in recent WP versions. Ref: #64198.

Dev Note: https://make.wordpress.org/core/2024/10/20/miscellaneous-block-editor-changes-in-wordpress-6-7/#new-filters-to-customize-and-extend-behavior-of-post-save.

I'm going to close the PR. If new hooks need improvements, let's create a separate issue.

P.S. There's also a plugin by Human Made that intercepts and saves based on requirements - https://github.com/humanmade/publication-checklist.