The selective refresh feature plugin for the customizer makes for a better customizer experience. Weston Ruter summarized the feature on Make Core, and describes its functionality in depth. But also hints at what it makes possible.
Currently, postMessage
enables live changes, but saving those changes requires a full page reload. postMessage
doesn’t do any server side communication. Selective refresh enables server side communication (aka allows for actual saving of changes) and the ability to view changes without a full page reload.
The code that is now a framework for selective refreshing started with the move of nav menus and widgets to the customizer:
With theĀ shipped example of selective refresh ofĀ nav menus in theĀ Customizer, and an initial implementation ofĀ selective refresh for widgets, work progressed to generalize a selective framework that would support the complicated examples ofĀ nav menus and widgets, but also to support simpler use cases such as letting the server render the updated site title so that
wptexturize
and other filters can apply. The generalized framework has been implemented in the CustomizeĀ Partial Refresh feature plugin, which also re-implements selective refresh of nav menus and introduces selective refresh of sidebars and widgets.
And now, selective refreshing is making its way to WordPress 4.5. However, Weston buried the lede.
As he notes toward the end of the post on Make WordPress Core, the selective refresh component doesn’t just allow for site changes within the customizer, but for customizer controls to be called from the site.
It’s worth describing what partials are in this context, for those (like me) that aren’t into the nitty gritty of the customizer:
This plugin introduces a selective refresh framework which centers around the conceptĀ of the partial. A partial is conceptually very similar to a Customizer control. Both controls and partials are associatedĀ with one or more settings. Whereas a controlĀ appears in theĀ pane, theĀ partial livesĀ in the preview. The fields in a control update automatically to reflect the values of its associated settings, and a partial refreshes in the preview when one of its settings isĀ changed.
And…
In addition to a partial being associated with one or more settings, a partial is also registered with a jQuery selector whichĀ identifies the partialās locations or āplacementsā on the page, where the rendered content appears.
With selective refresh, an interface could be created within placements themselves to give focus on the associated control; but the whole customizer isn’t required, and just the control that’s needed can pop out. As Weston putĀ it, “That is to say, selective refresh makes the Customizer a much better framework for implementing frontend editing.”
And that, in addition to selective refresh, is awesome.
Thanks for the writeup.
Actually, saving settings that are previewed via postMessage does not require a full page reload. The problem with previewing changes purely via postMessage is that the logic for applying the change has to be completely duplicated in JavaScript from what is done in PHP for normal site visitors. This isn’t a huge problem for simple scalar settings like a blogname or background color, but for compound settings the selective refresh framework allows for the rendering logic to be kept DRY, which is essential for scalably previewing changes widgets, nav menu, or content in a post/page.