A couple days ago Helen Hou-Sandí live tweeted her first time trying out Gutenberg, the feature plugin for the next generation WordPress editor. One of her tweets stood out to me and started a thread:
tl;dr You can use the Customize Posts plugin to add and edit posts in the Customizer and preview your changes—to the title, excerpt, featured image, etc—on any area of your site where the post may appear. Here is a demo video that shows the plugin in action along with the Customize Snapshots and Customizer Browser History plugins in a child theme of Twenty Seventeen:
Framework for Previewing
The problem of post previewing is something I’m really interested in. Post previews in core don’t work for postmeta (like the featured image and page template) and you can’t preview changes on anything other than the singular template. Actually, I’m really interested in being able to preview any change that I may make to a site before it goes live, and being able to preview any set of changes together. That’s a reason why I’ve been so interested in the Customizer, as it is WordPress’s interface and framework for previewing. The Customizer allows you to make changes to multiple settings and preview how they appear across your entire site: you just click around the preview and all of the changes remain applied as you navigate. Once you’re satisfied, you can then publish the changes for all to see, or you can abandon them as if they were never made.
The kinds of things you can manage in the Customizer have slowly grown since it was first introduced five years ago: from basic settings like the site title, what is shown on the homepage, and the configuration of the theme’s style—to managing widgets, nav menus, and custom CSS. What is not able to be managed in the Customizer yet are posts and pages (aside from now being able to create page/post stubs). If you were able to modify posts and pages in the Customizer—including setting their titles, excerpts, content, and featured images—then by virtue of the Customizer framework you’d be able to preview how those post changes look not only on the singular template but also on a category archive, search results, homepage, or anywhere else that the post would appear. And this management of posts and pages in the Customizer is exactly what the Customize Posts feature plugin implements.
Customizer and Gutenberg
The user interface for post/page editing in the Customize Posts plugin should definitely not be considered a proposal for what the future of content authoring looks like in the Customizer. Rather, the future of content authoring is what Gutenberg is all about. But what does the future of content previewing look like? This I suggest should be handled by the Customizer framework.
(By the way, you also don’t have to be limited to the preview being in the Customizer frame with sidebar controls either. The Customize Snapshots plugin allows you to open the changeset preview without a frame at all—something you can also do without the plugin by right clicking on a link in the preview and opening it in a new tab. When the frontend is loaded in the context of a changeset (with the
customize_changeset_uuid param supplied), you can click around the site and this changeset context will persist, allowing you to preview the customizations across the site. These changeset preview URLs can even be shared with unauthenticated users.)
The Gutenberg editor has a preview button like the classic WordPress editor, but it doesn’t quite work yet. I’ve suggested that if the Gutenberg editor stored the modifications—to post fields, postmeta like featured image, and other related objects like global reusable blocks—in a Customizer changeset, then clicking the preview button in the Gutenberg editor could just open the frontend with the changeset’s UUID parameter supplied to preview how all of those changes look not only on the post’s singular template but also anywhere else on the site where it appears, as you navigate around the site with the changeset’s preview state applied. This should also be the case for previewing and creating a draft of changes to previously-published posts, which is something Customize Posts also facilitates but is not currently possible in core.
Gutenberg is being developed in a way that it provides an editor component that can be embedded in places other than the edit post screen. You could be browsing the frontend of your site—inside or outside the current Customizer interface—and when you click an edit link this could open Gutenberg in an overlay allowing you to make changes, and then when you dismiss the overlay then preview how those changes will look. Additionally, since Gutenberg is all about presenting content as editable blocks and each block is in itself a reusable component, it should also be possible to do inline editing of blocks on the frontend. Selecting a block could reveal the block editing interface (with the inspector perhaps showing in a controls panel), and then deselecting the block could cause the Customizer’s selective refresh to kick in to re-render that block from the server so it will appear exactly the way normal visitors to your site will see it. Changes to multiple blocks on multiple posts could all be written into a single changeset as you go navigating around your site. This changeset can also include changes to any other settings like widgets and menus as well.
Customizer as Staging Environment
Customizer changesets allow you to stage changes; it’s like bringing a staging environment onto your production site. You can preview the changes yourself or share a preview of the changes with a stakeholder who doesn’t even have a WordPress user account, as noted above. You can then go live with all of the staged changes by publishing the changeset, which you can also schedule to go live later. The Customize Snapshots plugin currently implements the UI for this; read more on the recent v0.6 release post. A changeset allows you to batch save any number of unrelated changes at once. When the Customizer is used for managing content it opens up whole new workflows in WordPress.