Full site editing: The UI should provide a way to revert a template part to its default state

[jameskoster]

Hopefully we can borrow much of the work done in #28141 to accomplish this.

The one difference here is that it should probably be possible to revert a template part while editing a template, or editing the template part directly in isolation.

• Revert while editing the template part in isolation. Design in this comment.
• Revert while editing the template part parent. Design in this comment.

[0aveRyan]

This seems critical to FSE's inclusion in WordPress 5.8. The Site Editor encourages users to edit templates and users should have a way to revert to the author's original intent and upgrade to updated Theme changes.

It seems a minimally-viable to-do is to at least notify users when an update to their Theme contains an updated template file to one of their custom wp_template's stored in the database.

As-is, Theme Authors cannot safely release refactored stylesheets or block templates without risking a user not knowing updates are available or worse perhaps breaking a site (if a developer changes a css selector .old to .new in a stylesheet, updates the filesystem template, pushes new version and a user has .old stored in the database it could break their live website until they revert or figure out how to reconcile their custom modifications with the new template).

Long-term we need to think about how to help Theme Authors and Users safely merge changes, but an MVP is notifying users that Theme v1.5 contains template changes from their prior v1.4.1 they originally extended. This would probably mean saving the filesystem template as a revision anytime a user modifies in the site editor, such that it can be compared with their modifications and the filesystem version to detect a change upon Theme update.

[jameskoster]

Yeah, theme updates (and to a lesser extent theme switches) all need careful consideration. I would encourage you to open issues to discuss details of the update flows since reverting will likely only be a small part of a much larger overall experience.

[aristath]

I posted the same reply on Slack where this was discussed, but posting here as well for posterity.
Since a template is just a collection of blocks, when a theme gets updated it doesn't matter what changes the theme does... Theme templates are just "presets", that the user can then customize if they want.
If a site-owner has customized their templates, then they want these templates to stay as they are, and their work shouldn't be lost when the theme gets updated.
The theme doesn't provide any CSS selectors, so nothing can really "break"... it's all just blocks. The selector for a header wrapper group will always be header.wp-block-group
But even if that wasn't the case, classic themes have that issue and it never was a blocker... child themes need to be maintained and tweaked on each update of the parent theme, and so does any custom-CSS the user has added in the customizer.
If anything, the FSE paradigm is a significant improvement over these classic implementations 🙂

[jameskoster]

Circling back to the OP, I think we can reuse the exact UI that has been merged for Templates to satisfy this requirement:

[0aveRyan]

@aristath I hear what you're saying and I agree with much of it. However, I do think this differs from the existing parent/child scenario in a way that affects both "Clear customizations" that @jameskoster originally pointed out and the separate but related issue of "updates available."

• The barrier to entry for customizing a Theme is being radically lowered here. We are encouraging and empowering users to modify presets. Where a much smaller pool of sites customized parent/child in the past, it is likely to invert to be the majority.
• I disagree the Theme doesn't provide CSS selectors. It seems highly likely Themes can and will offer Block Styles. What raised this issue to me was developing a Block-Based Theme where I changed the Block Style selector in JS registration and the preset markup, but saved markup naturally didn't receive the update. Plus, we can encourage use of the theme.json all we want, try to educate Theme developers about this risk, but some designers will want to continue leveraging traditional stylesheets and the cascade.
• If a Theme Author makes substantial changes to a preset, ideally a user should know about that. Both to perhaps benefit from enhancements, but also "Restore template to theme default" wouldn't necessarily be restoring, it would be upgrading. If a user made a tiny tweak to v1 of a preset (i.e. changing a spacer block from 25px to 20px) and they click Clear customizations and it radically changes their header to v2 of that preset on the filesystem, it's easy to say that's upgrade without warning or consent. Revisions will help here, but I think it would be much better to warn users before it's a problem they're trying to revert. We wouldn't need to store every delta change to a preset, just the original a user modified from as a revision.

We can move this discussion to another ticket, however this issue is tightly coupled to "Clear customizations."

FSE is a powerful, intuitive and effective tool -- particularly to users already comfortable with Gutenberg. I think users will make excellent use of it. That's why I worry this could be a problem. It's both an issue for Theme Developers to release iterative updates and a UX issue for Site Owners who unknowingly could upgrade/not be aware of changes the Theme Author released.

[jameskoster]

I shared a concept in #30773 (comment) for reverting a template part while editing the parent template. I think it would be worth adding that here.

We'd need #29147 to land first.