How to remove the customizer CSS option

Now that WordPress 4.7 has been released, most people will notice an “Additional CSS” section in the customizer when they update. This is an awesome feature and a perfect use of the customizer. It’ll be great for the vast numbers of users who just need to add some basic CSS to customize their theme.

However, for many of us, it’s an unwanted feature on our own sites for one reason or another. This tutorial is going to walk you through disabling this feature based on your situation.

Remove directly from customizer

If you just want to get rid of the custom CSS option altogether, the easiest route is to simply remove the control from the customizer. Dropping the following code in your theme’s functions.php or a plugin will handle that fine.

add_action( 'customize_register', 'jt_customize_register' );

function jt_customize_register( $wp_customize ) {

	$wp_customize->remove_control( 'custom_css' );
}

You can also remove the entire section (which won’t show if there are no controls) using the following line of code. However, that may have the unwanted consequences of hiding controls that other plugins/themes have added.

$wp_customize->remove_section( 'custom_css' );

Removing permission

Screenshot of the unfiltered_html capability in the Members plugin

For clients who shouldn’t be editing code, you may already have this set up using a role/cap plugin.

WordPress introduced a new meta capability called edit_css. It is checked before showing the control. This new meta cap is mapped to the unfiltered_html capability. What this means is that users without the unfiltered_html cap won’t see the control in the customizer anyway.

If you have a client who shouldn’t be editing advanced code, it’s best to take that option away by removing the unfiltered_html capability. This will also likely help in any similar scenarios in the future.

To do this, you can grab a copy of my Members plugin and uncheck the unfiltered_html checkbox for the user’s role (see screenshot above).

Customizing permission

There are some scenarios where you might want to allow the user to have the unfiltered_html cap but not be able to edit CSS. This is best handled with a filter on the map_meta_cap filter hook. What you can do is “map” the edit_css meta cap to another capability or set of capabilities.

The following code will disable the capability for everyone by mapping it to the do_not_allow capability. Place the following in a custom plugin file.

add_filter( 'map_meta_cap', 'jt_map_meta_cap', 10, 3 );

function jt_map_meta_cap( $caps, $cap, $user_id ) {

	if ( 'edit_css' === $cap ) {
		$caps = array( 'do_not_allow' );
	}

	return $caps;
}

You can take that further by utilizing the $user_id variable. Or, you can change do_not_allow to a custom capability you’ve set up (the Members plugin allows you to do this). You can even add multiple capabilities as a requirement for editing CSS. Really, the sky is the limit.