WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 2 years ago

#32772 closed enhancement (invalid)

Filter for disabling Customizer

Reported by: hereswhatidid Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.3
Component: Customize Keywords:
Focuses: administration Cc:

Description

This filter gives developers a simple way to enable the 'no-customizer-support' class within the body tag. Due to the fact that the 'customizer-support' class is added via JavaScript on page render, it cannot be manipulated using any core filters or actions currently.

By setting the filter value to false, the Customizer is essentially hidden from the admin and the links that were currently pointing at the Customizer (widgets, themes, etc...) are reverted to their previous dashboard destinations.

Currently, disabling and reverting the Customizer requires any number of different methods ranging from CSS overrides to hide the Customizer menus, manually removing specific menu items (https://wordpress.org/support/topic/remove-customize-from-admin-menu?replies=5), or using JavaScript to target and hide the Customizer-specific items.

This filter makes this process in to a simple boolean filter so that developers who do not want or need the Customizer can easily remove it.

Attachments (1)

32772.patch (1.6 KB) - added by hereswhatidid 4 years ago.

Download all attachments as: .zip

Change History (11)

@hereswhatidid
4 years ago

#1 @dd32
4 years ago

Personally as much as I don't use the customizer a lot of the time, I think offering a filter to disable it is probably not in the best interests of WordPress users.

The customizer, as much as some dislike it, is a major component of the future of WordPress UX - whether that is a good or bad thing remains to be seen by some - but like it or hate it, it's here.

For the record though, I think a better way to disable it is to simply remove the customize capability from the roles, or on-the-fly.

#2 @hereswhatidid
4 years ago

I was attempting to follow the precedent established by the Admin Bar which I would consider a similar type of UX component. The Admin Bar can be disabled not only by a filter but by a global variable, core function, and user profile setting. The Customizer has none of these options.

#3 follow-up: @celloexpressions
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

I have yet to see a valid reason for something like this. In most cases, concerns about not wanting users to have access to the Customizer stem from the fact that you're not giving them the appropriate capabilities. And the customize capability can be used to turn off the Customizer if you really must.

If you don't want users to have access to editing visual settings like colors, widgets, or menus, remove the edit_theme_options capability from the relevant user roles (potentially including administrators). Same goes for switch_themes and if you really want to lock things down on a client site, give them editor user accounts. customize is currently mapped to edit_theme_options by default, but that can be changed by plugins or core in the future. But on these sorts of sites, you probably shouldn't be building/using themes with options that you want to restrict your users from accessing in the first place.

Note that widgets and menus have been proposed to get their own discrete capabilities in #29213 and #31020.

While you can remove the customize meta capability (or re-map it or whatever), doing so simply because you don't want to train users or don't want to use the Customizer is doing yourself and your users an enormous disservice. As dd32 mentioned, the Customizer will only continue to grow in importance within WordPress. Additionally, user testing has shown that the Customizer experience is generally easier for users to grasp than the admin, which largely stems from the value of having live-previewing available. We're putting a significant amount of time into the Customizer every release to continue improving it, conducting frequent user tests along the way to optimize usability.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


4 years ago

#5 follow-up: @hereswhatidid
4 years ago

Well, I guess you know my clients needs better than I. Thanks for setting me straight.

#6 in reply to: ↑ 5 ; follow-ups: @Viper007Bond
4 years ago

Replying to hereswhatidid:

Well, I guess you know my clients needs better than I. Thanks for setting me straight.

As @celloexpressions explained, if you really do want to disable it, then you can disable it, but via a method that makes sense: capabilities. You're wanting to prevent user X from doing action Y which is exactly what capabilities, not filters, are designed for.

And modifying capabilities is not difficult (and there might even be a better way than this):

add_filter( 'user_has_cap' , function( $allcaps ) {
	unset( $allcaps['edit_theme_options'] );
	return $allcaps;
} );

The admin bar is different in that it's a feature and not a tool. The context "can user X use the admin toolbar" doesn't make as much sense as "should the toolbar be enabled".

#7 in reply to: ↑ 6 @andreasnrb
4 years ago

Replying to Viper007Bond:

Replying to hereswhatidid:

Well, I guess you know my clients needs better than I. Thanks for setting me straight.

As @celloexpressions explained, if you really do want to disable it, then you can disable it, but via a method that makes sense: capabilities. You're wanting to prevent user X from doing action Y which is exactly what capabilities, not filters, are designed for.

And modifying capabilities is not difficult (and there might even be a better way than this):

add_filter( 'user_has_cap' , function( $allcaps ) {
	unset( $allcaps['edit_theme_options'] );
	return $allcaps;
} );

The admin bar is different in that it's a feature and not a tool. The context "can user X use the admin toolbar" doesn't make as much sense as "should the toolbar be enabled".

WordPress is the tool the Customizer is just a feature, same as the admin bar. Both admin bar and customizer is about making it easier(although the opinion on that differs greatly) for endusers to do things. Manipulating capabilities on a per user basis is just weird. Being able to turn parts of WP off completly with an on off switch is much more sensible.

#8 in reply to: ↑ 3 ; follow-up: @helen
4 years ago

The comparison between the customizer and toolbar is interesting. The toolbar's content is determined by various capabilities, and contains some critical things like the log out link, which is why it can only be turned off for the front end. In that way, its existence is not tied to a capability of its own, so a filter makes sense. I wish we didn't have a UI setting for turning it off per user, but I recall the passionate reaction that led there.

The customizer similarly has its content determined by capabilities, but is also in itself an editing tool. What I think is odd here, no matter the method of turning it off, is that you end up with users who are empowered to do X but not allowed to have a live preview mechanism for X. This is probably okay when your users only use WP in a single context, but I think today we're in a place where people are experiencing WP on more than one site, and changing that availability, shifting contents and all, is a bit of a disservice when it comes to the bigger picture. I'm not inherently opposed to somebody not wanting to use the customizer on a personal level - I certainly find it annoying in some workflows - but providing a filter for this purpose is in essence endorsing disabling our current live preview mechanism. That is not something I can globally get behind. Still a wontfix for me, but better to document and discuss.


Replying to celloexpressions:

I have yet to see a valid reason for something like this.

While you can remove the customize meta capability (or re-map it or whatever), doing so simply because you don't want to train users or don't want to use the Customizer is doing yourself and your users an enormous disservice.

We are not omniscient, and even if your final opinion ends up being the same, your process in getting there matters much more. By all means, think this way if you must, but keep it to yourself if you can't also listen without jumping to defense.

#9 in reply to: ↑ 8 @hereswhatidid
4 years ago

Replying to helen:

The comparison between the customizer and toolbar is interesting. The toolbar's content is determined by various capabilities, and contains some critical things like the log out link, which is why it can only be turned off for the front end. In that way, its existence is not tied to a capability of its own, so a filter makes sense. I wish we didn't have a UI setting for turning it off per user, but I recall the passionate reaction that led there.

The customizer similarly has its content determined by capabilities, but is also in itself an editing tool. What I think is odd here, no matter the method of turning it off, is that you end up with users who are empowered to do X but not allowed to have a live preview mechanism for X. This is probably okay when your users only use WP in a single context, but I think today we're in a place where people are experiencing WP on more than one site, and changing that availability, shifting contents and all, is a bit of a disservice when it comes to the bigger picture. I'm not inherently opposed to somebody not wanting to use the customizer on a personal level - I certainly find it annoying in some workflows - but providing a filter for this purpose is in essence endorsing disabling our current live preview mechanism. That is not something I can globally get behind. Still a wontfix for me, but better to document and discuss.


Thanks for the additional reasoning, it is greatly appreciated!

One the reasons I disable the Customizer on some sites is that the UI is so different from the dashboard experience that my clients feel like they wandered into a different system. I've found that many of the small businesses I build WP sites for may only update their site 3-4 times a year and will print out specific steps on how to change things using screenshots. If one of them were to click the Widgets link from the admin bar and suddenly find themselves in the Customizer, their first instinct is that something is wrong and they'll call me. I don't mind providing training on using the Customizer but usually the response I get is more along the lines of, "Why did this change? It was fine before." and for those particular clients I'd like to be able to keep them in their consistent, familiar UI. The admin bar Widgets link vs dashboard Widgets link was especially confusing for them but that's more of a consistency issue than specifically related to the Customizer.

I really do like the Customizer, I just don't feel it's a worthwhile UX improvement for some clients.

#10 in reply to: ↑ 6 @senlin
2 years ago

Replying to Viper007Bond:

And modifying capabilities is not difficult (and there might even be a better way than this):

add_filter( 'user_has_cap' , function( $allcaps ) {
	unset( $allcaps['edit_theme_options'] );
	return $allcaps;
} );

Not only does that filter disable the Customizer, it also wipes out the Menu and Widgets pages, bit too extreme, no?

Note: See TracTickets for help on using tickets.