Site Editor: Add Missing Styles #26958
Conversation
Copons
added
[Type] Bug
Copons
requested review from
mattwiebe,
oandregal,
vindl,
david-szabo97,
jeyip,
noahtallen and
Addison-Stavlo
|
Size Change: 0 B Total Size: 1.19 MB ℹ️ View Unchanged
|
There was a problem hiding this comment.
Looks good to me! Tested and it all now works as I would expect.
The only thing holding off an approval is the curiosity about "not in edit-site" comment, which I see you have ping'd @nosolosw for a response on that.
| } else { | ||
| // STEP 3 - OTHERWISE, ADD STYLES | ||
| // | ||
| // If we are in a block editor context, but not in edit-site, |
There was a problem hiding this comment.
Interesting, I wonder why "not in edit-site" and if we are missing anything? 🤔
|
👋 I've taken a look at this and want to share my thoughts. There are two issues here: Blocks that depend on the
|
|
Thanks for looking at this @nosolosw!
It's I think specific to the HTML block which loads the preview in an iframe. That iframe needs the editor styles to properly display the content, and it grabs them from If I'm understanding the code correctly, on update Global Styles directly modifies |
|
Interestingly, I just ran into this and fixed it on my end: Automattic/block-experiments#156 |
|
It seems that we have two different issues here:
#27063 attempts to remove the class from the blocks that have it, as they shouldn't depend on a specific editor selector. I'd appreciate wide testing and feedback there.
HTML preview (uses iframe) has this issue. In a conversation with @jorgefilipecosta he brought up that other blocks may have issues as well (classic, shortcode, etc). I haven't confirmed but this needs investigation. To fix this second issue we need to update how we generate the stylesheet client-side for edit-site: we need to be able to inject (and update upon user changes) our client-side generated stylesheet within the settings.styles. We also need to respect all the existing styles. I'm going to start working on this (unless someone has already started). |
|
PR for second issue at #27065 |
|
Both PRs have been merged so this should be fixed. Thanks for reporting! |
Description
.block-editorclass to the Site Editor.The Site Editor is initialized in a very different way compared to the Post Editor, and there are plenty of inconsistencies to be found.
I stumbled upon this issue when trying the HTML block in the Site Editor: its textarea didn't have any styles applied.
I then noticed that some styles depend on the
.block-editorclass, which is created by Core WordPress when renderingedit-post.edit-siteis not initialized in the same way, and didn't have that class, making a few components and blocks (e.g.PlainText) not working as intended.After fixing the plain text view of the HTML block, I also noticed that its preview was broken as well.
As it turned out, we don't add the experimental global styles to the block-editor settings in
edit-site.I'm not sure why, though, and I can't tell if I'm causing any regressions here.
Pinging @nosolosw as author of the original PR for some pointers: #24250
How has this been tested?
Screenshots
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist: