Site Editor: Ensure editor settings are populated with server-side settings ASAP#75785
Merged
Site Editor: Ensure editor settings are populated with server-side settings ASAP#75785
Conversation
Copons
added
Global Styles
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +6 B (0%) Total Size: 6.87 MB
ℹ️ View Unchanged
|
Copons
force-pushed
the
fix/disable-font-library-mobile
branch
from
7544373 to
8d89399
Compare
Contributor
|
There must be some code in place that passes the settings from "core/edit-site" store to "core/editor" store. Would be cool to find the root issue here instead of adding an adhoc fix. Like why is this not happening properly when loading the mobile route but is happening properly when loading the full site editor route. Maybe that "syncing" of setting or something need to be moved elsewhere? |
Contributor
Author
@youknowriad I'm struggling a lot to follow the flow of the code, and what should be the expected behavior, so I'm not sure where the most appropriate location for this sync could be. AFAICS it's not working because the syncing happens in the On large screens, the preview panel is always visible, so On small screens, though, the preview panel is never visible. You either see the "sidebar" (e.g. navigation or Styles panel) full screen, or the edit canvas. As long as you don't switch over to edit canvas, |
Contributor
|
Ok that makes sense, for me the issue here is that global styles UI assumes that there's an "editor" that has been rendered in the page to work properly. I've traced this down to I noticed the above component is used in three places: 1- The default global styles editor sidebar, in this case it's within the editor so it's wrapped with EditorProvider, so no problem Unfortunately, dealing with "server side editor" settings has always been an issue, we tried solving over time but the ideal solution is not there yet. For the current bug, I'm inclined to say that we should add a "settings" prop to The question then becomes how to provide the settings in there use-case mentioned above: 1- That should be as easy as For me the ideal solution here is to avoid the need for these settings that get passed top down from the server and instead use endpoints that are specific to each setting. For instance "font library enabled" seems like a "site setting" to me and not an "editor setting", so ideally it should be in the site settings endpoint... But this is a long term battle. What do you think? |
Contributor
Author
|
@youknowriad I hope I got your suggestion right in 9438db3. 😅
Its |
youknowriad
reviewed
Feb 24, 2026
youknowriad
reviewed
Feb 24, 2026
youknowriad
reviewed
Feb 24, 2026
| ); | ||
| const isMobileViewport = useViewportMatch( 'medium', '<' ); | ||
| const [ section, onChangeSection ] = useSection(); | ||
| const settings = useSelect( |
Contributor
There was a problem hiding this comment.
I think we should probably only pass what's necessary instead of the whole settings. Probably doesn't make sense for now, but maybe it makes it a little bit more clear that this shouldn't be a "dump all what you think about as a setting". Now maybe there's a another way to pass that message.
Contributor
Author
There was a problem hiding this comment.
I don't think it's strictly needed, since useServerData then picks only the relevant properties anyway.
gutenberg/packages/editor/src/components/global-styles/index.js
Lines 21 to 28 in d812b91
If we did the same here, we'd be practically duplicating that logic. 🤔
youknowriad
reviewed
Feb 24, 2026
Contributor
youknowriad
left a comment
youknowriad
left a comment
There was a problem hiding this comment.
I didn't test. Maybe @tellthemachines can help review a bit here as well. But the changes do implement exactly my suggestion. Thanks @Copons
Contributor
|
This is working well for me in testing in both the embedded styles sidebar in the and the left-hand side site editor one. In the extensible site editor experiment I see a flash of the font library when loading on mobile, but then it disappears: font-lib-flash.mp4As an aside, testing in the experiment is tricky right now because the nav seems to be broken: 
All the button links are pointing to the current page, instead of the pages they should be pointing to.
|
Contributor
This used to happen for me when I had old stuff in the |
Contributor
Author
|
Thanks for looking at this @youknowriad @tellthemachines!
|
|
Flaky tests detected in d812b91. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/22393939307
|
Copons
force-pushed
the
fix/disable-font-library-mobile
branch
from
d812b91 to
7ec390f
Compare
Contributor
Running |
Remove the direct dependency on the core/editor store from GlobalStylesUIWrapper by accepting an editorSettings prop. Each usage site now provides settings from its own context: - Editor sidebar: reads from core/editor store - Edit-site styles page: reads from edit-site store - New styles route: uses useEditorSettings from lazy-editor A fallback to the editor store is kept for backwards compatibility. Also revert the workaround of dispatching updateEditorSettings in the edit-site initializer.
Copons
force-pushed
the
fix/disable-font-library-mobile
branch
from
7ec390f to
5f76c97
Compare
Contributor
Author
|
@tellthemachines @youknowriad I'm seeing the same error in trunk, so I'd assume it's unrelated to this change. Is there anything else that's blocking this PR? |
Contributor
|
Yes, it's unrelated and we've fixed it separately now. |
youknowriad
approved these changes
Mar 4, 2026
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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?
Populate the Site Editor's editor settings with server-side settings ASAP.
Why?
This change fixes a WordPress.com issue where disabling the font library only works on large viewports.
The Site Editor renders different component trees depending on viewport size.
The styles routes, for example, render
Editoron desktop viewports as part of the preview, and on mobile when in edit canvas.Editorsyncs server side settings (I think) through its provider. But that component is not rendered when viewing the Styles panel on mobile.The font library can be disabled server side via
block_editor_settings_allfilter:When opening the Styles panel on desktop,
Editoris rendered, the server-side settings are populated, and the font library is not displayed. Resizing the viewport to a mobile size, the font library remains hidden.However, if opening the Styles panel directly on mobile,
Editoris not rendered, the server-side settings are ignored, and the font library is displayed. Then, expanding the viewport to a desktop size, theEditorkicks in, and the font library gets hidden.How?
By syncing the server-side settings during the site editor initialization, we ensure those settings are available immediately, regardless of which component tree is rendered.
I must note that I'm not entirely sure this is the right approach, and I wonder if there's a better location for the
updateEditorSettingscall.I also have concerns that this might surface other issues, similar to the font library one, that have remained concealed on mobile by not populating server-side settings.
A lighter approach could be to only populate the
fontLibraryEnabledin the Styles panel.Testing Instructions
Visualize the issue BEFORE APPLYING THIS CHANGE
Test the fix AFTER APPLYING THIS CHANGE
Screenshots or screencast
Before
Screen.Recording.2026-02-20.at.16.26.32.mov
After
Screen.Recording.2026-02-20.at.16.24.39.mov