Inconsistent check to not render toolbar

[Jesus Franco]

Expected Behavior

If I check the option "hide in customizer", then the toolbar shouldn't be rendered in any customizer view.

Actual Behavior

The toolbar its shown, but not enqueued the stylesheets. So, all the links and the toolbar are rendered but without the stylesheets and scripts, it becomes useless and polutes the customizer UI (its positioned in front of the Save/Publish/Schedule customization).

Conditions in which is observed the bug

This behaviour doesn't occur if the user accesing the customizer has the edit_theme_options.

However it happend if the user accesing the customizer has a different capability.

I've added a filter to user_has_cap used by the customize.php script to grant access to the UI, that allows the user use the panels, sections and controls granted to them role, but not to the whole set of features allowed by edit_theme_options.

Specifications

• Plugin Version: 1.7.6
• WordPress Version: 4.9.4
• Other plugins installed: Plenty, but just that filter seems to be the culprit.
• Theme: jarida
• Browser: Firefox 58 and Chrome 63

Proposed fix

I've replicated the check done in VAA_View_Admin_As_UI::enqueue_scripts to the beginning of methods VAA_View_Admin_As_Admin_Ba::__construct() and VAA_View_Admin_As_Toolbar::vaa_toolbar_init() and then the toolbar is not rendered.

[Jory Hogeveen]

Hi @tzkmx
Thanks for your bugreport, I'm trying to replicate this issue but can't really find why the styles/scripts aren't rendered.
If you user has access to VAA the UI and Toolbar are rendered on the customizer (unless turned off).

In all cases the regular admin bar or VAA toolbar would trigger the scripts to be rendered.

I've replicated the check done in VAA_View_Admin_As_UI::enqueue_scripts to the beginning of methods VAA_View_Admin_As_Admin_Ba::__construct() and VAA_View_Admin_As_Toolbar::vaa_toolbar_init() and then the toolbar is not rendered.

If you check for ! VAA_API::is_toolbar_showing() in the constructors it would always return false since the adminbar wouldn't be initialized yet at that stage. I don't think that would be the correct fix.

Is there a possibility that I can take a look at a staging version of your installation?

[Jory Hogeveen]

Oh, keep in mind though that if you have selected a view then it would always be shown on the customizer.

[Jory Hogeveen]

I've added the filter in a plugin root and now I seem to replicate the behaviour:

add_filter('user_has_cap', function($allcaps, $_, $args, $user) {
	if(in_array('customize', $args)) {//in_array('editor', $user->roles)
		return array_merge(['edit_theme_options' => true], $allcaps);
	}
	return $allcaps;
}, 13, 4);

But there is another issue. With this filter the adminbar is still shown inside the customizer preview which shouldn't happen.

[Jory Hogeveen]

@tzkmx
Please see this commit: 1799e15

I think this will fix your issue.
Keep two notes in mind:

• Please remove $this-> if you are patching to a 1.7.x version. Or update to the 1.8 branch
• It seems there is another issue with your installation that shows the adminbar on the customizer preview window. This should not happen within the customizer. The patch above will not fix this..