Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#48569 closed defect (bug) (wontfix)

Twenty Twenty: Theme-specific editor styles being improperly enqueued

Reported by: markjaquith's profile markjaquith 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().

https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/themes/theme-support.md

Change History (8)

This ticket was mentioned in Slack in #core-themes by hometowntrailers. View the logs.


5 years ago

#2 @SergeyBiryukov
5 years ago

  • Component changed from General to Bundled Theme
  • Milestone changed from Awaiting Review to 5.3

#3 follow-up: @joyously
5 years ago

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.

#4 @SergeyBiryukov
5 years ago

  • Milestone changed from 5.3 to 5.3.1

Moving to 5.3.1, per Twenty Twenty team.

#5 in reply to: ↑ 3 @markjaquith
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.
The add_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 @williampatton
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 @nielslange
5 years ago

  • Milestone 5.3.1 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

#8 @joyously
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.

Note: See TracTickets for help on using tickets.