Add parameter to add_editor_style() to determine for which editor the styles are loaded

[Azragh]

What problem does this address?

Currently I use the function add_editor_style() exclusively to load the styles for tinymce. Styles for Gutenberg are added via enqueue_block_editor_assets() so that I can use both editors and make individual adjustments. Due to the different structure of the content, this is unavoidable if you want to support both. If I add add_theme_support('editor-styles'), my tinymce.css is also loaded in Gutenberg, which I actually don't want.

I came across the problem because with my themes the HTML previews don't work properly - they are only displayed in the browser default. Open issue here: #9129

» According to this thread, you should be able to fix the problem by using the add_editor_style() function to provide Gutenberg styles too. I tried to change my themes according to the instructions there, but it didn't help. Apart from now having my tinymce.css in Gutenberg too, nothing has changed. The HTML preview is still not displayed in my theme styles (but that is not the point here).

What is your proposed solution?

My idea would be to add an additional parameter to the function add_editor_style(), where you can specify for which editor the corresponding files are loaded. Or maybe a new function like add_tinymce_style(), which doesn't get influenced by Gutenberg? Something like this would make it easier for theme developers to upgrade old themes for gutenberg, but keep backwards compability. Because like this you can simply leave the old editor styles (which are likely to contain selectors like body#tinymce to overwrite font-sizes and stuff) and create/compile a new file for Gutenbergs backend.

At the moment I have two files that control the editor functions. One is a tinymce_setup.php and the other is gutenberg_setup.php. When I create a classic theme, I simply do without loading gutenberg_setup.php, so all settings jump back to standard/classic. If I could now call add_editor_style() in both files, but only one specific, it would be great. At the moment, I can only solve the whole thing by not calling add_theme_support('editor_styles') at all and using add_block_editor_assets() for Gutenbergs backend instead.

[annezazu]

@oandregal perhaps you might have some thoughts here?

[pjoulot]

I kind of agree, loading styles for the block previews and for the rich text editor should not be coupled. It sounds like a conception error to me.
I encountered the same problem, and I actually had a hard time to find out that you have to use add_editor_style to fix the previews since for me "add_editor_style" was tinymce and I didn't even think about that it could be the same function to add styles in previews and the rich text editor.

[ellatrix]

The TinyMCE/Classic editors have a class mce-content-body, so you can wrap selectors with .mce-content-body. Similarly, the block editor has the editor-styles-wrapper class. I believe that's enough to work with? I don't think we'd want to add a new API.

[Azragh]

@ellatrix This is what I did finally, I'm just not really happy with it. When I now decide to configure a classic theme, I have to edit three files instead of just comment out one single line of code, this was my point. But yeah let's leave it as it is I got used to it.

[ellatrix]

Why do you need to edit three files? Can't you use the same file and use those classes when you need to tweak something for a specific editor?

[Azragh]

@ellatrix My previous setup was such that I could place all gutenberg relevant settings in a file "gutenberg_setup.php". The practical thing about this was that if I commented out the line that included the file in functions.php, I only had to install the classic editor plugin so that gutenberg and all its styles would disappear completely from the website.

Today I would have to comment out the settings file, delete the theme.json and then comment out the gutenberg styles in 2 of my scss files. But as I mentioned, this is now completely irrelevant, as the introduction of the theme.json has completely thrown my concept out of kilter anyways.