WordPress.org

Make WordPress Core

Opened 6 months ago

Last modified 35 hours ago

#39896 new enhancement

Customizer: Allow users to Draft changes before Publishing

Reported by: melchoyce Owned by:
Milestone: 4.9 Priority: normal
Severity: normal Version:
Component: Customize Keywords:
Focuses: ui Cc:

Description (last modified by westonruter)

Inspired by drafting and revisions in the Customize Snapshots plugin, the button design in Customize Posts, and Press This, I want to propose a way to allow users to draft changes in the Customizer.

This introduces a split button to the Customizer that lets you toggle between "Publish" and "Save Draft."

This would pair nicely with the Revisions mockups introduced in #21666, but doesn't depend on it.

Drafting would be helpful if you're setting up your site, or making some big changes, and you don't want to publish them just yet. With drafting, you can leave and come back to the Customizer later to finish making your changes.

If you leave the Customizer without saving a draft or publishing your changes, the next time you enter the Customizer, you'll get a notice asking if you want to restore the autosave.

In future iterations, once Revisions is built, we'll explore adding the ability to have multiple drafts of pending changes. Also related is the ability to schedule the changes for publishing (#28721).

Related: #31089, #39841

Attachments (7)

customizer-drafting-i1.png (455.4 KB) - added by melchoyce 6 months ago.
customizer-advanced-draft-i1.png (138.2 KB) - added by folletto 6 months ago.
Customizer Advanced Publishing Options i1
Save and Publish - Option 1.png (287.6 KB) - added by JoshuaWold 4 days ago.
Save and Publish - Option 1
Save and Publish - Option 2.png (325.7 KB) - added by JoshuaWold 4 days ago.
Save and Publish - Option 2
Save and Publish - Option 1.1.jpeg (358.2 KB) - added by JoshuaWold 3 days ago.
Save and Publish - Option 1.1
Save and Publish - Option 2.1.jpeg (479.3 KB) - added by JoshuaWold 3 days ago.
Save and Publish - Option 2.1
Save and Publish - Option 2.2.jpg (379.5 KB) - added by JoshuaWold 39 hours ago.
Save and Publish - Option 2.2

Change History (31)

@folletto
6 months ago

Customizer Advanced Publishing Options i1

#1 follow-up: @folletto
6 months ago

Given that I like the linear approach that is posted above, its structure also inspired me an idea that can allow some more advanced future features. It basically uses the same interaction on the side of the publish button, but instead of opening a small popup takes over the entire sidebar. With that space, we can do many things.

In the concept above I explored this concept a bit:

  1. Same basic functionality: Publish and Draft.
  2. Sharing link available (this is a bit simplified as it's dependent on save, so it's not that linear as in the mock)
  3. Preview before publishing of all the changes, with the ability to quickly revert them.
  4. View of the date and author of latest published changes.
  5. Link to history of past revisions.

I'd note that this is more an exploration for ideas than a straight suggestion for this ticket, but since it might inspire a different approach and a longer term vision in another way, I think it made sense to be added.

#2 @karmatosed
6 months ago

First up, really like that this is happening. It's something that will have a lot of user impact and benefit.

I think it could be good to prototype both ways and explore them as they are different enough for that.

I do wonder about the non-popover approach though. I'm possibly feeling it's a little not as natural as the popover - it feels less of an existing pattern in WordPress. In saying that, it's not a bad idea to explore new things.

#3 @westonruter
6 months ago

In terms of how to implement drafting as proposed here technically, this is what I have in mind:

After you hit Save Draft, and then leave the customizer, if you come back to click Customize and go straight to customize.php you would get the previous drafted changes restored. Currently each time a user starts customization a new changeset is spun up into existence with a unique UUID. So potentially instead of creating a new UUID, we could instead first query the changesets to see if there is a draft and instead use it instead. This behavior should be customizable by plugins (e.g. Customize Snapshots) so that concurrent non-linear drafts of changes could be made. But in core, only one draft would normally exist at a time, for the initial iteration.

When you start a new customization session from scratch, as you make changes those changes currently get autosaved into the auto-draft changeset periodically so that if you navigate away from the customizer you can get the changes restored. (Also this allows you to share the URL with another user so they can preview and make additional changes on top of what you have done.) Still, when you try to leave the customizer it still presents you with the AYS dialog since there is no UI to return to that changeset, which is what introducing a Draft button will address, as will restoring the last drafted changeset to the customizer the next time someone starts a session.

The moment that someone hits Save Draft this should cause the AYS dialog to be removed and it should stop the autosave behavior which writes new changes directly on top of the changeset, since it is now a draft and not an auto-draft. Subsequent changes should be autosaved into a new autosave revision of the changeset instead of writing onto the changeset post itself. A subsequent change should also cause the onbeforeunload AYS dialog to be restored, until which the user hits Save Draft again which should result in the changes being written on top of the changeset post directly (and if revisions support is enabled for customize_changeset posts, this should cause a new normal revision to be made).

If the user has made changes to a Draft and leaves the customizer ignoring the AYS dialog, a user could be notified that there are autosave changes that are saved in the changeset's autosave revision (as noted in the ticket description) which could then be restored be merging them on top of the saved changeset (and then either reloading the customizer or dynamically populating up the customizer settings in JS, assuming that the UI will dynamically respond to create corresponding sections and controls in response to settings being spun into existence), as noted above.

#4 @westonruter
6 months ago

  • Milestone changed from Awaiting Review to 4.8

@melchoyce Question: How would a user abandon the changes? How would they clear out the draft? Should there be another option in the dropdown to revert/reset/trash the changeset?

#5 in reply to: ↑ 1 ; follow-up: @melchoyce
6 months ago

Given that I like the linear approach that is posted above, its structure also inspired me an idea that can allow some more advanced future features. It basically uses the same interaction on the side of the publish button, but instead of opening a small popup takes over the entire sidebar. With that space, we can do many things.

Thanks @folletto, this is a great exploration — I can see it extending well to future iterations. For example, this would be a good framework in which to add scheduling. Let's explore future after i1 is in the works.

I think it could be good to prototype both ways and explore them as they are different enough for that.

@karmatosed: For now, we're just going to focus on drafting vs. publishing. We'll explore more advanced options in future iterations.

Question: How would a user abandon the changes? How would they clear out the draft? Should there be another option in the dropdown to revert/reset/trash the changeset?

@westonruter: This is where I diverge from your thoughts on technical implementation. I think drafting here should mirror how it works in posts. Specifically, I disagree with:

After you hit Save Draft, and then leave the customizer, if you come back to click Customize and go straight to customize.php you would get the previous drafted changes restored.

This is how I see it:

  1. Make some changes
  2. Leave the Customizer without saving
  3. Changes are autosaved
  4. Come back into the Customizer
  5. See a prompt to restore changes
  6. If you click to restore, they're loaded into the Customizer
  7. If you click the close icon on the autosave changes notice, the old changes are discarded (but maybe saved in your revision history?)
  8. If you make new changes and save, the old changes are overwritten

We wouldn't load your autosaved changes, but would instead rely on you to manually bring them back. I think this is far less complicated than automatically loading your autosaved changes, and more consistent with how drafting works elsewhere in core.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


6 months ago

#7 @westonruter
6 months ago

  • Description modified (diff)

#8 @westonruter
6 months ago

  • Description modified (diff)

#9 in reply to: ↑ 5 ; follow-up: @westonruter
6 months ago

Replying to melchoyce:

We wouldn't load your autosaved changes, but would instead rely on you to manually bring them back.

Yes, this makes sense to me. 👍🏻

See a prompt to restore changes

So, is this then a clear use case for the global notification area (#35210)?

#10 in reply to: ↑ 9 @melchoyce
6 months ago

Replying to westonruter:

So, is this then a clear use case for the global notification area (#35210)?

Yeah, I think it is. I went with @karmatosed's design proposal from ticket:35210#comment:26 because I still find it the most simple and clear version.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


5 months ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


3 months ago

#13 @jbpaul17
3 months ago

  • Milestone changed from 4.8 to 4.8.1

Punting to 4.8.1 per bug scrub earlier this week.

#14 @westonruter
2 months ago

  • Milestone changed from 4.8.1 to 4.9

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.


3 weeks ago

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.


5 days ago

This ticket was mentioned in Slack in #core-customize by joshuawold. View the logs.


5 days ago

@JoshuaWold
4 days ago

Save and Publish - Option 1

@JoshuaWold
4 days ago

Save and Publish - Option 2

#18 @JoshuaWold
4 days ago

Last week Weston, Mel, Jeff Paul and myself met to talk about the various options available in this ticket.

We also took some inspiration from the mockups from @folletto (https://core.trac.wordpress.org/attachment/ticket/39896/customizer-advanced-draft-i1.png) - thanks!

There are a few ways we can tackle save and publish in the Customizer. The WordPress admin is handling this one way, and the Gutenberg plugin has been considering some other ways to handle it. We’re trying to find a middle ground between those two for the Customizer.

Based on the mockup above, we would like to propose that the settings for save and publish be shown in a panel (that either slides in vertically or horizontally, tbd) in the Customizer, as opposed to a modal dropdown (previously proposed here: https://github.com/xwp/wp-customize-posts/issues/207)

Here are two of the ideas we’ve discussed:

Option 1

Save and publish are split out as two separate buttons at the top (we need to validate if the words will still fit when translated). There is another button to open up the settings panel. Clicking that will slide in the panel and give you the option to schedule the post *which will change the main publish button to say “schedule” or share the draft.

Option 2

There’s a publish button with an arrow icon to open up the settings panel in the Customizer. In the settings panel you can change the button from a publish button to a save button.

You can also schedule the post, which will update the button to say “schedule”

#19 @westonruter
3 days ago

I like Option 2 because it opens the door for additional statuses, like Submit for Review (Pending).

I know this is just a sketch, but instead of “Switch button state” I think it would be something like “Saving changeset will:” and then you decide if it will Save Draft or Publish (or eventually Submit for Review). Or it could just be “Status” like on the edit post screen. The default would be Publish, and so a user would only switch to Draft if they explicitly want to create a long-lived draft. In that way, it would maintain existing usage patterns for users who are used to just hitting “Save & Publish” after a quick change. My only hesitation there is I think there has also been discussion in Gutenberg about adding a second click behind Publish to prevent accidentally going live, so right now in Customize Snapshots there is a “Confirm Publish” button that appears as well.

At first I was thinking there should be a “Schedule” option in addition to “Publish” but actually I like how you have it here in that you can supply a future date either when saving as a draft or publishing, as then you'd be able to save a draft with a future date but you're not wanting to commit yet to it going live accidentally if you forget about it.

One other note: “post” should be replaced with “changeset” in the mocks.

This ticket was mentioned in Slack in #core by westonruter. View the logs.


3 days ago

@JoshuaWold
3 days ago

Save and Publish - Option 1.1

@JoshuaWold
3 days ago

Save and Publish - Option 2.1

#21 @JoshuaWold
3 days ago

Thanks for the feedback @westonruter, I updated the wireframes based on that. I like some things about Option 1.1 better, but agree that Option 2.1 allows for expandability with the button.

#22 @westonruter
2 days ago

One other thing that I think needs to be factored into this design is how to display any existing changesets which are currently scheduled or other changesets that are currently drafted. Or do we only allow one single changeset to be drafted/scheduled at a time for the first iteration on a core merge? This is the so-called “linear option”. In that option, when you open the Customizer you would be opening with whatever the latest non-published changeset is, whether that be drafted or scheduled.

For the non-linear option (the branching option), which is what Customize Snapshots implements, there can be any number of concurrent changesets drafted or scheduled at a time, and in that case each time you open the Customizer you'd be starting a new changeset. In that case, you'd want to be able to get a list of other changesets drafts or scheduled for publishing to open for additional edits.

Last edited 2 days ago by westonruter (previous) (diff)

@JoshuaWold
39 hours ago

Save and Publish - Option 2.2

#23 follow-up: @JoshuaWold
39 hours ago

  1. @westonruter if we go the non-linear route, what do you think about having the other changesets at the bottom of this panel? As shown in the attachment above.
  1. Would we want to give the ability to edit/delete settings?
  1. If I change the changeset to "save draft", what do you think about having the option to set the title show?

#24 in reply to: ↑ 23 @westonruter
35 hours ago

Replying to JoshuaWold:

  1. @westonruter if we go the non-linear route, what do you think about having the other changesets at the bottom of this panel? As shown in the attachment above.

Yes, having a list of the other changesets here I think makes sense. Note that this list would naturally tie in naturally with adding changeset revisions to the Customizer, as a draft/scheduled post are essentially revisions that have not yet been published/committed yet. See #21666 and #31089.

  1. Would we want to give the ability to edit/delete settings?

Yes, in that it would allow a user to switch to that changeset to make additional changes. In other words, it would be like in the Customize Snapshots plugin how you can navigate to the list of changesets in the WP Admin and click “Customize” to open it in the Customizer to make additional changes. The UI for reverting a change from a changeset I think would be integrated somewhere else, like within each control for which there is a changed/dirty setting there could be a revert button, but that can come in a future release. (This capability exists in Customize Snapshots today by “inspecting” a changeset in the WP Admin edit post screen and clicking the “Remove setting” links.)

  1. If I change the changeset to "save draft", what do you think about having the option to set the title show?

See also this issue in Customize Snapshots where the title could potentially default to a list of the controls that the user interacted with.

Being able to specify the title for the changeset would be I think important if we go with implementing branching/non-linear changesets. But then again, if we do implement branching changesets then what we're going to inevitably come up against is conflicts between two separate changesets. So part of me thinks that we should go with the linear option for 4.9.

But with the linear option, if there can only ever be one non-published changeset at once, would this be inherently problematic for drafted and scheduled changesets? If I schedule some changes to go live on Saturday night, and today is Thursday, then this would basically block the Customizer from being used to make changes until that changeset is published since you'd open the Customizer with the scheduled changeset loaded in. This wouldn't be a problem for branching changesets, but then there would be the issue of how to handle (or not handle) conflicts between two unpublished changesets. Some options for conflict resolution have been explored/discussed in Customize Snapshots, including adding indicators on controls for which there are other changesets which have pending changes. Potentially such controls could be “locked” from being edited, like post locking, if there is another changeset already has its setting as being modified. Anyway, there would be some interesting challenges to solve here.

Note: See TracTickets for help on using tickets.