-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Global Styles: synchronize user CPT registration and UI visibility #35427
Merged
Merged
Changes from 2 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
4850fab
Pass the setting down
oandregal 8404a6d
Use the flag in the client to hide the GS UI
oandregal 9e5aeb5
Fix PHPDoc
oandregal 7d14040
Tie GS to the site editor being available
oandregal 239da35
Revert "Use the flag in the client to hide the GS UI"
oandregal File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,8 @@ | ||
export { default as GlobalStylesUI } from './ui'; | ||
export { useGlobalStylesReset, useStyle, useSetting } from './hooks'; | ||
export { | ||
useGlobalStylesIsEnabled, | ||
useGlobalStylesReset, | ||
useStyle, | ||
useSetting, | ||
} from './hooks'; | ||
export { useGlobalStylesOutput } from './use-global-styles-output'; |
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
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.
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 where we decide under which conditions the UI and the user CPT are available.
At #34885 (comment) I argued that I lean towards only enable them when the user has a
theme.json
, otherwise, we don't know whether the user styles are going to play well with the theme's. Riad brought up we should open this up for themes that have block templates but don't havetheme.json
as well.As long as both places use the same logic, I'm not strongly opinionated. I went here with the current logic of the UI.
If we go with theme.json or block templates, I do wonder where's the logic we use to decide whether the edit-site is available. Shouldn't we tie this into that?
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've just checked and we don't load the site editor if the theme does not support block templates. So, if we want to update the logic, block templates are the only thing that matters to this as well.
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.
Should it be be
gutenberg_supports_block_templates
orgutenberg_is_fse_theme
. Meaning should classic themes that support block templates allowed to have global styles? Leaning towards no but curious what you think.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.
We enable the site editor only for themes that actually have templates (
gutenberg_is_fse_theme
), so this should be enough of a check to enable GS as well. As a curiosity, support forblock-templates
is added by us if the theme has atheme.json
, so it's a redundant if we already checked for theme.json support.However, note that this starts to get convoluted when/if we want embed GS in other screens (template or post editor). It's a lot simpler (and safer in terms of styling, in my view) if we only enable GS for themes with
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.
Ok, I pushed changes to make global styles (UI+CPT) use the same check than the site editor.
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.
Ok so as it stands, this PR means Global Styles UI is only for FSE themes right? Meaning a classic theme with theme.json won't have access to it (if we potentially move the global styles UI elsewhere, say to the post editor or the customizer). That's fine by me for now but it also make me wonder why we need the check in the frontend since basically the site editor is not rendered in the exact same conditions.
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.
Oh I just noticed that you removed the frontend checks nevermind
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.
Right. To confirm: both site editor & GS are now shown under the same conditions with this PR (
gutenberg_is_fse_theme
).