WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 8 months ago

#43043 closed defect (bug) (duplicate)

WP Customizer checks current_user_can() too early

Reported by: jamesmehorter Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.4
Component: Customize Keywords:
Focuses: Cc:

Description

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.

Change History (4)

#1 @westonruter
3 years ago

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.

#2 @mauteri
3 years ago

@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?

#3 @dlh
3 years ago

See previously #24169.

#4 @dlh
8 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed
  • Version changed from 4.9.1 to 3.4

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.

Note: See TracTickets for help on using tickets.