Please add Preview option back in by default when editing an Entry!!!

[rogerdawkins]

Description

I've just updated to 3.2.3 and would like to request that Preview is added back in as default when you first open an Entry to Edit it. The workflow when I'm editing and as far as I know all of my clients is to Edit an Entry and then the first thing they do is click Preview and then start editing. It is totally unintuitive to have to save a draft before you can do a Preview. Please change this beahaviour!!!!

Steps to reproduce

1. Edit an Entry
2. Preview is missing

Additional info

• Craft version: 3.2.3
• PHP version: 7.2.20
• Database driver & version: MySQL 5.7.26

[narration-sd]

@rogerdawkins , I had some thinking on this when first announced, which might possibly be helpful, along with @brandonkelly 's explanation above it..

You can find the note here: #4535 (comment) .

The gist is that making a draft be a Draft, as this update does, is actually safer, and closer to normal editorial practice, at least I feel. If you find agreement, this might help sell the idea in with your clients...

[rogerdawkins]

@narration-sd Thanks for your input. I can understand what you are saying that in a full Editorial process there may be merits in creating a Draft first. But typically, IMHO, Craft CMS is used by companies wanting to simply edit content on their web pages. If you read any review of Craft CMS the one thing that every review will eulogise on is how wonderful Live Preview is (and how easy it is to use) and that content editors love it. This change has moved what is one of the 'Jewels in the Crown' of Craft CMS and hidden it behind an unintuitive UX.

I appreciate it has all come about as part of changes to support a Headless Preview but I would prefer a system setting somewhere that allows Headless Preview and this new system is used for websites that require it and the old pre-3.2 system that uses Draft versions purely for Content Editor versions and Live Preview to always be available.

[brandonkelly]

I wasn’t excited about dropping it either. I’m thinking we might bring it back, and just have Craft create a draft over Ajax like we did in 3.2.0 - 3.2.2, but just not until the user actually clicks either “Preview” or “Save as a draft”.

[rogerdawkins]

@brandonkelly I was thinking about it after adding this comment earlier and I came up with the same idea. Add the Preview button and then when it is clicked you can create a draft behind the scenes. I think that would be a great solution.

[sebastian-lenz]

If the preview is tied to the draft system, does this mean that auto-saving must be turned on to use it? That would be quite problematic as someone might play around in the editor on a draft unknowingly changing it. As we don't have auto-saving in the regular element editor this behavior would be difficult to grasp.

Also, why is the live preview now so tightly bound to the draft system? We had a perfectly working preview in Craft 3.1 and the code for it (LivePreviewController) actually still is in the code base. Cann't we just reconnect the old preview controller?

[brandonkelly]

@sebastian-lenz Yes, drafts still get auto-saved, and there’s no way to turn that off. Craft makes it clear that changes are getting saved via the autosave indicator though, so I don’t expect anyone will be surprised by it.

There were a number of issues with the old Live Preview functionality. It was slower, required template hacks if you needed to set parameters on Matrix / relational field queries, and was generally pretty buggy. The new implementation solves all of that, in addition to making it possible to preview your entries in other contexts with Preview Targets, plus the new headless/decoupled preview capability.

[brandonkelly]

Just released Craft 3.2.4 which brings back the Preview button for Current entry revisions, which acts as a shortcut for clicking “Save as a Draft” + “Preview” 🎉

[narration-sd]

That was quick 😄 ... in and out, or out and in, I guess.

@brandonkelly , I've given this a little time before responding, and maybe have a good combo plan.

• if you're going to bring back the Preview button on fresh New entries on this architecture, it needs also to automatically save as Draft. Otherwise, anyone using CraftQL will not at this stage be able to find/access the entry; know you'll appreciate the cause. This was in backchannel correspondence for good reason, and I see the need for others, watching here.
• Doing the autosave will also correct some issues I note at the moment. If you make a New entry, then Save it (labelling of button is questionable, but half-fit with what happens), the dropdown announces you have a draft, called Draft 1. Then go out to Entries listing, and note you actually have an active Entry listed by its title, which is now published in its likely unfinished form on the website! Going back into edit, indeed it's now called Current.
• thus, an autosave to Draft will solve both problems -- please! Again, as per backchannel, but also for now-evident others.

Here's the extra benefit part.

• If you make this show/don't show auto-drafting Preview button controllable by a general.php Settings option, you can announce it as
  a) supporting a Workflow, for those that see the benefit, since we turned that up in conversation
  b) allowing conservation of Drafts, for those who like to be able to back out of starting an entry without adding something to the database unduly.
• Last part's mainly aesthetic, yes, but you can see from correspondence it can cause concern...

Thanks, and the evident-others parts has me thinking amusing thoughts about positioning -- it will work 😊

[brandonkelly]

if you're going to bring back the Preview button on fresh New entries on this architecture, it needs also to automatically save as Draft.

Nothing has changed about new entries in either 3.2.3 or 3.2.4. They continue to be created as ephemeral “unsaved drafts”, and have autosave up until the “Save Entry” button is clicked.

If you make a New entry, then Save it (labelling of button is questionable, but half-fit with what happens), the dropdown announces you have a draft, called Draft 1. Then go out to Entries listing, and note you actually have an active Entry listed by its title, which is now published in its likely unfinished form on the website! Going back into edit, indeed it's now called Current.

Are you telling me that when you save an entry, the entry gets saved?

[narration-sd]

Nothing has changed about new entries in either 3.2.3 or 3.2.4. They continue to be created as ephemeral “unsaved drafts”, and have autosave up until the “Save Entry” button is clicked.

Yeah, that's the problem. There's no Entry element which has the Draft. Thus: a) CraftQL can't see it, because it schemas drafts only as a property of entries. If it even did, then it would take an entirely different GraphQL query to find it -- thus not transparent for drafts as you know is such a nice feature allowing CraftQL to work transparently for previews.

Thus this auto-save-on-preview does need to make an Entry. How that entry should be treated gets to the next point, yes...

Are you telling me that when you save an entry, the entry gets saved?

Well, yes.
a) That's the problem with the button label to begin with
b) or, it's a problem with what way it's being saved: as a Draft or as Current. That's what I'm saying about the dropdown indicator which names differently while you're still editing, and after you've left and come back.
c) the issue I think needs particular focus is what this New entry becomes. If it's never Previewed, it's never real as far as listed and published Entries. If it's previewed as you have things now, it can't be seen for preview by any CraftQL-using arrangement. And yes, if you auto-save it as an Entry, it will become a real listed and pubished Entry.

I'm thinking this way to solve, maybe.

1. Every New Entry auto-saves as a proper Draft, visible to CraftQL.
2. 'proper' means based as normal to an Entry
3. Entries with only Drafts are not published.
4. To publish, you get a button on that draft which says Publish or Publish Draft, not Save. Cmd/Ctrl-S gets the same Publish behavior.

How do you like those apples, with your better insight?

[narration-sd]

slight clarity update on solution

[narration-sd]

a little more clarification as I go out the door for a time...

[narration-sd]

@brandonkelly This morning's insight is that I believe to have a way to solve this. The kind you get from looking away.

It comes out of that kit of object parts that built up in assembling the final Live Vue architecture which enables Gatsby and Gridsome in a way that ordinary folks can handle it, which you know has been operating 'a while', tracking Craft's moves.

Thinking it out a present, and I'll put a note on Craft's support line.
Clive