Add ability to turn off double confirmation multi-entity saving screen

[annezazu]

What problem does this address?

This came up in the latest FSE outreach program's All Things Media exploration:

I kept wanting to be able to turn off the double confirmation in the Site Editor. It was like, yes, I’m aware I probably edited multiple parts, I know what I’m doing and I want the option to turn that off if I want. I went looking for the Preferences panel instinctively despite knowing that there wasn’t one there yet.

In the post editor, there's this option but we like the same one in the site editor:

What is your proposed solution?

This likely could be seen as part of site editing UI parity: #21245.

The only concerns on my mind are around what else might be added to this saving flow. For example, some items like saving edits as a new template are being explored before the multi entity step ideally: #27851 whereas others like draft/scheduling changes are being explored design wise in the multi entity flow: #29575 Just something to clearly communicate and be aware of rather than a blocker :)

[annezazu]

This also previously came up in the second call for testing:

I can understand why there is a 2-step process here, but every time I clicked “Update Design” it intuitively felt like I shouldn’t have to then click a “Save” button as well.

[jasmussen]

As parity with the ability to disable the same panel in the post editor, and on by default, sure! I wonder if we should rephrase the option ever so slightly to make it more clear that you can push global changes with a single click? A stab at new help-text:

Review edits and changes before making them all public

☝️ could be more elegant. Any thoughts?

[annezazu]

I really like that phrasing!

[carolinan]

This is a duplicate of #32386
and it is becoming an unwelcome distraction the more I work with the site editor.
But since this issue has some more details, I will close 32386.

[annezazu]

Apologies for missing that original issue! I very much did try to search but managed to miss it 🤦🏼 Thanks for connecting the dots.

[annezazu]

Feedback came up related to this during the FSE Outreach Program's Build a Block Theme exploration:

When saving I get the “Are you ready to save?” screen to check which entities should be saved, even if only one entity (“Global Styles”) needs to be saved. But I guess that makes sense, since accidently publishing styles which are not perfect yet, is bad 😅

Worth considering as we think about the double confirmation.

[gschaub]

All - I'm commenting from a different perspective from what I suspect this group posesses - that of a developer from outside of the project that needs to leverage the frameworks that this group created and supports. Also note that while related, my challenge is in the post editor, not FSE. Although I haven't had to dive through the internals of FSE, I assume the editor and core-data are common to both.

I created the issue above (#68771) and my challenge is that the double confirmation (and the ability to uncheck one or more entities to be saved) has the ability to compromise data integrity. I am developing a block that persists most of its data in custom database tables. The best way to support this was to leverage the entity framework for the save/post/delete, etc. controls within the editor.

Consequently, I need a way to avoid the double confirmation at design time. From a design perspective, you wouldn't have a double confirmation to save a paragraph block. My block should work the same way from a front end user perspective. Here is my request that I believe will support the needed flexibility to address my concerns and the other concerns raised on this issue:

• Extend core-data entity definitions to include a property for something like "explicitlyConfirmOnSave" with a boolean
• Update the editor package to respect that boolean upon save
• Create documentation for usage guidlines for setting the property
• Update entities.js in a way that is consistent with the guidelines

Finally, I am going to pass on some practical realities associated with the state of documentation throughout Gutenberg. This is my first experience developing within the block editor construct. While there are unquestionably rough edges, I strongly agree that this is the approach that will keep Wordpress relevant well into the future. Unfortunately, I quickly exhaused the use of the existing documentation and found the only way to learn to develop for the project was to pursue a tedious and exhausting effort in tracing the logic back through the various packages. I frankly don't know if I'd have done this if I fully appreciated the rabbit hole into which I was jumping (and also being a very subborn SOB). Please, please, please make it easier for outside developers to create sophisticated tools that will enrich the community through thorough documentation.