[wp-trac] [WordPress Trac] #36431: Harden assignment of Customizer settings transports for selective refreshable widgets

[WordPress Trac]

#36431: Harden assignment of Customizer settings transports for selective
refreshable widgets
--------------------------+----------------------------
 Reporter:  westonruter   |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Future Release
Component:  Customize     |    Version:  trunk
 Severity:  normal        |   Keywords:  4.6-early
  Focuses:                |
--------------------------+----------------------------
 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

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36431>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform