[3.2] FR: Don't disable the Update Entry button

[mmikkel]

Description

As part of Craft 3.2's auto-draft functionality, the "Save Entry" button has been replaced by an "Update Entry" button, which is disabled when the user is viewing the current Entry version.

In my opinion, disabling this button is a bad idea for a few different reasons:

1. There are several valid reasons why a user may want to (re)save an Entry without editing its content – e.g. clearing out any caches related to that Entry, triggering save events to have a third party plugin do its thing, etc.

2. I assume that (at least part of) the reason for the current behaviour is to indicate to the user if they're editing an unpublished draft or not (i.e. there are unpublished content changes). Which is nice; previous Craft versions offered no such indication. But... why disable the button? Wouldn't it be just as clear (and less confusing) if the button was always enabled, and simply read "Save Entry" (or even "Resave Entry") for the current version, and "Update Entry" when editing unpublished drafts? I'm all for more context-aware UI, but not being able to re-save the Entry as-is seems unnecessarily restrictive.

3. As a more general thing – there are very decent arguments to be made that disabled buttons suck :)

Steps to reproduce

Additional info

• Craft version: 3.2.0
• PHP version:
• Database driver & version:
• Plugins & versions:

[timkelty]

In the week or so we've had a client in a 3.2 CP, we've already heard a lot of frustration about "waiting for the save button".

[mmikkel]

@timkelty Yeah... the fact that the auto-save UI is not optimistic and depends on AJAX requests to update state, definitely compounds the issue. But even if the state update was immediate, disabling the button would still be a very bad idea IMO.

[ryanmasuga]

One of our devs just "updated" an entry on our site (Asset field) and he can't re-save the entry because the button is grayed out. He then tried changing a field he didn't need to change just to trick Craft into re-enabling that button (which didn't work).

[ryanmasuga]

I was able to recreate that issue - we have certain blog posts that have JS errors in console that are preventing them from being saved. Other blog posts are fine. We're trying to find the rhyme or reason. We're using a pretty standard "content blocks" matrix setup.

Anyway, when the button does re-enable itself, there is enough lag (2-4 seconds) that things "feel" slow.

[mmikkel]

@ryanmasuga More than the bugs (which will surely be ironed out), I'm worried about the basic design of auto-saves (auto-drafts?) – both conceptually (see #4549) and in terms of AX. Specifically, I think having the "Update Entry" (aka "Save Entry") button being disabled for the current version is a pretty major usability issue, but certainly the general slowness of the AJAX dependant UI state is also a problem.

[brandonkelly]

After some thought, I’ve decided to disable draft auto-creation when editing entries, for a couple reasons:

• The concept appears to be a little unintuitive. (3.2 autosaves pollute the concept of drafts #4549)
• It could lead to drafts getting created even if nothing was actually changed (from the user’s perspective). ([3.2] Endless loop of drafts when trying to view or delete a draft #4545)
• It got in the way of quick edits. ([3.2] FR: Don't disable the Update Entry button #4535 (comment))
• It was a bit hacky behind the scenes in ways I don’t need to get into, but could have led to other bugs eventually.

So as of 3.2.3, if you are editing the Current revision of an entry, you will get the old “Save Entry” button, plus a new “Save as a Draft” button:

If you click “Save as a draft”, a draft will be created based on the current form contents, and you will be redirected to it. From there the page will behave identically to 3.2.0 - 3.2.2 – changes will be auto-saved, etc..

One caveat of this change is that it will no longer be possible to preview the Current revision of entries, even after you start making changes. (See how there’s only a “Share” button, but no “Preview” button, in the above screenshot.) That’s because the content previewing system in Craft 3.2 is based on what’s stored in the database, rather than sucked out of form post data like previous versions. If the changes aren’t getting auto-saved to a draft, then they won’t show up in the preview iframe either.

It will be a slight adjustment but I expect authors will get used to it. It’s only one additional click (“Save as a Draft”) to start previewing your changes.

[narration-sd]

Interesting one. It might save the most pressing of the needs I've been hitting you up about. And I will try it(!)

For an editor, this move struck me at first as a step backwards. It's not only losing the automatic feel of previewing, it's also requiring a second step that you didn't mention, to push a now-required Draft back into Current.

But, then with a little thought, the view starts really changing. It's actually probably a much more sensibly safe way to do content updates -- not putting them in likelihood of immediate publishing.

Higher level editors may well appreciate this especially. The presented site moves when it's judged and approved to move. Permissions might be a possible help in this also. Indeed, it makes a workflow.

I also like that it kind of cuts down on the proliferation of garbage-collectable, sometimes I think invisible entries in the database. So, a smoothing move also...

Clive

[narration-sd]

p.s. of course the 'saving my issue' part is about this new functionality being in place for fresh new entries, which presume it will be...

I just tried the currrent dev-master, but Preview is still visible there, so the code's probably not finished, understood.

Including this will make consistency for the overall change, one more point for it...

[theskyfloor]

I feel like I might be in the minority but I would at least like to suggest adding a real autosave to the roadmap. If 3.2's implementation was hack-y then by all means get rid of it but Craft still needs a real autosave with no user interaction necessary. Somehow Wordpress manages to do this without it being a drag on editing, UX, or user understanding... and my clients expect that their CMS will do it. They certainly don't understand why WP does it and Craft which I say is better doesn't and it's especially frustrating when they lose data that they might have otherwise been able to use because they forgot to do something. Just some thoughts to the counter point.

I do agree that 3.2's autosave wasn't very clear and even though I found it even more confusing I preferred it in alpha when it happened to create an entry even if the user didn't intentionally save anything.

[brandonkelly]

To be clear there’s nothing hacky about draft autosaving; just draft auto-creation from the Current entry revision. So if you’re working on a substantial edit and want it to be autosaved, you still can do that; just click “Save as a draft” at some point and autosave will start kicking in.

[brandonkelly]

But I hear you – and we will continue working to improve.

[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” 🎉