[wp-trac] [WordPress Trac] #39487: Default to 'transport'=>'postMessage' for a setting associated with a selective refresh partial

[WordPress Trac]

#39487: Default to 'transport'=>'postMessage' for a setting associated with a
selective refresh partial
-------------------------------------------------+-------------------------
 Reporter:  danielbachhuber                      |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  5.4
Component:  Customize                            |     Version:  4.5
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-unit-  |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by dlh):

 * keywords:  needs-patch => has-patch needs-testing needs-unit-tests
 * version:   => 4.5
 * milestone:  Future Release => 5.4


Comment:

 I've been tripped up by not using `postMessage` with my partially
 refreshed settings many times. It'd be great if core could provide a
 safety net here.

 [attachment:"39487.diff"] attempts to implements the logic described in
 comment:1.

 The logic is added to the `\WP_Customize_Selective_Refresh` class in part
 because it's related to selective refresh and part to avoid adding more
 methods to `\WP_Customize_Manager` if they don't strictly have to be. The
 added `check_transport_of_settings_with_partials()` method is called via
 hooks to allow developers to disable it consistently in the admin and the
 preview.

 As I was working on this patch, I learned that there's precedent for a
 theme to register a partial for a setting but intentionally leave the
 setting transport as `refresh` unless some condition is met. Core itself
 uses this pattern with the `header_image` setting, which is changed to
 `postMessage` in `\WP_Customize_Manager::register_controls()` depending
 the on theme support for `custom-header`.

 The patch would also change the transport for these settings, perhaps
 unexpectedly. Luckily, if the partial keeps `$fallback_refresh` enabled,
 then a full refresh of the preview will continue to occur if the partial
 refresh fails. Accordingly, the patch doesn't modify settings associated
 with partials that disable `$fallback_refresh`.

 I'll work on unit tests, but I'd love for anyone to take the patch for a
 spin to try to get something into the next release!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/39487#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform