[Resolved] Adjusting Access to the Customizer and Block Editor

[Michael]

We use GeneratePress for a multisite installation at a university serving up about 320 sites. We created a Content Manager role with the Members plugin to serve alongside the Editor role to give those who were assigned these two roles enough access to allow them to add/edit content, images, local templates, etc. We’ve found that while its helped to some degree, the Appearance menu item is controlled by one toggle only. It’s either on or off. If it’s turned off our content managers cannot access menus, widgets or the customizer. If it’s turned on content managers have access to the customizer and can change the branding of the header, layout, footer, etc. So, in short, we have to give them access. This leads me to my question.

I have removed all of the GP Customizer options usingthis document using the recommended snippets plugin and it hasn’t got us all the way there. Are there any additional snippets that might help us dial down access?

Further, I’m also trying to limit these content managers from access all of the settings of the GenerateBlocks used in the new child theme we’ve designed. I came across this post which I think touched upon the same issue. Aside from custom development do you have any recommendations for what I describe?

Thanks all!

Mike

[Tom]

Hey Mike,

Are you wanting to turn off the Customizer for them completely, or only specific panels/sections within it?

As for the editor, we’re hoping to release a feature for this in GB Pro this year.

Thanks!

[Michael]

Howdy Tom,

I need my content managers to be able to access the Appearance menu item for basically the menu options. This child theme will be pretty locked down while our others we are developing will be more open.

CUSTOMIZE

• Site Identity (lock)
• Layout (lock)
• Colors (lock)
• Typography (lock)
• Background Images (lock)
• General (lock)
• Menus (leave open)
• Widgets (lock)

WIDGETS

• Header (lock)
• Footer Widget 1 (lock)
• Footer Widget 2 (lock)
• Footer Widget 3 (lock)
• Footer Widget 4 (lock)
• Footer Widget 5 (lock)
• Footer Bar (lock)
• Top Bar (lock)

Can’t wait for the GB solution! That will be a very welcome edition. Any ETA on this feature?

Thanks Tom!

[Tom]

Most of those Customizer sections should be using edit_theme_options as the capability. Do your editors have that capability somehow?

No timeline yet on GB – we’re focused on the upcoming Query Loop block for now.

[Michael]

Gotcha. You are right Tom. The native Editor role does not. I had created an additional custom role called “Content Manager” that had an additional permissions using edit_theme_options and assigned my test user both roles. The only tweak I was after was to disallow access to Widgets, Customize and Header and allowing the role to access Menus so users could add their pages, post categories, etc. to their menus. Maybe that type of granularity isn’t possible. Look forward to GB & query loop.

[Tom]

It would certainly be nice if they made it easier on us.

I did find this, which might be helpful?: https://wordpress.stackexchange.com/a/96035/197564

[Michael]

Thanks Tom! That got me way closer. For anyone who is interested I took the example you referred me to and modified it slightly so that my users who have the custom_manager role and are provided edit_theme_options permissions can only access the menu submenu from Appearance.

For anyone interested note the childthemename would need to be replaced with your own theme name.

The only issue I have now is that the code seems to deactivate my access to these submenus as well and I’m a super admin.

Thanks again Tom!

function hide_menu() {

    if (current_user_can('content_manager')) {
        remove_submenu_page( 'themes.php', 'themes.php' ); // hide the theme selection submenu
        remove_submenu_page( 'themes.php', 'widgets.php' ); // hide the widgets submenu
        remove_submenu_page( 'themes.php', 'customize.php?return=%2Fchildthemename%2Fwp-admin%2Findex.php' ); // hide the customizer submenu
		remove_submenu_page( 'themes.php', 'customize.php?return=%2Fchildthemename%2Fwp-admin%2Fnav-menus.php' ); // hide the customizer submenu on menu page
    }
}

add_action('admin_head', 'hide_menu');

[Tom]

The only issue I have now is that the code seems to deactivate my access to these submenus as well and I’m a super admin.

Hmm that’s strange. Perhaps you need to add the content_manager capabilities to the admin role?

[Michael]

Thanks Tom I’ll test it. I actually spoke a little too soon. I’m guessing access to the customizer is a little different from themes.php and widgets.php. I was able to hide both of those easy with what I posted earlier. But access or limiting access to the customizer is trickier. I’m wondering if there is a global setting to hide or turn off access.

Right now I’m removing access to customizer on each page in the admin dashboard which is really unsustainable similar to below.

remove_submenu_page( 'themes.php', 'customize.php?return=%2Fchildtheme%2Fwp-admin%2Findex.php' );
remove_submenu_page( 'themes.php', 'customize.php?return=%2Fchildtheme%2Fwp-admin%2Fnav-menus.php' );
remove_submenu_page( 'themes.php', 'customize.php?return=%2Fchildtheme%2Fwp-admin%2Fadmin.php%3Fpage%3Dtablepress' );

I know this is way out of the GP support scope so I wouldn’t want you to spend a bunch of time on it. If you happen to know the answer, great. If not, no worries.

Thanks much!

[Tom]

Hi there,

Does this not work?:

remove_submenu_page( 'themes.php', 'customize.php' );

[Michael]

Howdy. This is interesting.

When I put that code into the Code Snippets plugin and activated it, it does not work as expected. But when I put it directly into the functions.php file of my child theme, it works perfectly. It may be because I’m running a multisite. I just haven’t seen that issue come up before.

Thanks Tom!

[Tom]

Interesting, that’s good to know. Glad it’s working now! 🙂

[Author]

Posts