Customize Posts Plugin and Selective Refresh are Paving the Way for Front-End Editing Powered by the Customizer

photo credit: Paintbrush – (license)

Last week Weston Ruter and the folks at XWP released Customize Posts version 0.5, which includes a new framework for postmeta and the ability to preview featured images. The feature plugin aims to introduce basic content authorship in the Customizer to improve the new user site setup experience and make it easier to edit existing content.

As of 0.5, Customize Posts supports the ability to change and preview the page template, and will sync changes back to the metabox on the page edit screen. It also supports changing the post author, excerpt, and comment/ping status, with live previews and changes saved to the editor. Check out Ruter’s screencast touring the plugin’s newest capabilities:

Front-End Editing Powered by the Customizer: A Not-Too-Distant Possibility

With all these advanced editing capabilities, it doesn’t take a giant leap to imagine a future where the customizer provides the architecture for a front-end post editor. While WordPress’ front-end editor project seems to have gone dormant, improvements to the Customizer are steadily chipping away at the various aspects of content authorship that are not yet editable on the frontend.

“Now that we have the ability to selectively refresh elements without doing full page reloads, this opens the door to using these Customizer components outside of the Customizer itself, such as in the frontend,” Ruter said.

Front-end editing of partials, which are similar to customizer controls but exist in the preview, is a natural extension of the selective refresh architecture and a concept that Ruter will be exploring in the near future.

“Consider, for example, being logged-in on the frontend,” Ruter said. “You see something you want to edit and you click on it. Since the Customizer partials all have selectors associated with them, if the partials are registered with each logged-in frontend request, then there are containers that can be targeted for editing.”

Ruter envisions that clicking on an element would load the controls for that element on demand via a lazy-loaded Customizer pane or a floating control. He said that this would work in concert with customizer transactions (aka snapshots) to store the changes persistently in a transaction.

Front-end editing powered by the customizer, according to Ruter, would involve the following:

Being able to click Customize in the admin bar to lazy-load the Customizer pane’s controls into the existing page without having to having to navigate to `customize.php`

Being able to click on individual containers that have associated partials to start editing controls that relate to those partials

All changes made on the frontend to be persisted in a transaction draft that is initialized on demand

The ability to edit posts in the customizer on the front-end isn’t going to happen overnight, but Ruter thinks a proof of concept could be available this year.

“It’s going to take some discovery and prototyping, similar to Customize Posts,” Ruter said. “My guess is there would be something to play around with in Q3, depending on other projects and having enough time to put down on paper these ideas that have been floating around for a couple years.”

An important step towards making that possible will be getting basic content authorship added to the Customizer, which Ruter and contributors are working towards for the upcoming WordPress 4.6 release.

These will be welcome changes for those who are looking to do more on the frontend, but it still leaves the bulk of content editing behind the admin. Unless you’re a developer who follows every update to the customizer, it’s still confusing for the average WordPress user to know what content can be edited on the frontend vs. content that requires returning to the admin. The editing experience will remain disjointed until the majority of tasks can be done on the frontend.