[T RParticipant]

Hi,
Is there a way to remove the ‘Customizer’ from different roles? Particularly the Editor Role? I’m using the following php script and “Customizer” is being included and I’d rather it is not included to prevent the client from ‘messing’ around in there but still have access to the widgets and menu. How can I remove the access to Customizer?

<?php

/*
* Appearance permissions: edit Appearance menu for selected roles
*
*/

class AppearancePermissions {

// roles to which allow the Appearance menu
private $allowed_roles = array(‘editor’);
// allowed items from Appearance menu
private $allowed_items = array(
‘widgets.php’,
‘nav-menus.php’
);
// capabilities required by WordPress to access to the menu items above
private $required_capabilities = array(
‘edit_theme_options’
);

private $prohibited_items = array();

public function __construct() {

add_filter(‘user_has_cap’, array($this, ‘add_required_caps’), 10, 4);
add_action(‘admin_head’, array($this, ‘remove_appearance_menu_items’), 10);
add_action(‘admin_head’, array($this, ‘appearance_redirect’), 10);
add_action(‘wp_head’, array($this, ‘hide_admin_bar’));
}

protected function user_has_allowed_role($user) {
foreach($user->roles as $role) {
if (in_array($role, $this->allowed_roles)) {
return true;
}
}

return false;
}
// end of user_has_allowed_role()

public function add_required_caps($allcaps, $caps, $args, $user) {
if (!$this->user_has_allowed_role($user)) {
return $allcaps;
}

remove_filter(‘user_has_cap’, array($this, ‘add_required_caps’), 10, 4);
foreach($this->required_capabilities as $cap) {
if (!$user->has_cap($cap)) {
$allcaps[$cap] = true;
}
}
add_filter(‘user_has_cap’, array($this, ‘add_required_caps’), 10, 4);

return $allcaps;
}
// end of add_required_capabilities()

/**
* Hide admin front-end menu
*/
public function hide_admin_bar() {
global $current_user;
if ($this->user_has_allowed_role($current_user)) {
// block front end admin menu bar
show_admin_bar(false);
}
}
// end of hide_admin_bar()

public function remove_appearance_menu_items() {
global $current_user, $submenu;

if (!$this->user_has_allowed_role($current_user)) {
return;
}

if (!isset($submenu[‘themes.php’])) {
return;
}
// remove not allowed menu items
foreach($submenu[‘themes.php’] as $key=>$item) {
if (!in_array($item[2], $this->allowed_items)) {
$this->prohibited_items[] = $item[2];
unset($submenu[‘themes.php’][$key]);
}
}
}
// end of remove_appearance_menu_items()

public function appearance_redirect() {
global $current_user;

if (!$this->user_has_allowed_role($current_user)) {
return;
}

foreach ($this->prohibited_items as $item) {
$result = stripos($_SERVER[‘REQUEST_URI’], $item);
if ($result !== false) {
wp_redirect(get_option(‘siteurl’) . ‘/wp-admin/index.php’);
}
break;
}
}
// end of appearance_redirect()

}
// end of class AppearancePermissions()

new AppearancePermissions();

[T RParticipant]

This reply has been marked as private.

[Paul RModerator]

Hi,

Thanks for writing in! Regretfully this isn’t a feature offered by X. It could be possible with custom development, but this would be outside the scope of support we can offer. You may wish to consult a developer, or a service like WerkPress or Elto to assist you with this. X is quite extensible with child themes, so there are plenty of possibilities. Thanks for understanding. Take care!

[Rich AParticipant]

Hi TR. Thought I’d chime in. There are some WP plugins that allow you to customize the user roles. Here is one…

https://wordpress.org/plugins/user-role-editor/

I haven’t tried that particular plugin or any of the others like it so I can’t speak to how well they work. However I am considering using one on a couple of sites for just that reason…to stop well-meaning folks from getting themselves into trouble. 😉

If you decide to use one, please let us know how it goes.

Cheers!

[Paul RModerator]

Thanks for the help Rich.

[T RParticipant]

Thank you all for the help and advice. Rich, I’m actually using that plugin and it’s working out great (except for this little thing). If I can just not have the ‘Customizer’ show on the editor role, it would be exactly what I need in a nutshell; would be so helpful to keep their little fingers off of the customizer! This plugin allows for the editor to have access to ONLY the widgets and menu in the Appearance section which is very helpful, but I just can’t get the ‘customizer’ to disappear. 🙂

Thanks again for the help all!

[Rich AParticipant]

Hi TR. Always happy to help.

I did a little experimenting with User Role Editor on one of my dev sites. I created a new user role, “Admin” by duplicating the existing WP Administrator role. Then I unchecked various options until I had what I think would be a good compromise.

As you can see in this image, the settings I used eliminated the Appearance/Customizer…

So I think if you tweak things a bit (particularly editing/deleting themes options) you should be able to get the desired results.

Hope that helps!

[Rich AParticipant]

Hi TR…follow up. I see that you still want them to have access to widgets and menus. I’m guessing that’s why the customizer is still showing. Without digging into the actual WP database, I’m not sure if you can avoid that then.

You might ask the developer about it on their support page.

If you get it sorted out, let us know..that would indeed be helpful.

Cheers!

[T RParticipant]

Hi, Rich!
You are absolutely correct. I’ve played around with it and yep, it seems the ‘customizer’ is there being that it’s attached to something in the code somewhere. If I can get the correct name for it, I may be able to remove it. Not sure. I put in a question to the developer to see if he can help with it at all. The code I added in this thread actually activates the ‘edit_theme_options’ but with only the widgets and menu visible which is great, but because the ‘edit_theme_options’ is activated, it triggers the ‘customizer’ to pop up also. urghh. lol

[RadModerator]

Hi T R,

This code works on my end, you can incorporate this code at your code.

add_action('admin_init', 'remove_customizer');
function remove_customizer () {
remove_submenu_page( 'themes.php', 'customize.php?return=%2Fx%2Fwp-admin%2F' );
remove_menu_page( 'customize.php?return=%2Fx%2Fwp-admin%2F' );
}

Instead of intercepting submenu global variable, will just use wordpress builtin functions. customize.php?return=%2Fx%2Fwp-admin%2F is the exact url slug you will see on your browser address bar.

Cheers!

[T RParticipant]

Thanks! I’ve tried this and it didn’t work. I’m sure it’s something I’m doing (or not doing). I can add this to the code I have above and it work great for you? Or should I add this code you provided to another .php file for it to remove the ‘customizer’.

Sorry. Can you tell me what I’m doing wrong?

Thanks again.

[RadModerator]

Hi T R,

Yes, it works on my end.

The code I gave is enough to remove it, but it’s up to you if you will add it to your existing code. But since you need a role check, you may want to add role exception.

1. Remove all your code given above that is related to customizer. ( save a backup copy first )
2. Add this code (updated version)

class RestrictCustomizer {

		$capabilities = array();
		
		function __construct ( $capabilities ) {

			$this->capabilities = $capabilities;

			add_action('admin_init', array(&$this, 'remove_customizer_menu'));
			add_action('customize_controls_print_scripts', array(&$this, 'restrict_customizer_access') );

		}

		function is_capable () {
			foreach( $this->capabilities as $capability ) {
				if( current_user_can( $capability ) ) return true;
			}
			return false;
		}

		function remove_customizer_menu () {

			if ( !$this->is_capable() ) {
				remove_submenu_page( 'themes.php', 'customize.php?return=%2Fx%2Fwp-admin%2F' );
				remove_menu_page( 'customize.php?return=%2Fx%2Fwp-admin%2F' );
			}

		}

		function restrict_customizer_access () {
			
			if ( !$this->is_capable() ) {
				wp_die ('Ooops! You\'re not allowed to access this'); //Replace this with your redirect if you wish to.
			}

		}  

}

new RestrictCustomizer( array('manage_options') );

That should allow specific capability for accessing customizer. And you can add multiple capabilities.

new RestrictCustomizer( array('administrator', 'manage_options', 'customize') );

Why capabilities and not role? because we need to honor default permissions set by wordpress or 3rd party plugin (Role Editor). Imagine if you restrict it to admin role, but later decided to forward customization to a developer, then you will have to create another role that has admin capability. Instead of just assigning capability to existing roles.

Cheers!

[T RParticipant]

Thanks so much. I just needed to add this ‘private’ for it to work [private $capabilities = array(‘editor’);] and it does work BUT it now doesn’t allow for the Appearance: widgets and menu. So I’d have to use one or the other. When I try to incorporate the two, I’m getting an error OR it will not read the customizer code. Uggghh!

[Rich AParticipant]

[Sits back and scratches head.] Interesting…hope you find the “magic combo” to resolve this. I’m really curious now. 😉

[T RParticipant]

Ah. So I also explained this to the developer of the plugin and this is what he said:
“Yes.
Finally I got to conclusion that as script adds new user capability automatically it should block all not-allowed menu items linked to this capability automatically too. Thanks for the right suggestion. I will update code in a couple of days.”

So once I get this and it works, I will certainly share this. It is indeed a big help for a great plugin and this great theme (smile).

I will keep you posted.

Thanks all!

[Author]

Posts