[wp-trac] [WordPress Trac] #27355: Customizer: Add framework for partial preview refreshes

[WordPress Trac]

#27355: Customizer: Add framework for partial preview refreshes
-------------------------+--------------------------
 Reporter:  westonruter  |       Owner:  westonruter
     Type:  enhancement  |      Status:  assigned
 Priority:  normal       |   Milestone:  4.1
Component:  Customize    |     Version:  3.4
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  javascript
-------------------------+--------------------------

Comment (by westonruter):

 Replying to [comment:20 celloexpressions]:
 > - If a setting has a `selector` and `transport: postMessage`, do `$(
 selector ).html( to );` for the setting in core, eliminating the need to
 implement it in JS. If no selector is specified, require implementing it
 manually as you must currently do. In other words, by specifying a
 selector you say that the value of that setting is the content of that
 selector, so no other handling is needed.

 Yeah, good thought. However, only sometimes is the JS behavior just
 sticking the value into a certain element as the HTML or (better) text
 content. Changing a color, for instance, wouldn't make sense at all to use
 `$( setting.selector ).text( value )`. So then that would necessitate
 having some declarative way in PHP to indicate how JS should handle the
 updating of a setting on the element(s) found by the selector: do you
 update the text content? Do you replace the HTML for the entire element?
 Do you change an attribute's value? Do you change some style property? So
 you can see that this quickly can get out of hand, this automatic
 generating JS logic to apply setting changes. So I think for now it should
 continue to be a manual update if `postMessage` transport is supplied.

 > - That's not directly related to partial refreshes, but makes it even
 easier to implement partial refreshes where the entire contents of the
 selector is the value of the setting.

 Yeah, if the transport is `partialRefresh`, then we can automatically
 apply the change because by definition we're updating a specific element,
 and not having to do any special logic. We would, however, be firing
 events when a partial gets updated so that Customizer preview JS can re-
 attach any event handlers or construct dynamic elements.

 Even in this case, however, I think the default handler for refreshing a
 partial's element should be allowed to be explicit. When attaching these
 default behaviors, we could check to see if the theme already defines
 custom behaviors for a partial refresh and defer to it.

 > - Unfortunately, we're not going to be able to make any changes to
 Twenty Fourteen here, since it needs to be 100% back-compat to 3.8. But we
 can do whatever we'd like for Twenty Fifteen.

 Thanks for pointing that out. I'll revert.

 > - `WP_Customize_Manager::update_settings()` could be really useful. It
 should probably wrap a singular version, which would be a bit nicer than
 modifying properties directly, as the current `get_` methods require. Of
 course, we would need to introduce this for all of the Customizer objects
 - panels, sections, settings, and controls. Probably needs a new ticket,
 maybe not 4.1 material.

 OK, so `$wp_customize->update_setting( $id, $array )` and
 `$wp_customize->update_settings( array( $id1 => array(…), $id2 =>
 array(…), … ) )`? And then implement `update_panel(s)`,
 `update_section(s)`, `update_control(s)` as well? Good stuff. Yeah, I
 agree that this should go in another ticket.

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