RFC 104: Validation on publish

[gasman]

Rendered

A frequently-requested feature (see Wagtail issue #12505) is the ability to save draft versions of pages in an incomplete state that would not pass validation, but still enforce validation at the point that the page is published or submitted for approval. This is also a prerequisite for an effective auto-save implementation, as noted in RFC 99. This RFC sets out the requirements for such a feature, and an approach to implementing it.

[lb-]

Hey @gasman

I just wanted to bring over the idea/question from the RFC 99 #99 (comment)

Is it worth us considering a different approach, where these autosaves sit as revisions that are not applied to the model somehow, allowing us to skip validation for these only.

Autosave would create a 'unstable'/'dirty' revision, these would be attached to the user and of course the Page/Snippet instance.

When loading a page that has a dirty revision, it's used to populate the fields and it also notifies the user that we have loaded a previous 'unsaved change', the user can opt to go to the last saved state if they want (if it's available).

These unstable revisions would possibly not show up in revision reports by default.

When the user opts to actually save or publish, the current state approach would not change. It validates and creates a formal/stable revision. Because of the way revisions are saved (JSON), we can eventually opt in to some smarter live editing/revisions down the road with something like https://github.com/automerge/automerge

In addition, because we serialise things to JSON for revisions, we may find ourselves not having to solve a bunch of other edge cases such as nuanced validation scenarios.

The unstable revisions would only ever be used to show a new 'edit' view when the user refeshes / loads a previously un-saved model and would be given the opportunity to revert this.

Even for initial model creation, before saving anything, we could consider an unattached revision. This would still not validate fully until saved and could appear in the dashboard and page listings separate from actual saved items. We would have to consider a placeholder id or something that allows guests to get back to this, maybe it appears when they go to create a new page at the same point in the tree later, giving them an option to create a new one or continue where they left off.

This also gives a mechanism for users to just 'ignore' things they have started and do not want to accidentally save. It also avoids having to have rules for some fields such as title, we can just call it 'unsaved page' or 'unsaved snippet' if there's no title at the specific revision.

This approach is kind of borrowed from how Confluence works, there's a clear difference between an unsaved and saved page, even when editing one. I can close the tab for any unsaved work (within reason) and be confident I can get back to it later without issue.

It also means that developers can be confident that anything in the database will be consistently validated, including anything that may be published (from a full save) later in the future.