Make WordPress Core

Opened 8 years ago

Last modified 3 years ago

#36778 reopened enhancement

Parent theme editor-style.css cannot be disabled

Reported by: matthewmcvickar's profile matthewmcvickar Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Editor Keywords: needs-patch
Focuses: administration Cc:


While it is possible to override the CSS in a parent theme's editor-style.css, it is not currently possible to completely disable or dequeue a parent theme's editor-style.css file.

This is a problem for a few reasons:

  • Theme authors may not keep their editor-style.css files up to date with the HTML the editor produces, leading to formatting oddities.
  • You may not just want the editor styles customized from the WP defaults at all.

Change History (12)

#1 @ocean90
8 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release
  • Type changed from defect (bug) to enhancement
  • Version trunk deleted

Hello @matthewmcvickar, welcome to our Trac!

Looks like you're requesting a function like remove_editor_style( $stylesheet ) which allows to remove a specific editor stylesheet from the global $editor_styles. Is that right?

For now you could use remove_editor_styles() which removes all stylesheets or the editor_stylesheets filter.

#2 @matthewmcvickar
8 years ago

Hello @ocean90 and thank you!

I'm afraid neither of those approaches work when I try them.

My parent theme has an editor-style.css; my child theme does not.

When I use remove_editor_styles() in the child theme, the parent theme’s editor stylesheet is still used.

Similarly, when hooking into the editor_stylesheets filter, neither unsetting the array passed into the filter nor unsetting the $GLOBALS['editor_styles'] array nor returning false has any effect—the parent theme’s editor stylesheet is still loaded.

(So far, I've gotten around this by checking if that file exists and deleting it if it does—that seems to be the only way around this that I can figure out.)

// Doesn't work.

// Doesn't work.
add_filter('editor_stylesheets', 'remove_parent_theme_editor_stylesheet');
function remove_parent_theme_editor_stylesheet($stylesheets) {
  return $stylesheets;

// Does work, but very ugly.
add_action('admin_init', 'remove_parent_theme_editor_stylesheet_file');
function remove_parent_theme_editor_stylesheet_file() {
  $parent_theme_editor_css = get_template_directory() . '/editor-style.css';
  if (file_exists($parent_theme_editor_css)) {
Last edited 8 years ago by matthewmcvickar (previous) (diff)

#3 @ocean90
8 years ago

Are you sure that you're running your code after the parent theme has registered the editor stylesheet?

Assuming that the parent theme registers the stylesheet at after_setup_theme the following should work:

add_action( 'after_setup_theme', function() {
}, 999 );

#4 follow-up: @matthewmcvickar
8 years ago

Just tested it, and that doesn't work either.

The parent theme isn't registering the stylesheet—there's just an editor-style.css there, and it's being picked up automatically (as described in add_editor_style()).

I did, however, just figure out a workaround using the mce_css hook:

add_filter('mce_css', 'remove_parent_theme_editor_stylesheet');
function remove_parent_theme_editor_stylesheet($stylesheets) {

  $stylesheets = explode(',', $stylesheets);

  foreach ($stylesheets as $key => $stylesheet) {
    if (strpos($stylesheet, get_template_directory_uri() . '/editor-style.css') !== false) {

  $stylesheets = implode(',', $stylesheets);

  return $stylesheets;
Version 0, edited 8 years ago by matthewmcvickar (next)

#5 in reply to: ↑ 4 @azaozz
8 years ago

  • Resolution set to worksforme
  • Status changed from new to closed

Replying to matthewmcvickar:

The parent theme isn't registering the stylesheet—there's just an editor-style.css in the parent theme directory

Why is there an editor-style.css file in the parent theme if it is not registered? Sounds like an error?

In any case, a stylesheet can always be removed from there with the mce_css filter. Closing as worksforme, using that filter to control which stylesheets are loaded seems sufficient for this edge case.

#6 @DrewAPicture
8 years ago

  • Milestone Future Release deleted

#7 follow-up: @eclare
7 years ago

  • Keywords 2nd-opinion added
  • Resolution worksforme deleted
  • Status changed from closed to reopened

Just wanted to add that this isn't an edge case. At my company we're estimating about 20% of themes (at least premium ones) include faulty add_editor_style() without any way of disabling it (overloading in the child theme). It's a pain for developers. That aside, I'd add the remove_editor_style() function for consistency and since the mce_css filter feels hacky.

We have dequeuing functions for scripts (styles), so it's only consistent that we add one for editor styles. Imho.

Please post a 2nd opinion.

#8 @eclare
7 years ago

Plus there's the honest case that if developers come across this issue, they'll edit the parent theme's PHP file instead of Googling around for this particular page for a solution (it's not populated on other sites). So, this issue results in parent theme code modifications, which is a serious problem.

#9 in reply to: ↑ 7 @azaozz
7 years ago

Replying to eclare:

...since the mce_css filter feels hacky.

No, it's the opposite :) mce_css is the best way to add or remove any style for the editor. This is the proper way for both themes and plugins. add_editor_style() was added later as "dumbed down hand-holding" for theme authors as apparently it is too hard for many of them to use filters... I didn't like the idea then, I dislike it even more now. As you mention lots and lots of themes use that to add all kinds of sub-standard CSS to the editor often breaking some functionality or making it behave unexpectedly.

There are several ways to remove theme added stylesheets from the editor. The most straight-forward is:

add_action( 'admin_init', 'my_remove_parent_styles' );
function my_remove_parent_styles() {
	add_editor_style( 'child-editor-style.css' );

(note that the child theme's stylesheet is called child-editor-style.css here).

If the parent theme adds several stylesheets (for example external fonts), it would be better to use mce_css and loop through them to determine which to keep.

(theme developers will) edit the parent theme's PHP file instead of Googling around for this particular page for a solution.

All serious developers would know better than editing somebody else's files. Perhaps we can add some more help to the add_editor_style() docblock (and a link to this ticket) to help them out? Patch welcome :)

Last edited 7 years ago by azaozz (previous) (diff)

#10 @eclare
7 years ago

Thanks for your fast reply :)

The issue is, even though serious developers look around for a solution, the only one is in this trac ticket. Obviously if you see add_editor_style(), you Google for remove_editor_style() and there isn't one. The next thing a developer could do is look further for a solution or edit the parent theme's code. Since this is like the only page with a proper solution, most will do the latter.

I think the minimum viable solution is to add an explanation to the Codex (or somewhere else), but I still feel strongly about consistency and ease of use. I think these few more lines of code are worth it if we stop parent theme edition on a LOT of sites.

I can see where you're coming from, but as there's already an easy way to potentially destroy the WYSIWYG editor by adding bad CSS to it, there most certainly should be an easy way to fix it if needed.

#11 @SergeyBiryukov
7 years ago

  • Milestone set to Awaiting Review

#12 @noisysocks
3 years ago

  • Keywords 2nd-opinion removed
  • Milestone changed from Awaiting Review to Future Release

I'm OK with adding a convenience remove_editor_style() function as there is demand for it, it's not much code, and it is consistent with the pairings we have elsewhere in Core (remove_action, remove_meta_box, unregister_block_type, etc.)

I get that mce_css makes it unnecessary but in my mind these sorts of filters are the "porcelain" layer of WordPress.

Note: See TracTickets for help on using tickets.