Drafts lacking versions

[tomkiss]

Hi there!

This is really product feedback, I hope this is the right place for it -

Today an editor had their content wiped out whilst editing their Draft.
I don't really know why. The draft was created by an initial copy/paste action of an article outline. Then, a lot of time was spent refining the article, adding content and so forth. They later hit the "preview" button, and the entire document reverted to the original copy/pasted content.

This is not the first time this sort of thing has happened, but it leaves me having to teach editors not to use the Drafts functionality at all. Which seems like a bad thing?
Due to its lack of versioning its a high-risk feature to use. IMO versioning is basically critical functionality for any document editor (I'm trying to think of a document state whereby a google doc or pages doc couldn't be undone/reverted?).

I never use drafts myself (tbh I've never been quite sure as to their purpose?) But then, I suppose I consider an unpublished entry as a draft of sorts. Although a caveat should be that despite using Craft CMS since the beginning, I find drafts and revisions functionality immensely confusing (I would add, to expand on that a tiny bit: It feels like the underlying technical aspects of these features are negatively impacting the UX). Anyway, rambling - I just wanted to share these experiences as there is has been a sizeable amount of time lost with work due to this, and it causes a lot of frustration when it happens.

[brandonkelly]

Thanks for the feedback.

It would be great to get to the bottom of why the content changes were lost—that should definitely not ever happen.

If you’re able to share your database and Composer files and point us to the entry where this occurred, we can try to look into it.

[mmikkel]

@tomkiss Was this a "real" draft, or a provisional draft (aka "unsaved changes")? If the latter, can you find any messages like "Overwriting an existing provisional draft" in your web.log file for the date in question?

Reason I ask is because we just had something very similar to what you're describing reported today, involving provisional drafts. Currently looking for a way to reproduce it.

[mmikkel]

FWIW, I'm pretty sure I figured out what's going on in our case: #18620

[tomkiss]

Hi, sorry for delay in replying.

I asked the author to write down an account of what happened, and she said:

If I'm recalling this properly:

1. created new entry
2. copy/pasted the text I'd used for other content (including emojis, which may or may not be relevant!)
3. saved as draft once
4. as I worked through the doc I was having some issues with it not wanting to isolate highlighted text to change its formatting; so, for example, every header (H3) I was trying to make kept doing it to the entire document, etc
5. hit preview before scheduling and saving it as a disabled entry, and that's when it reverted to the initial copy/paste!

I should note that step one is clicking the "New entry" button in the entries listing. Side note: would that button be somewhat more accurate if it were labelled "New draft"? Because it's not going to create a full entry (though in the past, it used to?). Though now I think of it, there are plenty of other places in the UI where it refers to an entry but means draft (save as new entry draft? duplicate entry draft?). I digress...

The reference to "formatting being applied to entire document" was the result of all the article content being pasted in with a single <p> tag with only <br/> tags breaking it up, so that explains that (it was vizy article field).

Unfortunately I don't have a database backup with the draft in question and I don't know which of the subsequent backups have any relevant data, if any.

Because of this I did some poking around to see if I could create some sort of problem in this area. And I did discover something, I think...

Saving.draft.with.validation.mp4

So, in this example, the entry type includes a required field. If it is a draft, then it can be saved because validation does not occur. However, when it is "created" as an entry, then validation will occur and the submission will fail.
Whilst editing, edits to the draft are background-saved. The problem is, that if a user clicks save before the current changes have been background-saved, then the page returns a validation error and most recent set of changes are reverted. Obviously in this example the changes are limited to a title, but they could be any field.

Locally, as in this screencap, the connection is pretty fast so its not a problem that is likely to occur. But on production servers the time it takes for a draft to save after edits can be much longer, and so its easier to see changes lost in this way.

Side note: the button in the preview says "Save", but it doesn't mean that in this context. It should imo say "Save draft", and perform that action, but what it means is "Create entry", hence the validation.

I don't know if this is related to the issue that originally occured. But the behaviour seems similar.
Could the same issue occur if one of the background-saves was interrupted by network disconnection?

It's also interesting that the original issue occurred moving between the main edit view and preview view; which afaia don't talk to each other (both make network calls to load their content).

[mmikkel]

Side note: would that button be somewhat more accurate if it were labelled "New draft"? Because it's not going to create a full entry (though in the past, it used to?). Though now I think of it, there are plenty of other places in the UI where it refers to an entry but means draft

...I don't mean to derail your issue by focusing on this detour, but I love debating stuff like this, so I can't help it:

If the "New entry" button was labelled "New draft" (and following from that, if e.g. Matrix "New" buttons also read "New draft"), a lot of authors would be super confused, because they aren't looking to create a new draft – they want to create a new entry 😊

The fact that new entries start their life as a kind of a draft (I believe "unsaved draft" is the term for them) isn't information important enough to authors, to make up for the confusion that renaming "entry" to "draft" everywhere in the UI would cause. In fact I think it's something that many authors won't even be aware of, partly because the Craft UI doesn't make it very clear.

And IMO, this is a good thing – because in keeping the concepts of "unsaved drafts" (and "unsaved changes", aka "provisional drafts") and "real" drafts (i.e. the persistent drafts that the author creates "on purpose" separate to a degree, each concept is actually made clearer.

[tomkiss]

Hah, well. I don't really disagree! Naming it "New draft" would be confusing to authors. But as an author myself, the "New entry" button used to create an entry, and then at some point it stopped doing that and instead made a draft entry. However the terminology of the button didn't change, which I'd argue was also a confusion for authors?
The UI includes the term, and it is possible to "Save draft", which implies that somewhere there is functionality to create a draft. Perhaps "New draft entry" would be better.

Semantics and naming things is hard.

I did actually have some previously quickly-thought out musings on this, following a loose desire to see a more consistent save menu (wrote it in a bit of a rush previously, so I've updated with some detail).

[brandonkelly]

would that button be somewhat more accurate if it were labelled "New draft"?

Technically you are creating a new entry, which starts off its life in an “unpublished draft” state. And that’s not exclusive to entries. New user accounts and Craft Commerce products each begin life as unpublished drafts as well. So “New draft” would be ambiguous.

Because of this I did some poking around to see if I could create some sort of problem in this area. And I did discover something, I think...

Yep, I’m able to reproduce that. I created a new issue for it (#18657). I’ll get that fixed and follow-up there.

Side note: the button in the preview says "Save", but it doesn't mean that in this context. It should imo say "Save draft", and perform that action, but what it means is "Create entry", hence the validation.

Thanks for pointing that out. It should be “Create entry” to match the full-page edit form and slideouts. Fixed that for the next release (9729108).