#48569 closed defect (bug) (wontfix)
Twenty Twenty: Theme-specific editor styles being improperly enqueued
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 5.3 |
Component: | Bundled Theme | Keywords: | |
Focuses: | administration | Cc: |
Description
Twenty Twenty's theme-specific block editor styles (i.e. things like fonts, centering, background color, etc) are being enqueued using wp_enqueue_style()
instead of add_editor_style()
, like they were in Twenty Nineteen. This means that it is impossible to distinguish between block-specific styles and theme-specific styles.
When using Twenty Nineteen, for instance, a custom post type that does not display on the frontend and thus should not use the theme's styling, could do something like this (obviously you'd gate it with a post type check):
add_action( 'admin_init', function () { remove_editor_styles(); });
But in Twenty Twenty, this has no effect, because the theme-matching editor styles are enqueued like any other style and get mixed in with core styles and block-specific styles.
This is contrary to Gutenberg's guidelines for adding editor styles, which explicitly say to use add_editor_style()
.
Change History (8)
This ticket was mentioned in Slack in #core-themes by hometowntrailers. View the logs.
5 years ago
#2
@
5 years ago
- Component changed from General to Bundled Theme
- Milestone changed from Awaiting Review to 5.3
#5
in reply to:
↑ 3
@
5 years ago
Replying to joyously:
It's not improper. It's the theme's choice of how to do it, not the editor's choice.
Theadd_editor_style()
choice is not always compatible with the styles.
I'm not sure I understand.
Yes, Twenty Twenty has chosen to force its styles into the editor, even for non-public post types that try to opt out of editor styles by using APIs for doing so that worked for previous core-bundled themes. I'm saying that's a bad choice, because Twenty Twenty is making the invalid assumption that all instances of the block editor are intended for editing content that will display in the theme, and should thus look like the theme.
If add_editor_style()
is not able to accomplish its job of crafting front-page-matching editor styles for the block editor, then this is a much more serious problem than Twenty Twenty using the wrong API.
#6
@
5 years ago
Hey Mark,
The add_editor_style()
is used here for the classic editor only. For the block editor we use the enqueue_block_editor_assets
action and run the enqueues hooked into that. You can dequeue them with wp_dequeue_style( 'twentytwenty-block-editor-styles' );
#7
@
5 years ago
- Milestone 5.3.1 deleted
- Resolution set to wontfix
- Status changed from new to closed
Close this issue based on https://core.trac.wordpress.org/ticket/48569#comment:6.
#8
@
5 years ago
If
add_editor_style()
is not able to accomplish its job of crafting front-page-matching editor styles for the block editor, then this is a much more serious problem than Twenty Twenty using the wrong API.
There are issues already in GitHub for the problem, which is that the stylesheet is processed and the editor class name is prepended to each selector. This doesn't work for styles that are for elements that are ancestors of the editor input area, like body
or html
or :root
. It changes the specificity of the styles, making it more difficult to write the correct CSS to match the front.
It's not improper. It's the theme's choice of how to do it, not the editor's choice.
The
add_editor_style()
choice is not always compatible with the styles.