Selective refresh paves a path for frontend editing

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.


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.

Similar Posts

One Comment

  1. Thanks for the writeup.

    Currently, postMessage enables live changes, but saving those changes requires a full page reload. postMessage doesn’t do any server side communication.

    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.

Comments are closed.