Customize: add a post editing flow

[mattwiebe]

The Customizer has always prevented following any non-frontend links in the preview, which has disabled post links provided by edit_post_link() from working. This was worked around in #38648 by no-op'ing the edit links.

One approach to solving this problem would be to bring post editing into the Customizer, which has been explored: ​https://github.com/xwp/wp-customize-posts

Another approach would be:

1. Navigate to the appropriate edit post screen when an edit_post_link() is clicked on
2. Before 1), save a Customize changeset if the state is unsaved
3. Provide a UI on the edit posts screen to return to the Customizer after editing is complete
4. When returning to the Customizer, restore the changeset stored in 2) if one was needed.

This would solve the problems of there being no way to edit posts from the Customizer, while not trying to stuff a (duplicate) post editing UI into a space that is not well-suited to it.

This could also help to editing posts created in nav menus #38002

[westonruter]

Changesets do provide a path to be able to suspend the customizer session to make edits to posts/pages via the edit post screen and then return to continue making changes customizer. (Another option would be a lightbox.) What I am wary of here is that the changes made are not actually part of the changeset even though the user would be editing the posts in the middle of a customization (live preview) session. I think the user should be able preview changes to the posts/pages along with the changes they are making to any corresponding nav menus and widgets, as well as be able to publish (even schedule) all of the changes together at once. I suppose it might be possible for changes made to posts/pages via the edit post screen to be routed to some autosave revision which can then be added to the changeset so that once the changeset is published the autosave revision could also be published as well (see ​wp-customize-posts#339). Nevertheless, while this could work technically, the UX of switching between the customizer interface and the edit post screen is jarring.

I think that the problem with the customizer UI being unsuitable for editing posts will be addressed this year as part of the next-generation customizer work, which should make editing content/blocks inside the post much more seamless with editing content/blocks outside the post. This should be accompanied by a next-generation editor which would be able to be embedded/overlayed in the customizer context.

[mattwiebe]

I should have clarified that this is mostly about providing a minimally viable flow where there is none now, where that flow is better than having none at all, is is the case right now.

I think that the problem with the customizer UI being unsuitable for editing posts will be addressed this year as part of the next-generation customizer work

Agreed! In the meantime, we have what we have, and will have it for quite some time, I would imagine. All this proposal is doing is trying to close the loop on a currently impossible flow with the lightest-possible implementation. Things like scheduling, like combining the post edit into the changeset, sound nice, but those could be later enhancements if they're deemed worthy.

In the meantime, there's a very real functional hole that can be patched together in a minimally viable way. It wouldn't be great, but better than what we have (nothing), and I think that's a win.

[westonruter]

Good points!

[karmatosed]

Replying to mattwiebe:

In the meantime, there's a very real functional hole that can be patched together in a minimally viable way. It wouldn't be great, but better than what we have (nothing), and I think that's a win.

+1 - anything we can do fix the experience sooner is such a benefit.

[lukecavanagh]

Having something sooner would be a big benefit, since the customizer and editor version will take much longer.

[mattwiebe]

Some prototyping started here: ​https://github.com/Automattic/customize-edit-post-flow

[celloexpressions]

I'd like to see this explored as a integration of the customize posts plugin but with inline-editing-only UI, and perhaps no post meta or taxonomy support at first. There should also be no UI for navigating to edit content in the customize pane - in-preview edit links should be used, perhaps alongside edit buttons added to menus and dropdown-pages controls in the pane.

In other words - bring the technical foundation that's now fairly mature into core, but restart from the ground up on the UI, only exposing the most critical functionality at first.

[westonruter]

@mattwiebe I gave your plugin a spin. I like the low profile, but I'm nervous about users getting used to the post changes being non-previewable and not-bundled with the changeset, like they're already perhaps used to with the media library modal (see #37887), though many are likely unaware of the details for how everything in the customizer should only be previewed/staged before an explicit saving. Maybe there is a better way to communicate, “hey, you're stepping outside the customizer so you are no longer previewing changes.” If the UX can be polished to communicate this to users, then I would endorse this as it could surely be ready before the customizer infrastructure for modeling posts/postmeta.

I opened a ​PR with some enhancements, including:

• Show link back to customizer before an update is made, if they decide no change needs to be made.
• Hide admin bar, admin menu, and admin footer in edit post screen when editing post opened from customizer. The intention is to keep the user from navigating away from editing the post. This could be extended further, such as for the revisions link. In fact, sessionStorage could be used to store the customizer_return and injected in more places via JS.
• Show cursor:progress once clicking link in preview to show while pending changes are written to changeset.
• Add notice about post changes made not being previewable nor being part of customizations.
• Add support for edit post links added via infinite scroll.

[celloexpressions]

Not sure it's worth spending much time on an admin-side, non-customize-api-based solution here. There's a decent chance there won't be a major core release before it's feasible to include the editor directly within the customize API. That'll be a far-superior experience than any temporary solution could offer.

Adding the customizer theme switcher in 4.2 really seems like a mistake now that we're still stuck with it and it has a massive functionality hole in preventing theme installation from being discoverable (see also #37661). This ticket feels like its starting to head down a similar path.

[mattwiebe]

Apologies for disappearing here, my priorities have shifted to other work, so I'll just leave the state of what I had completed in case anyone else wants to carry on. If not, I will still likely return to this, just not sure how soon that will occur.

The current version of ​the plugin adds a persistent notice across wp-admin to return to in-progress changeset. There are a couple of ​todos with things that need to be done to close the loop on that flow. There will be others, too, including cleanup from an earlier version (eg customizer_return is no longer used).

[westonruter]

Something else to consider with the link back to the customizer is to not only include the changeset_uuid query param but also the rest of the customizer state UI as it was when the link to edit a post was clicked. In other words, the current url being previewed and whichever panel/section/control is expanded via the appropriate autofocus param(s). Additionally, while not yet supported by core, the scroll position and device being previewed could also be captured: the ​Customizer Browser History feature plugin (see #28536) is able to restore these. Also, the ​Customize Snapshots plugin just ​added support for capturing the state query params at the time of saving a changeset, ​allowing these to be restored when the changeset is picked up again for editing. This is the same scenario that this ticket is addressing. See ​the code for obtaining the state query vars.

[celloexpressions]

There is a definite benefit to this work; however, it seems like it would be better to spend our time better-integrating the customizer with the front end, rather than with the admin as this ticket does. These changes could actually make the experience of the customizer as an in-between state more confusing. In the meantime, customizer browser history is the type of thing that benefits both approaches, should we decide to integrate the customizer more with wp-admin in the future (or in plugins) for some reason.

[jbpaul17]

Per yesterday's bug scrub, we're going to punt this to 4.8.1.

[westonruter]

I think this could be a great place for the Gutenberg editor to be integrated.

[westonruter]

This can be worked on as part of the Gutenberg plugin once it is at a point that the editor component can be integrated into the Customizer.

[westonruter]

In 41887:

Customize: Allow post/page stubs to be edited in WP Admin as "customization drafts" when changeset is saved as draft or scheduled.

• Update stubs to have draft status when changeset is saved as draft, instead of preventing auto-draft garbage collection by giving them a far-future post_date.
• Show notice in publish metabox when editing a customization draft indicating that it will be published automatically with its changeset; a link to Customizer is included.
• Include a new "Customization Draft" display post state in the post list table.
• Disconnect stubs from their changesets when they are updated with a status other than "Draft".
• Trash customization drafts when their related changeset is trashed or deleted.
• Add a _customize_changeset_uuid postmeta to stubs to link them with their associated changeset.
• Include customize_changeset_uuid as context when requesting to insert a new auto-draft.

Props westonruter, melchoyce.
See #39896, #39752, #34923.
Fixes #42220.

[JoshuaWold]

We just discussed this one in the design triage sync in Slack. In order to make sure we give the most effective feedback it'd be helpful if we could see a short video walkthrough or a few screenshots showing what's going on. :)

[celloexpressions]

This actually needs a new design proposal now, for how the Gutenberg editor will integrate with the customizer (15). The result is a unified interface for editing any aspect of a site with contextual live preview (and unified drafting/scheduling/publishing options). There are two fundamental design directions that this could go in:

1. Separate that editor from the front-end preview. Similar to the editor in wp-admin. The disadvantage is that the preview gets less "live", but it may be an easier technical implementation. UI could live in a sidebar or in a full-screen overlay that gets toggled with the preview similar to the mobile customizer interface.
2. Integrate the editor into the front-end preview. This could be similar to the wp-admin editor with a sidebar for post- and block-level controls, with the actual editing happening inline on the frontend of the site. Other aspects of site editing would also move from the customize sidebar into the preview in this scheme. The preview should retain the ability to navigate to different pages on the site during the editing process, complicating the technical implementation. This is the general approach that I advocated for above in this ticket.