-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block Editor: Allow control over drop cap feature with useEditorFeature
helper
#22291
Conversation
Size Change: +52 B (0%) Total Size: 1.12 MB
ℹ️ View Unchanged
|
a9246d4
to
bcfb64f
Compare
packages/block-editor/src/components/use-editor-feature/index.js
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the idea is that typography.dropCapEnabled may be enabled globally but, for example, disable inside a specific template part.
I'm not sure if we should include __experimentalBlocksConfig and __experimentalBlocksFeatures as settings. I imagine we may have a useGlobalStyles hook that queries the endpoint we will use to save and retrieve the global style.
That hook would be contextual, e.g., it would be aware that a paragraph inside a specific template part may have typography.dropCapEnabled disable while a paragraph not nested may have it enabled.
How to contextualize the global styles is not yet decided, so I guess provided we mark reverting as experimental for now, we can keep the current approach.
We want to have a way to give users control for this feature globally and on the block level for start. It's enough to handle. The idea is to offer
For this PR, it probably makes sense to remove |
a9553e8
to
2fb9fb8
Compare
We discussed with @youknowriad that it would be nice to document the priorities:
I plan to follow @nosolosw and his work in #22518 and include a section to: |
be46697
to
68643cb
Compare
I rebased this branch with |
68643cb
to
6e1fde5
Compare
I opened #22622 that is focused on documenting all the changes proposed in this PR. |
packages/block-editor/src/components/use-editor-feature/index.js
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👋 This is me thinking out loud about how all these pieces fit together, pardon me if you already know all of this, so I have a link for future reference. For clarity, I'll use core.json
to refer to lib/experimental-default-theme.json
and theme.json
for the one provided by the theme.
So, we currently have:
-
Block settings: persisted in the
core/blocks
store. There's ablocks.registerBlockType
filter in the client to hook into this. This data comes from block.json. -
Editor settings: persisted in the
core/block-editor
store. There's ablock_editor_settings
filter in the server to hook into this. This data comes from PHP (several sources).
And we want:
-
Block settings:
- Default values for supports are taken from block.json.
- Via the
blocks.registerBlockType
client filter, we override the defaults with data taken form thecore/block-name
subtree (the result of merging core.json & theme.json). - Via the
blocks.registerBlockType
client filter third-party code can still provide further overrides.
-
Editor settings:
- Default values for editor settings taken from PHP (several sources).
- Via the
block_editor_settings
server filter, we override the defaults with data taken from theglobal
subtree (the result of merging core.json & theme.json). - Via the
block_editor_settings
server filter, third-party code can still provide further overrides.
The useEditorFeature
component merges the block & editor preferences in this way: if they exist, block settings take precedence over editor settings.
This PR implements 2.2, but we still need to implement 1.2 (it's fine if we do this in a follow-up PR).
*/ | ||
function gutenberg_experimental_get_editor_features_config() { | ||
$empty_config = array(); | ||
$config_path = __DIR__ . '/experimental-default-theme.json'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you suggested, I'm thinking that we can move the theme.json
(both core and theme) to PHP. This also solves one potential code path in which we return the empty config without any values. We can do this in a follow-up as we also have to do it for global styles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's take care of it separately. I'm still unsure whether this JSON file shouldn't be used as a default for @wordpress/block-editor
settings object:
There is also this question whether should I put some defaults there as well for features 😅
Correct.
At the moment we don't entirely implement 2.2, because In general, we need to decide separately how |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm approving this, so we can iterate on related things.
I'd still like if we could remove the extra default parameter added to useEditorFeature
. It's not necessary for this feature just yet (if we remove it, this still works as expected). Once a few of the follow-up tasks are ready I think we won't need it, and having it now makes it more difficult to remove later.
These are the follow-up tasks that I see:
- Editor Defaults: take & merge data from the
global
subtree of thetheme.json
(now it only takes core defaults). - Block Defaults: expand to this area. Ex: that a theme can disable the drop cap for the paragraph block from theme.json.
- See how we can consolidate
lib/experimental-default-theme.json
andblock-editor/src/store/defaults.js
. - Document (can happen when a few more of the above things are ready).
6e1fde5
to
00eac25
Compare
Thank you for all feedback. I will open follow-up tasks shortly.
It's partially documented in #22622 and we should continue adding new revisions as we build the whole experience. |
Filed 3 follow up tasks as suggested in #22291 (review): |
Description
Related to #21583.
So far there is one new field proposed in the editor (and block editor) settings on the client:
__experimentalFeatures
. It's exposed from the server.Usage:
The discussion about the shape of config files needs to happen first before we commit to the more solid proposal.There was a very in-depth discussion about the shape of the theme config (and the WordPress core config with defaults for themes) in this thread: #22291 (review). We didn't commit to the final shape but we have enough to continue work on this feature and similar concepts related to themes and way to have more control over the block editor.
Finally, I tried to move
supports
from the JS toblock.json
for all blocks in #22422. At the same time, I wanted to try to rename it tofeatures
but it ended up as a very deep refactoring so I took step back and figure out why not putfeatures
as a section ofsupports
that has quite good support in the codebase. Based on that idea I included block overrides for features using the following definition of the block:Open questions
There is still this remaining question whether we need to define default settings in WordPress core that can be overridden by themes on the server using JSON format. An alternative approach would be to use PHP array or move that to the client in the
getSettings
implementation.How has this been tested?
First, I ensured that drop cap functionality still works for the Paragraph block as before.
I also manually modified
dropCap
flag in Paragraph block by modifying thesupports
field to ensure it disables the feature when it is set tofalse
. I also removed the section for Paragraph block and tested that global settings toggle the features properly.Types of changes
New feature (non-breaking change which adds functionality).
Checklist: