Customizer: Allow users to Draft changes before Publishing

[melchoyce]

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

[folletto]

Customizer Advanced Publishing Options i1

[folletto]

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.

[karmatosed]

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.

[westonruter]

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.

[westonruter]

@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?

[melchoyce]

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.

[westonruter]

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)?

[melchoyce]

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.

[jbpaul17]

Punting to 4.8.1 per bug scrub earlier this week.

[JoshuaWold]

Save and Publish - Option 1

[JoshuaWold]

Save and Publish - Option 2

[JoshuaWold]

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”

[westonruter]

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.

[JoshuaWold]

Save and Publish - Option 1.1

[JoshuaWold]

Save and Publish - Option 2.1

[JoshuaWold]

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.

[westonruter]

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.

[JoshuaWold]

Save and Publish - Option 2.2

[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.

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

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

[westonruter]

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.

2. 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.)

3. 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.

[melchoyce]

Two things:

• Could we start more minimally, without the ability to preview/trash concurrent changesets? I think 2.1 is a good first step.
• Can we use a different word? I had zero idea what "changeset" meant until it was actually explained to me. Can we just call them drafts in the UI?

[JoshuaWold]

Save and Publish - Option 2.4

[JoshuaWold]

1. Is pending review conditional on the workflow? For instance, does it only show up if I’m not authorized to publish? Or could it also be used by people who have publish authority?

2. Showing other changesets in the panel - The work done on #21666 would make a lot of sense to incorporate. I’ve started by pulling in some of the UI elements. What if we have the changeset title default to the date/time for now, and later we can look at using the labels from their settings? (​https://github.com/xwp/wp-customize-snapshots/issues/152)

3. Editing changesets - Good points, I like starting simple for now. I’ve added a “Customize” button to each changeset which will allow you to open that changeset and show it’s active status with a checkmark. The publish/schedule status of each changeset can be viewed by expanding them.

4. How we’d handle conflicts - Agreed that this needs to be figured out. Not sure the best approach yet.

---

Could we start more minimally, without the ability to preview/trash concurrent changesets? I think 2.1 is a good first step.

I’m ok with getting something simple out the door and then revisiting.

Can we use a different word? I had zero idea what "changeset" meant until it was actually explained to me. Can we just call them drafts in the UI?

I’m good with that. Any concerns @westonruter ?

[westonruter]

Replying to JoshuaWold:

Can we use a different word? I had zero idea what "changeset" meant until it was actually explained to me. Can we just call them drafts in the UI?

I’m good with that. Any concerns @westonruter ?

That's fine, or also maybe talking about “drafted changes”, “pending changes”, and “scheduled changes” would work well. The word “changes” seems like a simple user-facing equivalent term to “changeset”.

[melchoyce]

"Changes" is definitely more clear, though why introduce a new word when we already have the concept of drafts in core?

[westonruter]

@melchoyce I suppose it is to help distinguish what exactly is being drafted. It isn't a post draft. Also, by using “changes” then we'd have a way to talk about it being scheduled: “draft changes” vs “scheduled changes”. Not sure how we'd talk about something being scheduled without some noun to describe.

[folletto]

Customizer Advanced Publishing Options i2

[folletto]

Hi people! Sorry for my delay in replying. I've caught up (I hope) with the discussion above, and provided a i2 design that hopefully converge the point we preferred — in the design however I also introduced a couple of differences, so let's review:

1. The label is changed from "Status" to "Action". I had the impression that "Status" wasn't very clear, as it might imply status of... something? Given instead it changes the action that the user is about to make clicking the button, I thought "Action" would be clearer.
2. Finding a name is hard. I used in this design "customization" since it seem fitting with all the scenarios: it's unique, it's semantically meaningful, and it can be paired with other words: "customization draft", "scheduled customization", and so on.
3. I added back the "current live customization" date and author. I think it can be very valuable, but feel free to ignore if the data isn't there or if you don't feel it's relevant now.
4. I wasn't sure what the checkmark or the UUID was in the opened customization draft: I think the date is already the one above, and I feel the URL would be more useful there as a reference, and... isn't the URL already the UUID? double win?
5. I feel the title there adds too much complexity. Why not make the customization draft title editable from the list below? In that way the default date/time would do, but if more specificity is needed, it's something the users could do later. Skipping this for now seems to me also matching better the current iteration of the work, but again, maybe not.
6. I used ••• instead of the chevron as the chevron implies a dropdown of some form. This would be a new pattern, so I feel it should be using a different icon. That said, it's minor, so if there's a preference for the chevron, or the cog as per the latest above, or another icon entirely, it's fine too. :)

Everything else should be as you discussed and mocked... if not I might have just missed it, sorry!

I hope this mockup makes sense. :)

[JoshuaWold]

Replying to folletto:

Great work pulling this together. You brought up some great points and are also trying to keep things simple for the first iteration.

[JoshuaWold]

Howdy! I'd like to share an update.

• I've created a ​clickable prototype based on the design from @folletto above and some discussions with @melchoyce and @westonruter.
• Also, here's a ​screencast walking through the prototype.

Would love feedback.

As of right now here's a few things that need to be done:

Date picker

We need to decide whether scheduling in the customizer will follow the same convention as the ​WordPress admin, or whether we could improve on that. One of the ideas suggested has been to add a date picker.

Here’s some directions we could take with that:

• ​Calendar date picker inside the Customizer panel (matches how Calypso in WordPress.com works)
• ​Calendar date picker with keyboard accessible input, also discussed ​here.

@afercia brought up accessibility concerns about datepickers in general and what advantage they offer over default input fields.

So it seems that any solution chosen should have (at the very least) a fallback to entering input fields.

Open to thoughts on this!

Save and Publish button flow

We need to figure out the flow of the save/publish button when scheduling a draft. Here I propose how the flow could work: ​https://v.usetapes.com/iBRTo9jNJz. But, based on feedback from Weston, we need to consider the following:

What happens to the grayed out blue scheduled button when a user makes an additional change? Doe the button become enabled again or auto-save (not desired). The explicit action of clicking the button is how we are able to create a revision.

There’s currently a ​Slack thread in Making WordPress Slack discussing this issue, feedback is welcome!

Wording for Customization/Drafts/Changesets

There's been some additional discussion around what word should be used to define revisions/changesets, etc. Definitely open to playing with the word, but I'm concerned that "snapshot" or "revision" might be more ambiguous than "Customization". The idea of just not including the word at all is interesting (as proposed by Nick Halsey).

[JoshuaWold]

To further the calendar/date picker discussion, I'm thinking for the sake of the 4.9 release that we should just keep the design similar to the WordPress admin and come back to this point later.

It seems like a bigger issue than I was originally thinking.

So, unless there are objections I'm going to plan to keep the prototype without a calendar date picker for now.

cc @melchoyce for feedback.

[dlh]

One experience that stuck out to me in the clickable prototype is that after I opened the scheduling tools with the "•••" button, I first tried to close it with the "X" in the left corner.

My guess is I thought to do that because the scheduling tools appear on top of the default controls, and so I thought the "X" was closing that layer, so to speak, instead of the whole Customizer? I'm not quite sure, and, of course, my experience is not generalizable. But I did wonder whether the scheduling tools are intended to eventually live in a WP_Customize_Panel (or _Section)?

[westonruter]

Replying to dlh:

But I did wonder whether the scheduling tools are intended to eventually live in a WP_Customize_Panel (or _Section)?

At first I was thinking that they'd be in some new kind of meta panel that is not part of the panel or section API, but now that I think about that more maybe not. It could be a regular section that is unique in that it doesn't have a normal menu item that you click on like the other items. It could instead be triggered to expand via a button in the header area. It could also perhaps slide in from the left in the same way that the Themes section does.

[JoshuaWold]

Based on a ​Slack discussion, the proposed feature list that we'll try to get into WordPress 4.9 is:

4.9 release

• Save draft button - Add dropdown under publish with “save draft” (like Customize Snapshots but removes naming changesets, save pending in dropdown, and scheduling)
• If I save a changeset, leave the Customizer, and come back in the previously saved changeset is autoloaded, and trash icon appears (tooltip: delete draft)
• If I make changes, don’t save, and leave the Customizer, when I return a notification asks if I want to restore the previously autosaved auto-draft. If the notification is dismissed, the auto-draft is deleted (look at Trac #35210 for inspiration)
• When I’m working in Customizer, and save a draft of my work, if I make further changes the blue button is hijacked periodically and says “saving > saved” and stays in a grayed out state until a further change is made, then it goes back to “save draft” and the process repeats if I keep making changes
• Include the “view changes on frontend” link from Customize snapshots

Sometime after 4.9

• Update the scheduling flow, consider ​https://cloudup.com/ckGE1FGwJ_J, save and publish button flow section from: https://core.trac.wordpress.org/timeline?from=2017-09-06T20%3A31%3A28Z&precision=second
• Don’t include calendar UI for now https://core.trac.wordpress.org/timeline?from=2017-09-06T21%3A02%3A32Z&precision=second until we can solve the accessibility issue
• Keep “customization” word for now unless we can come up with an alternative

cc @westonruter and @melchoyce for validation

[melchoyce]

Replying to JoshuaWold:

Based on a ​Slack discussion, the proposed feature list that we'll try to get into WordPress 4.9 is:

4.9 release

• Save draft button - Add dropdown under publish with “save draft” (like Customize Snapshots but removes naming changesets, save pending in dropdown, and scheduling)
• If I save a changeset, leave the Customizer, and come back in the previously saved changeset is autoloaded, and trash icon appears (tooltip: delete draft)
• If I make changes, don’t save, and leave the Customizer, when I return a notification asks if I want to restore the previously autosaved auto-draft. If the notification is dismissed, the auto-draft is deleted (look at Trac #35210 for inspiration)
• When I’m working in Customizer, and save a draft of my work, if I make further changes the blue button is hijacked periodically and says “saving > saved” and stays in a grayed out state until a further change is made, then it goes back to “save draft” and the process repeats if I keep making changes
• Include the “view changes on frontend” link from Customize snapshots

Is the proposed UI sketched out and mocked up somewhere? It seems we're veering away from clear drafting and revisions and more into the Customize Snapshots plugin, which IMO is not very intuitive or user friendly.

[JoshuaWold]

Is the proposed UI sketched out and mocked up somewhere?

I'm going to work on that now in a quick sketch and see if it makes sense.

[melchoyce]

Replying to JoshuaWold:

Is the proposed UI sketched out and mocked up somewhere?

I'm going to work on that now in a quick sketch and see if it makes sense.

Thanks 👍

[JoshuaWold]

@melchoyce and @westonruter I've attached the 4 scenarios described above in the proposal for what could make its way into WordPress 4.9.

[afercia]

Worth reminding navigation through panels in the customizer sets the initial focus on the "Back" button:

thus, everything that comes "before" is basically "skipped" and hardly discoverable for keyboard users and especially screen reader users. This is a long standing issue in the customizer and maybe worth revisiting a bit how it works :)

About the split button, it will need some special a11y treatment and I'm confident it can be built with a decent level of accessibility. It would be nice to build it as a re-usable UI component, as something similar is already used in Press This and it was proposed also as enhancement for the Add Media button.

[melchoyce]

I think we're starting to move away from the right solution here, the more we focus more on changesets and less on drafting.

For example, the trash can — I've asked a couple people this morning what they think it does and I've gotten a range of answers:

Deletes my site

i would expect every change i'd made since the last time i clicked Save & Publish to be reverted. i could also see how some might expect it to revert every change they'd made since entering the Customizer in that session, even if they clicked Save & Publish at some point.

I don’t think it would delete my site, which is my gut reaction. That option being disregarded, I would guess it means that I lose the changes I’ve been working on. but I don’t know what to guess. I’m confused mainly. I’m confused because it’s an odd mix of interactive customizer work and change/save work. if the publish button is there, I expect that to be “save”, trash as “cancel” - but if I don’t save, I also expect to lose my changes

no idea! maybe “delete all my customizations and revert back to default”? but that’s really just a guess. and I don’t think a trashcan is a good icon for that action. trashcan means “remove/delete” there is nothing to delete in the Customizer, that’s the problem - they’re just settings

I would imagine the changes would not be saved. If I’d made changes to anything I would expect those changes to be reset, but I would not expect any previously saved/published changes to be reverted. And if it matters/helps - I would only expect previously saved/published changes to revert to the original state with the use of a button/command labeled “reset” and a confirmation modal. Anything less would enrage me. Well, as much enraging as I do these days which is more of a FFS.

great question. x feels like it would close + cancel my changes. if i had an element selected, i would think the trash would delete that? but feels weird to be way over there next to the publish icon

Hm. I hope it wouldn’t delete my site. But there’s a publish button next to it. But I’m working on my site, not a post. Maybe it would delete any changes that I had “customized” but not yet published? Kind of like a reset back to the latest saved version?

This is one of the reasons I'm still struggling to wrap my own head around changesets. They seem like revisions with superpowers, and even regular post/page revisions can be a little confusing in WordPress. Changesets seem to be bringing in yet another layer of complexity to a tool which is already quite difficult for newer users to figure out.

Let's think about the user experience of drafting changes to your site design, without assuming that Customize Snapshots is the correct solution.

If we didn't already have this idea of changesets, is this how we'd design this feature? If the previous proposal is too complex for 4.9 — which is fine, I'm cool with reducing scope — then let's focus on doing one thing really well. Using concepts that most people will be able to understand without prior experience will help us accomplish that.

[westonruter]

@melchoyce I don't really see how changesets are being newly in focus here. I think it's even less about changesets then previous designs because it's the linear model discussed above. (There's no branching changesets shown, or UI for managing multiple changeset drafts concurrently.) It's just giving user control over managing a single draft of changes to the Customizer, being able to get back to the changes they were making before, and be able to eliminate/revert the changes to start over.

The trashcan icon was intended as a way to just abandon the changes you've been making, to start over. It's the reset/revert/start-over. That wasn't accounted for before in the Customize Snapshots plugin either or in the Customizer generally. Maybe a revert/undo icon would be better.

Otherwise, I don't see the new mockup scenarios as being much different than what was previously designed, other than being a subset of the functionality in the most recent designs: no “non-linear”/branching changesets, no scheduling, no revisions list, and no new panel with options to open. To me it does seem like it is focused on doing one thing really well: drafting changes.

---

I agree that (branching) changesets are indeed like like revisions with superpowers. Actually, it's essentially the “post forking” concept that was popular for awhile, but for forking changes to your entire site instead of for a single post and then merging the changes back to go live on the published site instead of the original post. That is a hard thing to newer users to grasp, so maybe it should remain in a feature plugin like Customize Snapshots if we can never find a way to add it to core in a way that makes sense for the majority of users. That may mean that scheduled changes never come in either, since really having a scheduled change somewhat precludes there being multiple concurrent changesets (branching/non-linear) since you'd probably want to new draft changes while you have a previous set of changes already scheduled.

[melchoyce]

If we're concerned with letting people undo and redo changes, we should consider #21666. Otherwise, if we're just planning on focusing on drafting, I think we should simplify down to:

1. Make changes to your site
2. Choose "Save Draft" option, rather than "Publish" (I think the split button is probably still best for this, if we're staying simple)
3. When you're ready to push up your changes, switch back to "Publish"

Or:

1. Make changes to your site
2. Decide you don't want to make those changes anymore, and either reload the Customizer or leave it
3. On reload/return to the Customizer, show some sort of "hey, you didn't save your changes last time, want to restore?", but otherwise load your last published version.

No trash. No "preview changeset" in the sidebar footer.

(Essentially, now that I'm re-reviewing the whole thread, this is what I originally proposed in customizer-drafting-i1.png​.)

---

That is a hard thing to newer users to grasp

That is hard for me to grasp, tbh.

That may mean that scheduled changes never come in either, since really having a scheduled change somewhat precludes there being multiple concurrent changesets (branching/non-linear) since you'd probably want to new draft changes while you have a previous set of changes already scheduled.

Folks might want to, but we don't have to allow them to. We can choose to keep it linear for the sake of simplicity. If we want to include previewing and scheduling, I think we're better off refining what @JoshuaWold and @folletto were previously exploring. However, I'm totally fine with punting those features from 4.9 if we can't get them done in time.

[westonruter]

To summarize our DM chat in Slack, we are OK with having scheduled changesets in with the linear flow. In other words, in core there will still only ever be one pending set of changes (a single customize_changeset post), whether those changes are drafted or scheduled for publishing. Once changes are scheduled for publishing, then the user would not be able to publish new changes in the Customizer until those scheduled changes go live. This would be the same behavior as scheduling a page for publishing, in that can't make parts of it published when it is that scheduled state. Changes made in the Customizer would autosave on top of a draft changeset and scheduled changeset alike.

So we'd be moving forward with ​https://xd.adobe.com/view/95393ea0-df5e-4530-878b-5dfc39dcf59d/ but without the “Customization drafts” section.

Replying to melchoyce:

If we're concerned with letting people undo and redo changes, we should consider #21666.

Yeah, that's a good point. The trash icon just seemed to me to be something that was missed, so that's why I suggested it. But there are other ways to workaround not having it as you suggested.

The main thing left then to nail down is this part:

On reload/return to the Customizer, show some sort of "hey, you didn't save your changes last time, want to restore?", but otherwise load your last published version.

I think this is what @JoshuaWold depicted in 4.9 release - Scenario 3.png. Leaving the Customizer via closing it would be the way. If the user made changes but didn't save them, and the changes are in an auto-draft changeset, then the next time the user comes back they'd be prompted to load up the Customizer with that changeset applied. Otherwise, if they discard then the auto-draft is deleted.

Otherwise, if the user previously saved or scheduled the changeset, then when they return to the Customizer the next time then that previous changeset is autoloaded into the Customizer for them to continue making changes. There would be no way for them to abandon the changes, other than to individually undo the changes the they had saved previously (if they can remember them?) To abandon those changes, we'd need to implement #21666, which possibly could be incorporated into the new panel, perhaps as a “Discard pending X changes”, where X is the number of settings in the changeset.

Additionally, this new panel that contains the status, scheduling, and preview link can make use of the “forward arrow“ to go back as depicted in https://core.trac.wordpress.org/attachment/ticket/40278/customizer-theme-uploads-i1.png

An additional change to the prototype would be that the list of statuses should be changed to be:

• Publish
• Draft
• Schedule

And the schedule area with the datetime picker should then only appear if “Schedule” is selected. There would not be a need to have an Edit button for scheduling. The fields could just always appear when Schedule is selected. Un-scheduling a changeset would consist of just switching to Draft or Publish statuses.

[melchoyce]

Chatted with @westonruter and we feel good about the above

I'll add some quick sketches over the weekend to keep us moving.

[westonruter]

One additional consideration regarding drafting and scheduling in themes that are not active yet: changesets cannot currently be scheduled (at an architectural level) for themes that are not active, since the settings that are defined in the non-active theme are not loaded when WP Cron runs to publish the scheduled changeset.

So currently if you are previewing a theme switch, then the Schedule option would initially have to be hidden until we implement #39031 and #22880. A summary of that problem I have in a doc:

Allow theme switches to be scheduled along with the publishing of other settings, also to preview theme switches on the frontend by unauthenticated users. — The customizer currently treats the previewed “theme” as a separate out-of-band thing that is not included as a setting. The previewed theme lives outside the customized state. This means that a customize preview for a theme switch can’t be safely shared with a non-authenticated user since the user would be able to load any theme they want which could be a security concern. Likewise, since the theme isn’t a setting in the changeset, scheduling a changeset to go live at a future date would not be able to also include the change to the theme. Consider a use case of wanting to schedule a Winter theme to a Spring theme, along with a change to the Site Logo to have flowers instead of snow.

It would be very cool eventually to be able to schedule a theme switch when this is resolved.

[melchoyce]

I have a preliminary exploration for preview here: ​https://cloudup.com/c5CJ_FWnXf4

Going to try to work on this some more tomorrow while traveling.

Still to do:

• Notate my wireframes so y'all know what's going on
• Explore the autosaving flow
• Sketch out the leaving-without-saving flow, which is pretty much exactly how @JoshuaWold already sketched it out
• Should we add a link at the bottom of the panel to revert to your current set of changes? Or nah? (Probably something like the history/revisions icon and a label like "revert back to my last save & publish" or "get rid of my current changes" or something)

[westonruter]

In 41368:

Customize: Add rightward-facing back button to Themes section header to improve navigation (since the section slides in from the left).

Also serves to prototype for an upward-facing arrow in this location for a Publish Settings section.

Props melchoyce, westonruter.
See #39896, #40278, #21666.

[westonruter]

@melchoyce Video of rightward-facing back arrow added to Themes section in [41368]: ​https://youtu.be/Feqfj9ErEXU

[westonruter]

I'm working on getting the notifications area patch completed and committed so we can make use of it for this ticket. See #35210.

[melchoyce]

Replying to westonruter:

@melchoyce Video of rightward-facing back arrow added to Themes section in [41368]: ​https://youtu.be/Feqfj9ErEXU

I'd say ship it but you already have 😆

[westonruter]

Putting together a list of tickets that may or may not get resolved (maybe partially) in the course of completing this ticket:

• ✅ #35210: Add notification area to Customizer
• ✅ #37727: Allow for customize control notifications to have extensible templates
• ✅ #37269: Introduce removed event for wp.customize.Values collection
• ✅ #31582: Catching PHP Fatal Errors on WordPress Theme Customizer
• #39275: Improve wp.customize.previewer.save() for changesets.
• #28721: Scheduled changes for the customizer
• #21666: Customizer reset/undo/revert

Some of these tickets have patches, so they can be leveraged.

[westonruter]

In 41374:

Customize: Add global notifications area.

• Displays an error notification in the global area when a save attempt is rejected due to invalid settings. An error notification is also displayed when saving fails due to a network error or server error.
• Introduces wp.customize.Notifications subclass of wp.customize.Values to contain instances of wp.customize.Notification and manage their rendering into a container.
• Exposes the global notification area as wp.customize.notifications collection instance.
• Updates the notifications object on Control to use Notifications rather than Values and to re-use the rendering logic from the former. The old Control#renderNotifications method is deprecated.
• Allows notifications to be dismissed by instantiating them with a dismissible property.
• Allows wp.customize.Notification to be extended with custom templates and render functions.
• Triggers a removed event on wp.customize.Values instances _after_ a value has been removed from the collection.

Props delawski, westonruter, karmatosed, celloexpressions, Fab1en, melchoyce, Kelderic, afercia, adamsilverstein.
See #34893, #39896.
Fixes #35210, #31582, #37727, #37269.

[westonruter]

Initial progress on implementing autosave revision support in the Customizer: ​https://github.com/xwp/wordpress-develop/pull/256

Screenshot of notice warning added can be seen in autosave-notice.png​. I just copied verbatim the string that gets shown on the edit post screen.

Most of the remaining work is on the PHP side of things in the pull request:

• Querying for a user's recent auto-draft changesets if they don't have an existing one loaded.
• When the Customizer loads with a blank changeset UUID, grab the most recent draft or future changeset, and if one exists, use its UUID instead of generating a new one. This behavior would need to be able to be disabled to allow Customize Snapshots to be able to have multiple changesets living concurrently.
• Update admin-ajax endpoint to support the autosave_revision param.
• Delete the auto-draft changeset or a loaded changeset's autosave revision when dismissing the above notice.
• Load changeset data from autosave revision when autosaved param is provided.
• Delete an autosave revision when saving a changeset fully (as a draft, future, or publish).
• And more I'm sure…

For more notes on implementation, see first half of conversation in thread at: ​https://wordpress.slack.com/archives/C0381N237/p1504725296000135

[melchoyce]

Okay, uploaded drafting and scheduling.

Per yesterday's Slack chat, we've decided to cut any UI for autosaving: ​https://wordpress.slack.com/archives/C0381N237/p1505342651000160

Still planning on putting together an update for the exit-restore-changes-flow when I have time again this week. Also attaching an alternate layout idea that I explored, but am worried about making any big changes right now.

[westonruter]

Replying to melchoyce:

Per yesterday's Slack chat, we've decided to cut any UI for autosaving: ​https://wordpress.slack.com/archives/C0381N237/p1505342651000160

Just to add-on that while the UI for autosaving has been dropped, there is still a UI for having been autosaved. In other words, this is the notice which users are presented with after returning to the Customizer if they didn't explicitly save their changes: autosave-notice.png​.

[westonruter]

The PHP side of autosaving has been initially implemented and it is feeling good: ​https://github.com/xwp/wordpress-develop/pull/256

• If you go into the customizer on a fresh site and make changes, and then reload, you'll get a fresh blank Customizer when you reload but with a notice about restoring the auto-draft.
• If you open up the console and then do wp.customize.previewer.save({ status: 'draft' }) (since there is no UI yet) and then reload, you'll automatically get the changeset auto-loaded from the start.
• If you make additional changes on top of a drafted changeset, and then reload, you'll get a notice about the autosave revision with a link to load those changes.
• In the same way that a user can only have one autosave revision, a user can also only have one auto-draft changeset. If you open the Customizer without any drafted changes existing, and you disregard the notice about there being an auto-draft available, as soon as you make a change and the new auto-draft is created, the previous one will be deleted.

This autosave part of things needs:

• A filter for plugins (like Customize Snapshots) to opt-in to non-linear changeset mode, and then using this filter to modify the behavior for whether the changeset_uuid param gets dynamically added to the location, whether a drafted changeset gets auto-loaded, whether there can be multiple auto-draft posts living concurrently, and so on.
• User testing. One thing I'm not sure about is how best to deal with is when two users are working in the Customizer. If they both have changes auto-drafted, and then user A clicks to save draft, if user B then reloads the Customizer then they will see the drafted changes auto-loaded from user A without the option for user B to restore their auto-drafted changes, until the changeset from user A is published. Maybe that makes sense, but it's just not something I considered before.
• Code review and overall evaluation of the architecture changes.
• Addition of PHPUnit tests. Existing unit tests pass, so the API changes seem to be backwards-compatible.

[westonruter]

@sayedwp In coding up the UI for this, I suggest:

• Create a new branch independent of the autosave work being done in the existing ​PR, since I do not think there are any key dependencies (other than a needed filter for configuring whether or not multiple drafted/scheduled changesets can exist concurrently).
• Register a new section for the “Publish Settings”. The priority can perhaps be 0 with the themes section getting bumped up to 1. In reality, it shouldn't matter the priority because I'm thinking that the “Publish Settings” section item wouldn't appear at all in the list of sections. It should instead be hidden, as the way to expand it would be via the gear icon next to the Publish button.
• The header for the publish settings section would get a back button that appears on the right with an upward arrow. See [41368] for how a right-facing arrow was added for the Themes section. I don't think we're all completely confident on this upward-facing button here (as clicking the gear icon again would also collapse the panel), but it's something we can try.
• It would be a great if the section expanded downward instead of sliding from the left (as Themes) or right (as everything else).
• The action/status radio buttons and scheduling datepicker can all be part of a single custom ​setting-less control. Or I suppose it would be best if the control actually could be connected with the wp.customize.state( 'changesetStatus' ), but that would depend on #37964. It would just be important to ensure that the control's state is linked with changesetStatus, so that if the changesetStatus changes programatically by a plugin that the selected radio also changes. There should likewise be a changesetDate state that is linked to the date/time picker. I believe you've already implemented something like this in the Customize Snapshots previously.
• The share preview link would be in a separate setting-less control.

All of this should be pretty familiar to you with your work on Customize Snapshots. Your experience with that feature plugin will also be key to identify areas in the core implementation where we need the hooks to ensure Customize Snapshots can continue extending the core UI to add the “power user” features, like being able to have multiple changesets drafted at a time, being able to give titles to changesets, and so on. 🙌

[westonruter]

@sayedwp For the frontend preview link, the ​logic from an existing PR by @stubgo may be able to be incorporated (particularly setUpPreviewLink and updateSnapshotPreviewLinkHref). Namely that if you click on the frontend preview link, the call to requestChangesetUpdate should be made first to ensure that all of the pending changes in memory are written into the changeset before the user tries previewing the changeset on the frontend with a GET request.

[melchoyce]

Uploaded a super rough and messy flow: Settings - Restore Autosave flow.png

[westonruter]

@melchoyce awesome, that is implemented now in the PR. I'm going to get it up on an environment for you to test, but if I explicitly click the close link should it not throw up a confirm() dialog, and if accepted, delete the auto-draft since you explicitly didn't want to save it? Otherwise, if you close the browser tab I'd consider that to be a non-explicit exit of the Customizer and in that case the notice would be presented for you to restore?

[melchoyce]

Replying to westonruter:

@melchoyce awesome, that is implemented now in the PR. I'm going to get it up on an environment for you to test, but if I explicitly click the close link should it not throw up a confirm() dialog, and if accepted, delete the auto-draft since you explicitly didn't want to save it? Otherwise, if you close the browser tab I'd consider that to be a non-explicit exit of the Customizer and in that case the notice would be presented for you to restore?

I'd keep it simple and always discard the autosave unless you explicitly say "restore," like with posts. I don't think we need a confirmation.

[westonruter]

Replying to melchoyce:

I'd keep it simple and always discard the autosave unless you explicitly say "restore," like with posts. I don't think we need a confirmation.

By close link I didn't mean to refer to the dismiss link on the notification itself, but rather the close X link to exit the Customizer. With posts there is a confirmation when you try to leave without saving. I'll amend the patch to show what I'm talking about.

[westonruter]

I've created the test environment: ​http://trac-39896-xwp-testbed.pantheonsite.io/#main

I can create test admin user accounts for anyone who is willing to test.

[sayedwp]

@westonruter Sure, thanks for the details, I will start work on it this Monday or may be tomorrow.

[paaljoachim]

Mel's Publish Settings - Drafting Flow.png is really good.
As it shows the additional saving options as a drop down directly in the Publish area. Publish, Save draft, schedule works well. The same feature should also be added to Gutenberg.

I am also thinking that there should be an Site Status panel that gives an extra confirmation of what is going on with the site:

Detailed view. As it opens up the opportunity to additional features later on.

Regarding moving the publish section to the right as in Mel's: Publish Settings - Alternate Layout.png pushes the publish area away from where the various settings are located. It creates a disconnection. (It also bring a top bar making the viewing space smaller.) The best place for it at present time as the customizer looks like it does is to keep it where it is and add the drop down.

[westonruter]

Some great work on the changeset status UI being done by @sayedwp in ​https://github.com/xwp/wordpress-develop/pull/258

@melchoyce Demo: ​https://youtu.be/Q2-n1LCOnbg

Note the Schedule option is not yet connected with a date-picker.

I've merged the two branches (autosave and UI) into a third branch which I've deployed to the test environment so you can play around with it: ​http://trac-39896-xwp-testbed.pantheonsite.io/#main

[melchoyce]

Awwww yeah ✌️

At what point would it be helpful for me to start giving some minor design feedback?

[sayedwp]

I am focusing to finish at least all the UI parts by the end of day. ( Its morning here )

[JoshuaWold]

@westonruter, @sayedwp, @melchoyce some feedback from testing:

——

Issue with scheduling

Seeing an issue when I try to schedule a draft, the same error whether it's a future date or past date.

Current behavior:

1. Made a change to the interface (light > dark)
2. Saved draft
3. Set date for scheduling, getting error “not_future_date”, when it is in fact a future date. ​https://v.usetapes.com/u4vLhYOlHy

Expected behavior

1. Make change
2. Save draft
3. Set date for scheduling in the future, and it works.

——

Change text of “not_future_date”

Currently if you schedule a draft in the past, you get an error “not_future_date”, we should probably make something more user friendly, like “Drafts can’t be scheduled in the past”

——

Changeable timezones in scheduling

Currently it’s set to schedule in the UTC-5 timezone. Can this be changed to my local timezone? It’s a bit of a challenge to figure out what that time is in PDT.

[sayedwp]

@JoshuaWold Its not ready for testing yet, in fact, the schedule date control is still in the todo list. ​https://github.com/xwp/wordpress-develop/pull/258#issue-258301501

[westonruter]

Replying to JoshuaWold:

Issue with scheduling

I can see that this is simply because the date is not yet getting passed when submitting the save request. I probably pushed up the changes for review prematurely and @sayedwp just hasn't gotten there yet.

Change text of “not_future_date”

Yes, this didn't have a translatable string before because it was not displayed in the UI. I've changed it to “You must supply a future date to schedule.” for now.

Changeable timezones in scheduling

It is confusing with timezones. However, it should have the same behavior as the edit post screen, which only takes into account the site's timezone regardless of what your timezone is.

One thing that will help here is to have the current date/time supplied as defaults so then you just have to increment the time as desired. Maybe it would be helpful in the error message to indicate just how far in the past the date you provided is.

[westonruter]

Bumping priority to high for visibility and alignment with 4.9 goals, and given proximity to beta 1 deadline.

[paaljoachim]

Here is another idea per discussion in #core-customize channel.

[bduclos]

Are you considering an import/export feature? Importing Customizer settings from one site to another would be amazing. If it's not planned, would the new features make it easier to implement it on my own?

[westonruter]

@bduclos The new features wouldn't really have any impact on the implementation of an import/export feature.

It is trivial to implement an export feature because it's simply a matter of exporting the contents of the customize_changeset post. Well, and any posts that may be referenced in that changeset.

The hard thing is importing a changeset. Settings for widgets and nav menus all make reference to auto-incremented IDs in their settings, and so importing a changeset would run the real risk of conflicting with existing changes on a given site. Importing a changeset in a way that does not conflict with existing content is what the starter content feature was designed to solve: #38114.

In order to export and import a changeset, it would essentially need to be able to “understand“ the structure of the IDs (e.g. nav_menu_item[123] and the structure of the values, like when page_on_front is set to 4, that the 123 in the former and the 4 in the latter are both references to post IDs. It's the same problem you get when trying to migrate parts of a database from one site to another existing database. This is a problem that ​VersionPress has been focused on heavily as well as ​Mergebot. There may be a way to leverage schema work done by these projects as a way to inform a changeset import/export tool. But it would be out of scope for this ticket.

[paaljoachim]

Hi @bduclos

I did a search and came across this plugin:
​https://wordpress.org/plugins/customizer-export-import/

[westonruter]

In 41597:

Customize: Extend changesets to support autosave revisions with restoration notifications, and introduce a new default linear history mode for saved changesets (with a filter for opt-in to changeset branching).

• Autosaved changes made on top of auto-draft changesets get written on top of the auto-draft itself, similar to how autosaves for posts will overwrite post drafts.
• Autosaved changes made to saved changesets (e.g. draft, future) will be placed into an autosave revision for that changeset and that user.
• Opening the Customizer will now prompt the user to restore their most recent auto-draft changeset; if notification is dismissed or ignored then the auto-draft will be marked as dismissed and will not be prompted to user in a notification again.
• Customizer will no longer automatically supply the changeset_uuid param in the customize.php URL when branching changesets are not active.
• If user closes Customizer explicitly via clicking on X link, then autosave auto-draft/autosave will be dismissed so as to not be prompted again.
• If there is a changeset already saved as a draft or future (UI is forthcoming) then this changeset will now be autoloaded for the user to keep making additional changes. This is the linear model for changesets.
• To restore the previous behavior of the Customizer where each session started a new changeset, regardless of whether or not there was an existing changeset saved, there is now a customize_changeset_branching hook which can be filtered to return true.
• wp.customize.requestChangesetUpdate() now supports a second with options including autosave, title, and date.
• The window blur event for customize.php has been replaced with a visibilitychange event to reduce autosave requests when clicking into preview window.
• Adds autosaved and branching args to WP_Customize_Manager.
• The changeset_uuid param for WP_Customize_Manager is extended to recognize a false value which causes the Customizer to defer identifying the UUID until after_setup_theme in the new WP_Customize_Manager::establish_loaded_changeset() method.
• A new customize_autosaved query parameter can now be supplied which is passed into the autosaved arg in WP_Customize_Manager; this option is an opt-in to source data from the autosave revision, allowing a user to restore autosaved changes.

Props westonruter, dlh, sayedwp, JoshuaWold, melchoyce.
See #39896.

[westonruter]

In 41603:

Customize: Dismiss all autosaved auto-drafts for user and not just the one suggested when dismissing restoration notification.

Amends [41597].
See #39896.

[westonruter]

In 41626:

Customize: Introduce drafting and scheduling for Customizer changesets.

• Incorporates code from the Customize Snapshots and Customize Posts feature plugins.
• Adds a new Publish Settings section for managing the changeset status, scheduled date, and frontend preview link.
• Updates Publish button to reflect the status selected in the Publish Settings (including Save Draft and Schedule).
• Deactivates the Themes section when a non-publish status selected, and deactivates the Publish Settings section when previewing a theme switch.
• Introduces an outer section type (wp.customize.OuterSection in JS) for the Publish Settings section to use and for available widgets and available nav menu panels to use in the future. These sections can be expanded while other sections are expanded.
• Introduces WP_Customize_Date_Time_Control in PHP and wp.customize.DateTimeControl in JS for managing a date/time value.
• Keeps track of scheduled time and proactively publish from the client when the time arrives, as opposed to waiting for WP Cron.
• Auto-publishes a scheduled changeset when attempting to access one that missed its schedule.
• Starts a new changeset if attempting to save a changeset that was previously publish.
• Adds force arg to requestChangesetUpdate() to force an update request even when there are no pending changes.
• Adds utils methods for getCurrentTimestamp and getRemainingTime.
• Adds new state values for selectedChangesetStatus, changesetDate, selectedChangesetDate.
• Fixes logic for when to short-circuit check to close Customizer when there are unsaved changes.
• Adds getter methods for autosaved and branching parameters, with the latter applying the customize_changeset_branching filter.
• Call to establish_loaded_changeset on the fly when changeset_uuid() is called if no changeset UUID was specififed.
• De-duplicates logic for dismissing auto-draft changesets.
• Includes unit tests.

Builds on [41597].
Props sayedwp, westonruter, melchoyce, JoshuaWold, folletto, stubgo, karmatosed, dlh, paaljoachim, afercia, johnregan3, utkarshpatel, valendesigns.
See #30937.
Fixes #39896, #28721, #39275.

[westonruter]

In 41649:

Customize: Improve interactions between the Themes panel and Publish Settings section.

• Deactivate the Themes panel immediately after changing selected status to non-publish.
• Animate publish settings button into view with publish button when collapsing Themes panel.
• Deactivate publish settings section and hide publish settings button entirely when customizer state is clean.
• Harden access of Themes panel in case it was removed by plugin.
• Fix throttling of renderScreenshots calls in ThemesSection.

Amends [41648], [41626].
See #37661, #39896, #34843.

[westonruter]

In 41650:

Customize: Remove unused JS variables to fix JSHint.

Amends [41649].
See #37661, #39896.

[bduclos]

CSS bug: for large screens, the new publish panel is overlapped by the controls panel.
Inside customize-controls.css, the following lines are missing:

@media screen and (min-width: 1667px){
    .outer-section-open .wp-full-overlay.expanded {
        margin-left: 18%;
    }
}

[westonruter]

Replying to bduclos:

CSS bug: for large screens, the new publish panel is overlapped by the controls panel.

Thanks. I've opened this as #42051.

[westonruter]

In 41667:

Customize: Add infrastructure for trashing/reverting of unpublished changes; introduce full-screen OverlayNotification for trashing and theme install/preview.

• Introduce a new wp.customize.previewer.trash() JS API to trash the current changeset, along with logic to WP_Customize_Manager to handle deleting changeset drafts.
• Add trashing to wp.customize.state which is then used to update the UI.
• UI for trashing is pending design feedback. One possibility is to add a new trash button to Publish Settings section that invokes wp.customize.previewer.trash().
• Improve logic for managing the visibility and disabled states for publish buttons.
• Prevent attempting requestChangesetUpdate while processing and bump processing while doing save.
• Update changeset_date state only if sent in save response.
• Merge ThemesSection#loadThemePreview() into ThemesPanel#loadThemePreview().
• Remove unused autosaved state.
• Start autosaving and prompting at beforeunload after a change first happens. This is key for theme previews since even if a user did not make any changes, there were still dirty settings which would get stored in an auto-draft unexpectedly.
• Allow Notification to accept additional classes to be added to container.
• Introduce OverlayNotification and use for theme installing, previewing, and trashing. Such overlay notifications take over the entire window.

Props westonruter, celloexpressions.
See #37661, #39896, #21666, #35210.

[westonruter]

In 41670:

Customize: Fix WP_Customize_Date_Time_Control to be re-usable for plugins and custom settings.

• Allow time fields to be omitted by constructing with timeIncluded as false.
• Ensure reportValidity is only called on a control when it is in an expanded section.
• Rename "ampm" to "meridian".
• Improve accessibility and fix HTML validation and style issues for both the date/time control and the preview link control.
• Fix styling of dropdowns and clean CSS.
• Improve accessibility of nav menus component.

Props westonruter, afercia, sayedwp, melchoyce.
Amends [41626].
See #39896.
Fixes #42022.

[westonruter]

In 41677:

Customize: Fix positioning of outer section (e.g. publish settings) on large screen sizes.

Also fix preview link CSS for desktop and mobile.

Props sayedwp, bduclos.
See #39896.
Fixes #42051.

[westonruter]

In 41694:

Customize: Add button in Publish Settings to discard unsaved changes (including drafted and scheduled), reverting Customizer to the last published state.

Props westonruter, melchoyce.
Amends [41667].
See #39896, #21666.

[westonruter]

In 41720:

Customize: Let establish_loaded_changeset query changesets from any author not just current user when determining which changeset to autoload in non-branching mode.

See #39896.

[westonruter]

In 41750:

Customize: Allow controls to be created with pre-instantiated Setting object(s), or even with plain Value object(s).

• Allow passing settings in keyed object (e.g. settings: { default: 'id' } ), or as an array (e.g. settings: [ 'id' ]) with first being default; again, Setting/Value` objects may be supplied instead of IDs.
• Allow a single setting to be supplied with just a single setting param, either a string or a Setting/Value object.
• Update changeset_status and scheduled_changeset_date to be added dynamically with JS and simply passing of api.state() instances as setting.
• Introduce a data-customize-setting-key-link attribute which, unlike data-customize-setting-link, allows passing the setting key (e.g. default) as opposed to the setting ID.
• Allow WP_Customize_Control::get_link() to return data-customize-setting-key-link when setting is not registered.
• Eliminate default_value from WP_Customize_Date_Time_Control since now comes from supplied Value.
• Export status choices as wp.customize.settings.changeset.statusChoices.
• Export date and time formats as wp.customize.settings.dateFormat and wp.customize.settings.timeFormat respectively.

Props westonruter, sayedwp.
See #39896, #30738, #30741, #42083.
Fixes #37964, #36167.

[westonruter]

In 41788:

Customize: Fix confusion related to visibility of Themes panel with drafted/scheduled changesets.

• Prevent autoloading an existing draft/future changeset when theme not active.
• Add missing notifications container to Themes panel.
• Remove deactivation of themes panel when selected status is not publish.
• Show notification in Themes panel when themes cannot be previewed and disable preview buttons.
• Reject installTheme call when theme preview not available.
• Return promise from installTheme and eliminate use of global events in favor of promises.

Props westonruter, melchoyce, zoonini.
See #37661, #39896.
Fixes #42126.

[westonruter]

In 41802:

Customize: Improve keyboard accessibility for publish settings section.

Props sayedwp.
See #39896.
Fixes #42027.

[westonruter]

In 41803:

Customize: Constrain focus when overlay notification is displayed.

• Restore previously-focused element when overlay notifications are dismissed.
• Allow notifications to be dismissed via keyboard.

Amends [41667].
See #42110, #35210, #39896.

[westonruter]

In 41824:

Customize: Introduce WP_Customize_Manager::trash_changeset_post() to reduce duplication and ensure proper changeset trashing logic.

Trashing a changeset via wp_trash_post() does not have the desired result since it mutates post_content (via Kses) and the post_name (even though it is a UUID).

Props dlh.
See #39896, #42030.
Fixes #42175.

[westonruter]

In 41826:

Customize: Make sure saved state is initially false when restoring autosave revision so that Save button will be enabled.

Amends [41597].
Props sayedwp.
See #39896.
Fixes #42143.

[westonruter]

In 41839:

Customize: Add changeset locking in Customizer to prevent users from overriding each other's changes.

• Customization locking is checked when changesets are saved and when heartbeat ticks.
• Lock is lifted immediately upon a user closing the Customizer.
• Heartbeat is introduced into Customizer.
• Changes made to user after it was locked by another user are stored as an autosave revision for restoration.
• Lock notification displays link to preview the other user's changes on the frontend.
• A user loading a locked Customizer changeset will be presented with an option to take over.
• Autosave revisions attached to a published changeset are converted into auto-drafts so that they will be presented to users for restoration.
• Focus constraining is improved in overlay notifications.
• Escape key is stopped from propagating in overlay notifications, and it dismisses dismissible overlay notifications.
• Introduces changesetLocked state which is used to disable the Save button and suppress the AYS dialog when leaving the Customizer.
• Fixes bug where users could be presented with each other's autosave revisions.

Props sayedwp, westonruter, melchoyce.
See #31436, #31897, #39896.
Fixes #42024.

[westonruter]

In 41860:

Customize: Fix positioning of device-previewed window when publish settings are open.

• Update date control padding.
• Collapse publish settings section when opening panes for available widgets or nav menus.
• Remove save and cog buttons in mobile preview only mode.
• Move definition of wp.customize.previewedDevice to wp.customize.state('previewedDevice') for centralization, maintaining old alias.
• Remove unused CSS because the section is inside form now.

Props sayedwp, westonruter.
See #39896.
Fixes #42027, #42199.

[johnjamesjacoby]

Updated "Publish" button needs styling in non-blue color schemes

[sayedwp]

Updated "Publish" button needs styling in non-blue color schemes

When the publish settings section opens, an active class is applied to it. And when the color scheme changes, the color should change by the color scheme, so it looks like this is underlying problem which should be fixed in a separate ticket.

The same thing would happen if we add active class to any button in WordPress admin.

[sayedwp]

Created a ticket #42236

[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.

[westonruter]

In 41932:

Customize: Draw attention to save button after collapsing the publish settings section when the changeset status or date had been changed.

Props bpayton, westonruter.
See #42114, #39896.
Fixes #42211.

[westonruter]

In 41947:

Customize: Prevent drawing attention to save button if status unchanged from publish; account for changes to status/date when alerting about unsaved changes.

Also fix malformed ESLint directive from [41933].

Amends [41932].
See #39896, #42211.

[westonruter]

In 41968:

Customize: Update 'Save & Activate' reference to 'Publish & Activate' in themes help tab text.

See #39896.
Fixes #42305.

[westonruter]

In 41969:

Customize: Keep frontend preview link updated to reflect the current state of previewed URL, active theme, and autosaved state.

See #39896.

[westonruter]

In 42025:

Customize: Register the Publish Settings section in JS to ensure it does not get unregistered via PHP.

The publish_settings section is a fundamental dependency for Customizer, so it must be guaranteed to be registered.

Also unconditionally register core types for panels, sections, and controls in case plugin unhooks all customize_register actions.

See #39896.
Fixes #42337.

[westonruter]

In 42042:

Customize: Allow 0:00-0:59 in date/time control when 24-hour time used.

• Let min hour be 0 and max be 23 in 24-hour time; let min hour be 1 and max be 12 in 12-hour time.
• Show error notification when an invalid date value is provided, not just when not a future date.
• Fix translation of custom validity message.
• Start checking for validity after all inputs have been initially populated.
• Remove support for being able to enter 24:00.
• Cease forcing date input elements from being casted to integers, to allow for invalid inputs to be detected.

Props westonruter, Presskopp, peterwilsoncc, atachibana for testing.
See #39896, #28721.
Fixes #42373.

[westonruter]

In 42108:

Customize: Prevent history.replaceState() and history.pushState() calls from causing error in customize preview before DOM ready.

Amends [41597].
See #39896.
Fixes #42414.

[westonruter]

In 42109:

Customize: Always use underlying changeset post date as initial date in scheduled date fields if date is future.

Prevent user from having to re-enter the previously-supplied future date if they had switched from schedule to draft but wanted to switch back again. Improves parity with behavior of post edit screen.

Props dlh, westonruter, obenland.
See #39896, #28721.
Fixes #42413.

[westonruter]

In 42113:

Customize: Make sure theme switch blocking in the Customizer is consistently applied when changeset is drafted/scheduled.

• Consider both selectedChangesetStatus and changesetStatus states when deciding to disable.
• Factor out common logic into canSwitchTheme function on ThemesPanel.
• Keep Live Preview and Install buttons disabled in Themes controls and detail overlays when appropriate.

Props westonruter, dlh.
Amends [41788].
See #42126, #37661, #39896.
Fixes #42406.

[westonruter]

In 42114:

Customize: Ensure changeset_uuid param for autosave auto-draft gets stripped from location after previewing theme switch when not in branching mode.

Amends [41597].
See #39896.
Fixes #42415.

[westonruter]

Dev note: ​https://make.wordpress.org/core/2017/11/03/new-features-and-enhancements-with-customizer-changesets-in-4-9/

[westonruter]

In 42118:

Customize: Prevent customize_autosaved=on from getting added to frontend preview URLs.

Amends [41969].
See #39896, #42450.
Fixes #42433.

[westonruter]

In 42144:

Customize: Ensure autosave revision is dismissed immediately after implicit restoration notice dismissal as done with explicit notice dismissal.

Fixes issue where a drafted/scheduled changeset could inadvertently re-use the previous autosave revision in the preview while a user expects it to have been dismissed.

See #39896, [41597].
Fixes #42502 for trunk.

[westonruter]

In 42145:

Customize: Ensure autosave revision is dismissed immediately after implicit restoration notice dismissal as done with explicit notice dismissal.

Fixes issue where a drafted/scheduled changeset could inadvertently re-use the previous autosave revision in the preview while a user expects it to have been dismissed.

See #39896, [41597].
Fixes #42502 for 4.9.

[westonruter]

In 42538:

Customize: Use changeset-specific "locked" messages when branching is enabled.

Props dlh.
See #39896.
Fixes #42655.

[westonruter]

In 42539:

Customize: Use changeset-specific "locked" messages when branching is enabled.

Props dlh.
See #39896.
Fixes #42655 for 4.9 branch.

[westonruter]

In 42615:

Customize: Ensure customize_autosaved requests only use revision of logged-in user.

Props dlh, westonruter.
See #42433, #39896.
Fixes #42450.

[SergeyBiryukov]

In 42620:

Customize: Ensure customize_autosaved requests only use revision of logged-in user.

Props dlh, westonruter.
See #42433, #39896.
Merges [42615] to the 4.9 branch.
Fixes #42450.