refactor: Avoid private useBlockEditorSettings API #108
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `useBlockEditorSettings` function is not exported, even as a private API. Using it is brittle, at best, and the approach is not possible when sourcing WordPress package scripts from remote sites. These changes still patch the `@wordpress/block-editor` package to (1) allow the "quick inserter" to open the primary inserter and (2) enable the Media tab in the inserter. Long-term, we should remove these patches and replace them with changes to core.
When a post object is unavailable, we must ensure the raw title and content fields have fallback values. Otherwise, the host bridge logic throws while referencing values on an undefined object.
Now that we rely upon `EditorProvider` over `BlockEditorProvider`, we can no longer configure the former with the `hasFixedToolbar` prop. Instead, we must rely upon the preference store configuration.
We now render `EditorProvider` rather than `BlockEditorProvider`, so we no longer configure the latter with explicit settings. We also do not have explicit settings we need to pass to the former, so we pass an empty object to avoid exceptions from referencing values on an undefined object.
dcalhoun
added
the
[Type] Task
dcalhoun
commented
Mar 5, 2025
Comment on lines
+21
to
+22
| - stripExperimentalSettings: true, | ||
| + stripExperimentalSettings: false, |
There was a problem hiding this comment.
Patch manually enables populating the Patterns and Media tabs within the inserter. As outlined in the PR description, this is a workaround that works for the local editor, but not the remote editor.
Ideally, we seek the Gutenberg project exposing the APIs we need to avoid this patch.
Comment on lines
+43
to
+45
| preferenceDispatch.setDefaults( 'core', { | ||
| fixedToolbar: true, | ||
| } ); |
There was a problem hiding this comment.
Since we can no longer set hasFixedToolbar on the BlockEditorProvider, we must rely upon the preferences store.
Comment on lines
+181
to
+182
| title: { raw: '' }, | ||
| content: { raw: '' }, |
There was a problem hiding this comment.
Ensures draft posts do not throw exceptions when referencing values on undefined objects—this only occurred in development environments.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Remove use of
@wordpress/block-editor's private, non-exporteduseBlockEditorSettingsfunction. This reintroduces changes originally implemented in #24, but extended to address a disappearing block toolbar and empty Patterns/Media inserter tabs—effectively reverting #50.Why?
First, using private APIs is inadvisable and not a sound, long-term solution.
Second, we were actually patching
@wordpress/block-editorto exportuseBlockEditorSettingsas a private API. While patching "works" for the editor bundled with the app, we cannot patch the "remote" editor—i.e., one that relies upon WordPress packages sourced from a user's site.How?
First, remove the
@wordpress/block-editorpatch.Second, we now rely upon
@wordpress/editor'sEditorProviderrather than@wordpress/block-editor'sBlockEditorProvider. The positive is that this approach negates our need to accessuseBlockEditorSettingsas its usage is now managed by theEditorProvider. The negative is that theEditorProviderstrips other experimental features—e.g., populating content for the Patterns/Media inserter tabs—by default, which leads to the final change...Lastly, we introduce a
@wordpress/block-editorpatch disablingstripExperimentalSettings. This means the Patterns/Media tabs now function as desired in the bundled editor. As noted previously, this patch cannot be applied to the remote editor, meaning the tabs do not populate in that environment.We are trading one patch for another, but the outcome is the remote editor, at least, functions, albeit without a few features requiring patches.
Testing Instructions
Tip
Installable prototypes are available for testing:
1 - Formatting options remain present within the block toolbar
options—e.g., bold, italic, etc.
2 - The Patterns/Media tab populate with content from the current site
Accessibility Testing Instructions
N/A, no user-facing changes.
Screenshots or screencast
N/A, no user-facing changes.