Style Revisions: Remove the dropdown menu

[apeatling]

We currently have a dropdown menu that contains two items, it feels unnecessary and redundant considering other buttons here have no dropdown:

---

We can move all of this information into the style revisions sidebar view.

• Move the "Reset to defaults" action as a link under the intro text.
• Move the revisions count from the menu to next to the title in the sidebar
• Make sure the style revisions button is toggled on when it is selected

---

Here's my suggestion for how this could look:

[richtabor]

Move the "Reset to defaults" action as a link under the intro text.

We could put it in the styles vertical ellipsis menu, like we do for template resetting. And use the "Reset styles" copy, which matches what the command center uses (for styles and for templates).

[richtabor]

Is there another way to get to style revisions? Wondering if we need that back arrow next to "Revisions", if the panel is toggled via the "clock" icon.

[apeatling]

The back arrow is really awkward in its current state in trunk. It takes you back to the main global styles sidebar, but you don't get there with the reverse animation. I think we can remove it. I'm not aware of other ways to get here.

[apeatling]

Should the last item "Default styles" in the revisions history also be called "Reset styles"? It's essentially the same action.

[richtabor]

Should the last item "Default styles" in the revisions history also be called "Reset styles"? It's essentially the same action.

Good question. As everything else is a timeline event, it should probably be labeled as such too. It could be fine to have it be a time/date stamp with "{themeName} activated" even.

[richtabor]

While we're at it (though a bit off topic), I don't think we need the "Apply" button and corresponding modal at the footer. It does the saving flow, but not the full deal, like you get when you hit "Save" in the header, or in the site editor sidebar.

If we do keep it, "Apply" should probably be "Save", and it should use the proper save modal. Though I think it'd be nice to remove the loose end, and rely on the existing save patterns (that are also stronger and less scary).

[ramonjd]

While we're at it (though a bit off topic), I don't think we need the "Apply" button and corresponding modal at the footer. It does the saving flow, but not the full deal, like you get when you hit "Save" in the header, or in the site editor sidebar.

Clicking on a revision item provides a preview in the revisions window only.

The "Apply" button loads the revision into the current editor state and therefore the editor canvas, which is a separate entity and sits below the revisions window.

This separation is important as users can preview revisions before loading them into the editor, where the change counts as a document edit.

I'm hopeful there's an alternative UI or even different messaging that would improve the UX here. Perhaps there's a neat way to have two functions, that is, "apply without save" or "apply and save". 🤷🏻

I'm convinced that something will become obvious as we work through the ideas in #55776

If we do keep it, "Apply" should probably be "Save", and it should use the proper save modal. Though I think it'd be nice to remove the loose end, and rely on the existing save patterns (that are also stronger and less scary).

There was some testing around immediate saving in the initial PR.

The "Apply" button triggers a dirty state and therefore enables the Save button, and it also affords the user the opportunity to edit the revision changeset before committing it to save (and creating another revision entry).

The save flow contains other dirty entities as well, such as template edits. It's why the "Restore this revision" paradigm (load and save a single, historical state) of the WordPress code diff revisions.php page is tricky to migrate.

Another question we had in mind was, if the revisions panel did trigger a save flow, would we want the entire save flow, or limit the entities to global styles seeing as the revisions panel's explicit focus is global styles? Seems like that just complicates things. I'm not sure, but in my mind, the save flow belongs to the editor.

[ramonjd]

Just thinking more about this, maybe clicking "Apply" should close the revisions panel and take the user back to the editor (with the new changes applied)? Could that be an interim measure until we work out a better way?

Forget that, that's the way we already did it 🤦🏻 but it doesn't seem to do it all the time. I'll look into harmonizing it.

• Global Style Revisions: ensure consistent back button behavior #55881

[apeatling]

I'm working on this one 👍