Add initial support for themes to control the editor #24275
Conversation
oandregal
added
[Feature] Themes
|
Size Change: -266 B (0%) Total Size: 1.16 MB
ℹ️ View Unchanged
|
| return array(); | ||
| } | ||
|
|
||
| return $config['global']['features']; |
There was a problem hiding this comment.
I don't really think we should pass just the "global" features to the editor, we should pass all the features config (per block as well) and handle it in useFeature properly.
There was a problem hiding this comment.
Yup, that's my next step.
|
Wow!! What a coincidence! I was looking for a solution to pass the styles of the theme to the Editor in the best possible way. The strategy I have pursued is very rude, as it hurts an override in several classes of the native blocks, so that they come in harmony with the theme of the site and with the blocks themselves. This is bad because many updates come out and I can't keep up with the changes very well. In addition Editor's UI element as the floating controls are affected by the theme style, leaving them buggy. Congratulations @nosolosw for the initiative! If we can soon temify the styles of the blocks to conform to the themes and deliver a more faithful experience to the published content, it will be incredible! Thank you very much in advance! |
|
Ah! One more thing: Currently, without this implementation, what would be the least rude strategy for overwriting block styles to conform to the theme's styles? |
Hey @AdsonCicilioti We have a few options, depending on your needs. There's some theme supports, there's the ability to register new styles per block, there's block patterns, etc. From a theme perspective, CSS specificity wars is one of the issues we hope this approach would fix, but it's also one that's quite difficult to talk about without a specific use case. Do you have one in mind? Is there an issue you're facing that you'd like to report? |
|
Hello @nosolosw .. Thanks for your reply ... I'm trying to be as deconstructive as possible. I'm enabled in the editor's style and and using the editor's blocks to compose the content of my pages and posts, when I need to give visual conformity / harmony between the block elements and the theme elements, I use the CSS of my theme, which is loaded after the Block Editor Style. That way I can overwrite what I need to give the harmony. The things I'm using to harmonize with my theme are:
The big problem as I see it is part of my css that takes care of overwriting some styles, it’s getting too big, not to mention that I’m carrying the common style of the blocks to the frontend plus the theme style with various properties that overwrite the styles of blocks. I'm about to copy the common styles for my CSS files, modify them as needed, and disable it in the frontend. The problem is that over time these common editor styles will change. I do not want to resort to the creation of blocks, that are very similar to the Editor's and that already serve me in their structure. I will create new blocks, yes, but different blocks. It is inconsistent to recreate what already exists. I really intend to fully explore the editor and its blocks, but it would be amazing if there was a better way to overwrite the styles. |
Fixes #22655
Follows-up #22291
Related #20588
This PR adds support for themes to control the editor via the
globalcontext.It also merges the content of
editor-features.phpwithinglobal-styles.php, improving the performance as a result of having only one filesystem access to the same file by request.How to test
settings.__experimentalFeatures.typography.dropCapat theblock-editorstore isfalse.lib/experimental-theme.jsonand set the dropcap value totrue=> verify the value istruein the store.falsein the theme'sexperimental-theme.jsonfile => verify the value is false in the store.