In reply to Kristin.

@Kristin @KTS915 Thanks for your comments. I don't think we ultimately disagree here. I too want to see front-end editing happen, but we have to first build up the foundations, and I believe the Customizer is the best foundation to get us there.

The Customizer is WordPress's framework for previewing changes. I believe it is the natural place to develop features like content editing because users need to be able to see what their content looks like without a “save and surprise” experience. See an issue on the Front-end Editor project from two years ago where we discussed using the Customizer as the framework for previewing changes.

I believe the Front-end Editor project may have stalled because of the huge challenges with implementing an inline front-end editing experience that is compatible across all themes. The Customizer was designed for theme compatibility and because there is a separation between the preview and the controls for making changes, it is much easier to develop controls for editing posts and postmeta. Changing a page template is a great example: a change to a page template necessitates a full page reload because a template could have a radically different structure. Since the control for changing the template is not inline, a full page refresh doesn't cause the UI for editing to momentarily go away while the refresh is happening

For changing aspects that don't carry the risk of a full page refresh to preview properly, there are other challenges. Consider editing the post content and how the content in the visual editor in the backend is visually different than how the post content appears on the front-end. Sure there are editor-styles.css to help approximate the style, but it's not perfect. Beyond styling differences, a bigger challenge is how to deal with shortcodes. Even with the Shortcake project (a plugin which gives Shortcodes a UI with a visual representation of a shortcode similar to how the gallery shortcode is handled in core), the shortcodes appear differently in an editing context than in a regular front-end context. So there is a challenge for editing content on the front-end, where if you start editing the rendered content would have to be replaced with the editor content, and then then to preview the change you'd have to then leave the edit mode to go back to the preview mode.

The selective refresh functionality mentioned in this post provides the mechanism to preview changes to parts of a post without refreshing the entire page. This is critical for implementing front-end editing since, as noted above, you can't have the page reloading all the time while you are trying to type in the page.

Selective refresh (aka partial refresh) opens a door for the Customizer framework for previewing changes to be used on the front-end. A first phase for the Customizer on the front-end would be to lazy-load the Customizer sidebar and controls without having to navigate to customize.php. The second phase would be inline editing on the front-end. For an example of how this could work: say you're on the front-end and see a post you want to make a change to. You could click the regular post “Edit” link and the title and the content could then appear as editable fields, while the admin bar could reveal two new buttons for “Preview” and “Save”. Clicking “Preview” would apply the changes you made and apply selective refresh to see the title and content as they would appear on the front-end after saving. You could then click the Edit link again to make additional changes, or you could then click “Save” to persist the changes to the database. The changes you make could be added to a Customizer transaction and so persisted as a draft, allowing you to navigate to other areas of the site (e.g. going from the homepage where the excerpt is displayed to the post's permalink to see the full content), and you could continue editing the changes you made on the previous page. When you're satisfied, you could then click “Save” to persist all of the changes you made while in the Edit context while navigating around the front-end of the site.

Using the Customizer as the framework for front-end editing does not necessarily require using the Customizer UI as it currently exists.

So, please don't write-off the Customize Posts project as a waste of time. Front-end editing is a huge challenge and requires a lot of architecture. We're working on the foundational pieces for content editing in the Customizer with the goal of using them to power front-end editing as you are longing for.