WP Customizer checks current_user_can() too early

[jamesmehorter]

Hi all :)

On WordPress VIP, the only user role which may use Customizer is an Administrator. This is due to when the current_user_can() checks occur.

WP Customizer currently checks capabilities on the setup_theme action. https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-customize-manager.php#L510

This means the only way to create a role/capabilities to manage Customizer settings is with one of the few hooks which run before setup_theme, i.e. muplugins_loaded or maybe plugins_loaded. However, if, like us, you're on WordPress VIP, the earliest hook to do anything is after_setup_theme, since any/all functionality must live in themes.

I would like to propose that any Customizer current_user_can() checks be moved to the after_setup_theme action. Of course this would benefit us, but more importantly, Customizer specifically allows 'theme_mod' settings (setting specific to the current theme), which infers that a theme_mod setting is registered by the theme. If a setting is registered by a theme, the theme should then also be able to determine who may view/edit that setting.

[westonruter]

You must be using VIP Cloud Hosting and not VIP Go. In the latter case, you could add a full-on plugin. In the former case, I seem to recall that VIP can arrange for adding site-specific mu-plugin code.

[mauteri]

@westonruter This would effect anyone trying to do the same thing in a theme. Shouldn't the current_user_can( 'customize' ) checks fall in the after_theme_setup hook rather than the theme_setup to give the theme code a chance to set role/capabilities for this?

[dlh]

See previously #24169.

[dlh]

Having re-read both tickets, I think it would be fair to mark this ticket as a duplicate of #24169. As I understand it, the security concern described in ticket:24169#comment:4 that necessitates capability checks before after_setup_theme also applies in the VIP scenario described here.

If an approach becomes available to soften the blow of this limitation, as was sought after in #24169, I would move that it be added there so as to continue the previous discussion.