search

JoryHogeveen / view-admin-as

View the WordPress admin as a different role, switch between users, temporarily change your capabilities, set default screen settings for roles, manage your roles and capabilities.
https://wordpress.org/plugins/view-admin-as/
GNU General Public License v2.0
45 stars 3 forks source link

Inconsistent check to not render toolbar #88

Closed tzkmx closed 6 years ago

tzkmx commented 6 years ago

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

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.

JoryHogeveen commented 6 years ago

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?

JoryHogeveen commented 6 years ago

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

JoryHogeveen commented 6 years ago

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.

JoryHogeveen commented 6 years ago

@tzkmx Please see this commit: https://github.com/JoryHogeveen/view-admin-as/pull/78/commits/1799e1524e1cc81338a7945909c1e68a0c2ea792

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