Harden assignment of Customizer settings transports for selective refreshable widgets

[westonruter]

In #36389 it was brought to light that the theme support for customize-selective-refresh-widgets can be added _after_ the logic for registering the settings for incoming widgets that have been changed. This is due to themes adding the theme support in after_setup_theme which is also the action where WP_Customize_Widgets::register_settings() is called. If these both happen at priority 10, which one is called first depends on which one was added first. The other issue is that at the time that WP_Customize_Widgets::register_settings() is called at after_setup_theme, it is called before widgets_init and thus no widgets are yet registered. This means that any settings registered at this point will always have a refresh transport even if the theme supports customize-selective-refresh-widgets, since the WP_Widget instance is not visible yet to see if it supports selective refresh.

The fix is to change when WP_Customize_Widgets::register_settings() is called, deferring it from after_setup_theme to widgets_init, at a priority when the widget objects have all been registered (e.g. 95)

See https://core.trac.wordpress.org/attachment/ticket/36389/36389.4.diff

[Ipstenu]

List of everyone calling after_setup_theme

[Ipstenu]

Attached after_setup_theme.txt which is everyone calling ... after_setup_theme()

It's actually every single file. If there's a good secondary, I can grep or ack on that.

remove_action( 'after_setup_theme', array( $wp_customize->widgets, 'register_settings' ) );

I know that's what we're looking for-ish, so maybe grep the files for wp_customize ?

[westonruter]

@Ipstenu try this:

ack --php '(has_action|add_action|remove_action).+?after_setup_theme.+?register_settings'

[Ipstenu]

Files from previous list who call wp_customizer

[Ipstenu]

Files from previous list who call settings

[Ipstenu]

That came back with zero hits, @westonruter :(

I ran this: cat scans/after_setup_theme.txt | ack -x 'register_settings'

And I got 96 hits: after_setup_theme-settings_files.txt

Ran it with wp_customizer and got a couple hundred: after_setup_theme-wp.txt

[westonruter]

@Ipstenu zero hits is good! :-)

Acking for register_settings is too broad, since we want to find specific calls to a method named just 'register_settings'. This pattern narrows it down to 26: ack -w "[\"'>]register_settings[\"'\(]"

I don't see any reference to instances of WP_Customize_Widgets but just other plugin-specific classes.

If I instead ack the list for customize, I see references to this method in PHP comments for plugins I've been involved with:

/plugins/plugins/customize-pane-resizer/php/class-plugin.php:28:		$priority = 9; // Because WP_Customize_Widgets::register_settings() happens at after_setup_theme priority 10.
/plugins/plugins/customize-widgets-plus/php/class-plugin.php:61:		$priority = 9; // because WP_Customize_Widgets::register_settings() happens at after_setup_theme priority 10

So yeah, there doesn't seem to be any code reference to WP_Customize_Widgets::register_settings(). I expected this to be the case, since this is a low-level method that shouldn't be interfered with.

[westonruter]

Duplicate of #36389.

Fixed in [37166].