U4-5510 - Previewing a content item saves that item

Created by Stephan 18 Sep 2014, 12:24:31 Updated by Murray Roke 14 May 2017, 22:46:45

Relates to: U4-3404

Relates to: U4-5052

The "preview" button is actually "save & preview" which means that pressing "preview" will cause the content item to be saved, causing a lot of pending documents in the back-end.

(creating the issue following a discussion on Twitter so we can clarify what exactly goes wrong)

1 Attachments


Richard Soeteman 18 Sep 2014, 12:30:20

I don't think the preview should trigger a save. And if for some reason it is necessary it should only save when there is something changed. When I have a published page and I want to preview it, currently it is triggering save first which means there is a pending version in the tree. I would suggest to add a warning similar to unsaved changes when hitting the preview button. So people know they need to save stuff before previewing.

Stephan 18 Sep 2014, 12:35:31


  1. at the moment if you hit "preview" it saves a pending document -- whether you've made changes or not? Or only if you've made changes?
  2. you'd like to preview changes without these changes being saved?

Stefan Kip 18 Sep 2014, 12:35:53

I don't see any reasons for not saving before previewing...

Richard Soeteman 18 Sep 2014, 12:37:14

It's always saving so even when there are no changes made to the document. That's the real issue IMO :)

Stephan 18 Sep 2014, 12:37:32

Stefan: me neither but I understand the issue of creating pending documents just because you hit preview on a document that you haven't changed.

Stephan 18 Sep 2014, 12:38:47

@rsoeteman Good, that was the purpose of me creating the issue: identifying the real issue. Saving "nothing" ie creating a pending document though nothing has changed = issue. But I thought it was fixed. Will look into it.

Stefan Kip 18 Sep 2014, 13:28:19

@zpqrtbnk Why would anyone preview a document which doesn't have any changes?

Stephan 18 Sep 2014, 13:35:22

Stefan: just because they can. Richard?

Richard Soeteman 18 Sep 2014, 13:40:20

Why wouldn't you if you are in the backoffice preview button is easier touched than first go to a different tab and click on the url.

Stefan Kip 18 Sep 2014, 13:42:09

Then that's the problem, you just invented a work-around which works for you.

Richard Soeteman 18 Sep 2014, 13:47:14

Come on Stefan it makes no sense to have a saved version when nothing is saved, that's the issue..

Stephan 18 Sep 2014, 13:48:04

Mmm... not sure, I'm with Richard on that one. Imagine you save some change on some content that are supposed to be menu items but NOT main pages... you have to preview a main page (which has not changed) to see how it renders.

Richard Soeteman 18 Sep 2014, 13:50:44

Exactly Stephan

Stefan Kip 18 Sep 2014, 13:53:42

@rsoeteman I didn't say it's okay to always save a document, even without any changes. I'm just saying it's not really easy to open the current document in your browser, without using the preview button.

Richard Soeteman 18 Sep 2014, 14:01:21

I think we are saying the exact same thing based on your last reply :)

Douglas Robar 18 Sep 2014, 15:51:55

Just to chime in (a bit late)... I do not like preview doing a save even if there are changes for a number of reasons:

The button says 'Preview' not 'Save and Preview'. This is completely opposite the behaviour of the 'Save and Publish' button next to it.

EDIT: --If a save happens on preview, there is no alert notice of the event as there are in all other cases of a save event on content (and all other kinds of) nodes.--

If a save happens on preview there is no way to abandon one's changes short of a roll-back, something most people don't know about and by default users of type 'writer' aren't allowed to roll-back anyway. It isn't uncommon to simply click away to something else in the umbraco backoffice to quickly abandon changes. I do this in CSS, templates, and content too.

The version table grows enormously (though it wouldn't be so bad if it didn't save even if there are no changes as much of this discussion has focused on)

We all agree that no save event should happen on preview if there is no change to the underlying data. That's certainly a bug.

What I'm arguing is that, though I like the simplicity of just clicking the preview button the UX is totally broken if a save happens (even if it only happens for changed content).

If saving on preview is considered a good thing we will need to address the above issues. The name of the preview button would need to be 'Save and preview', the usual green 'Content saved: Remember to publish to make changes visible' notice should somehow be displayed, and roll-back would want to be enabled for all user types by default.

Sebastiaan Janssen 18 Sep 2014, 16:00:41

FYI, it does show that it's been saved, except most people won't see it as you're redirected to the previewed page immediately.

Douglas Robar 18 Sep 2014, 16:04:41

@sebastiaan Indeed, it does. Okay, that's that one out of the way. Though as you say, it isn't exactly obvious because of the redirect. Still, we can set that aspect of the UX concerns aside. Thanks for the clarification.

Shannon Deminick 23 Sep 2014, 02:17:28

Hi everyone.

First - the version table will not grow when you just save! We only create versions when necessary, not just by saving documents. A version is created when the publish status has changed, it has been like this for a very very long time. The code that does this check is here:


That seems like a primary concern here which isn't actually a concern.

For doug's #3 point, if someone changes some data and clicks preview without a save, then they will not see that data when they preview. The document has to be saved with changed data in order to preview it, it's impossible otherwise without some new db changes (i.e. versions that are not actually versions).This is why this change was made because of the reports in this issue: http://issues.umbraco.org/issue/U4-3404

I'm happy to make this functionality work however people want it to... first it didn't save, then people wanted it to save (U4-3404), now people don't want it to save.

Douglas Robar 23 Sep 2014, 08:03:37

Thanks, @Shandem. I'm confused by your comment that preview doesn't save but the associated issue (U4-3404) says the bahaviour is now to save changes on preview. Certainly in 7.1.6 clicking the Preview button does indeed save changes and the preview reflects these (silently saved) changes. It is clear that every 'Save' event writes a version and with 7.1.6 every preview event causes a save as well. That could lead to a lot of versions if people preview often but save/publish rarely, as I see students in the courses do all the time.

I wasn't aware of U4-3404 change, as I suspect a number of people weren't. @rsoeteman's concern that every preview causes a save, even if there are no changes to the content of the document, appears to be unfounded. @rsoeteman, can you confirm/clarify if/when a save event happens when clicking the Preview button if there's no change to the document content?

Lastly, if the 'save when clicking preview' is now intended behavior (U4-3404) then I feel strongly two things should be updated to support that situation:

The button text should become 'Save and preview' (including all lang files)

The 'Writer' user type should allow Roll back by default to enable abandoning inadvertent changes

Shannon Deminick 23 Sep 2014, 08:09:16

@Doubdrobar what i mean is that it doesn't create physical versions in the database everytime you save. Yes it saves the current version (overwrites), but it does not create a new version in the version table. Again, here's the logic that determines if a new true version is stored in the database:


The remarks state:

    /// <remarks>
    /// A new version needs to be created when:
    /// * The publish status is changed
    /// * The language is changed
    /// * The item is already published and is being published again and any property value is changed (to enable a rollback)
    /// </remarks>

This has been the behavior from around 4.10 or so IIRC

Shannon Deminick 23 Sep 2014, 08:10:27

--Just to note, you cannot rollback a saved version from another saved version... because a version is not actually created. You can rollback after a version has been created, as noted in the above, this occurs when--

  • --The publish status is changed--
  • --The language is changed--
  • --The item is already published and is being published again and any property value is changed (to enable a rollback)--

Shannon Deminick 23 Sep 2014, 08:12:12

Sorry ignore that last statement, if data is changed, then yes a version is created. But just by pressing preview, if no data is changed, no version is created.

Richard Soeteman 23 Sep 2014, 08:14:28

Hi Shannon,

It is not the version table that is growing I think, dunno but what happens in code is this (so it saves before preview)

$scope.preview = function (content) {

    if (!$scope.busy) {            
        $scope.save().then(function (data) {

            // Chromes popup blocker will kick in if a window is opened 
            // outwith the initial scoped request. This trick will fix that.
            var previewWindow = $window.open("/umbraco/views/content/umbpreview.html", "umbpreview");

            // Build the correct path so both /#/ and #/ work.
            var redirect = Umbraco.Sys.ServerVariables.umbracoSettings.umbracoPath + '/dialogs/preview.aspx?id=' + data.id;
            previewWindow.location.href = redirect;

and a green indicator for pending changes is visible in the tree. If it needs to save, fine but only when there are changes I think sites will end up with a lot of pending changes and editors don't know which ones are really changed.

Hope this helps

Shannon Deminick 23 Sep 2014, 08:18:14

I know it saves before preview... otherwise you cannot preview the changes... this is why we people asked me to fix this: U4-3404

Doug mentioned that the version table would grow enormously but that is not the case, unless data is actually changed. So if you navigate to a node and click preview, sure it will save it before previewing but no version is created because it hasn't actually changed. So all I'm saying is there is no need to worry about the version table growing.

Shannon Deminick 23 Sep 2014, 08:21:11

Again, i'm happy to do whatever people think is right. There's clearly a difference between how people want this to work.

We can easily change the name of the button, but allowing a Writer to rollback is a permissions decision which is based on what the administrator of each site wishes to allow.

The reality is, if a writer, or anyone wants to preview a change, the document needs to be saved. So either the preview button saves and then launches preview, or the person has to click save and then click preview. It is the same end result.

Richard Soeteman 23 Sep 2014, 08:28:28

But why save when there is nothing to save? I noticed when I previewed a few published pages and did nothing else. The green sign in the backoffice then tells the editors the page is changed so they need to publish again to make this go away. Isn't there a way in client code that tells if property values are really changed? When not just preview when they are changed save and preview..

Douglas Robar 23 Sep 2014, 08:36:07

But a version IS saved when clicking preview. Open a content page, delete a word in the RTE for instance, and click Preview you'll see the preview with the word removed. A version is saved (you'll see it listed in the Rollback dialog, and the Audit trail dialog).

Interestingly, if I delete more words and preview again, a new version is NOT saved, but the last version is updated to contain the data with more words deleted. Which I guess is why Shannon says the version table won't grow and grow. Replacing the last saved but unpublished version with the current values is worse than a growing version table IMO. Versions are easy to remove with various tools, but lost data is gone forever if it is overwritten. The unintended consequence is that there's no way to rollback to a particular state, which isn't a good idea.

This is true of any save event it turns out, either using the Preview button or using the 'Save' button. In either case, the last version that isn't published is overwritten and prior changes lost. Suppose two content editors are working on a page. The last one to publish 'wins' but you can always rollback to the other version to recover any content. Not so if the preview or save buttons are used; those intermediate changes are lost forever.

Douglas Robar 23 Sep 2014, 08:41:16

I can reproduce the problem Richard is talking about! I couldn't before but now I can. Here's what I did:

Publish a content page

Go to another page in the content tree

Return to the previously-published page in step 1

Preview the page (do NOT alter the page in any way)

When you dismiss the preview window you'll see two things: there is a green plus sign overlay on the content page's icon indicating there's a change in the values of the page that is not visible to website visitors, and a new version (or a replaced version as discussed above) is created and visible in the Rollback and Audit trail dialogs.

Shannon Deminick 23 Sep 2014, 08:50:14

Yes... it's because of what is noted above. The item's published status is changing, thus a new version is created. If an item is published, then an item is saved, it has a new version.

This specific case may not be ideal, if something is published and then saved but nothing is changed, then really nothing should be done. It's another item to add to the logic of 'ShouldCreateNewVersion' method.

Please note, the versioning has been like this for a very long time, it was actually worse before. You can read all about it on this issue: http://issues.umbraco.org/issue/U4-2589 And there's info there on the decisions as to when a new version is created.

So moving forward, does the following solve everyone's requirements:

  • Change the button to say 'Save and publish' (even though it won't save if nothing has changed)
  • Update the logic in the ShouldCreateNewVersion to not actually create a new version if the item is published and the item is just being saved, but no data has actually been changed (i'll need to double check with @sitereactor that this won't have any adverse affects)

Richard Soeteman 23 Sep 2014, 08:57:59

Might be of topic but I think this is an UX issue instead of a code issue and you might ask the UX group (if still exists) what they think about this? The change in ShouldCreateNewVersion sounds good by the way :)

Andy Butland 27 Sep 2014, 19:40:21

Hope another commenter chipping in helps rather than hinders, but for me the current situation is a definite improvement on U4-3404 (as you couldn't preview changes at all before that was done), and the button should say "Save and preview" to be clear what's going on.

Ideally though... preview wouldn't save at all - to support the scenario of "having a look to see the effect of a change, and then changing your mind". (Print) Preview in something like MS Word wouldn't save, and that's maybe what a new user will have in mind.

So how to do that? I've previously handled this in (much) smaller systems by using the editor's session. Clicking preview serializes the content object from the current state of the form to the session, and the preview link has some querystring flag indicating that you are viewing in preview mode. The preview logic would check this, and if found look in the user's session get the content from there rather than from the database. I don't know how feasible something like this would be in Umbraco but perhaps something along those lines might work to give a true preview behaviour.

Douglas Robar 29 Sep 2014, 11:08:34

Thanks for chipping in, @abutland! This is an interesting idea and might be the breakthrough we're all searching for. I'll leave it to others to comment on implementation details but consider the following scenarios and behaviour using your "no-save-but-preview" idea. I like it very much!

SCENARIO 1: Previewing a single page In this case, the editor is playing with a page and wants to confirm all looks good before publishing. This will probably be more common when the grid/layout builder/thingie is released in 7.2 as there is likely to be more to-and-fro'ing from the content editor to the rendered page before feeling confident to hit the publish button.

'Save and Publish' (and 'Save' for that matter) will behave as they always have done.

'Preview' would trigger the proposed no-save-but-preview action suggested by Andy. No version would be saved. No version would be updated/overwritten. (Would any event fire at all?) The preview button would not need to be renamed because no save would occur. The 'Discard changes' notification will alert the user if the editor attempts to move away from the page without saving or publishing first, while still allowing content editors to abandon changes without needing to rollback or modify the default member group settings.

SCENARIO 2: Previewing a number of related pages In this situation, the content editor is making changes to a number of pages and will publish them all when all pages are ready or approved. This might be a micro-site or an update to marketing messaging or SEO text or whatever.

The behavior is identical to the first scenario but let's play it out in full anyway.

Each page is edited by the content editor. The 'Preview' (meaning, no-save-but-preview in this case) may be used as many times as needed and no version is created or overwritten merely by clicking the 'Preview' button.

When the content editor is happy with the page, s/he clicks the 'Save' button, which behaves as it always has, and moves on to the next page. This repeats until all pages have been purposefully saved.

At any time the user clicks the 'Preview' button s/he will see the current page rendered using the not-saved-but-previewed values. Also, being a 'Preview', the saved version of pages that are purposefully saved but not yet published will also be used for the preview. NOTE: Handling the preview data for saved but not yet published pages is another issue, already being discussed and worked on elsewhere. I mention it here to give context.

SCENARIO 3: previewing while two people edit pages at the same time This is the same as Scenario 2, but multiple editors are working on the various pages at the same time (not the same page at the same time).

In this situation, clicking the 'Preview' button (using the no-save-but-preview method) will behave as described in the first two scenarios.

Doesn't that mean that any unsaved edits another editor is making will not be visible during Preview until the other page(s) have the 'Save' or 'Save and Publish' buttons clicked? Correct.

Is that a problem? Nope. If anyone is concerned about this in practice, they can use the 'Save' button before clicking the Preview button to expose their current edits to other content editors.

What does everyone think? Is the workflow and UX appropriate? Is Andy's "no-save-but-preview" idea possible to implement?

Shannon Deminick 29 Sep 2014, 23:58:02

To be honest I think we need to move this discussion outside of this issue since we need an interim fix for 7.2 and don't have time for new features. I think we should fix what is there now, and discuss feature requests like this on the mail list.

We need to identify what the problem actually is 'now'. Previously people didn't like the idea that a document had to be saved in order to publish it, so we fixed that. Now people don't like the idea that a document is saved automatically when clicking preview. Some of the main concerns is that when you click preview and a version is saved, you'll get a green icon stating that something is pending, the other concern was the wording. So to solve this problem 'now' (i.e. for version 7.2) it seems that these are our options:

  • First we need to do this regardless: Update the logic in the ShouldCreateNewVersion to not actually create a new version if the item is published and the item is just being saved, but no data has actually been changed

Then, here's some options:

  • Change the button text to say 'Save and Preview'
  • Leave the button text to say 'Preview' but when the form is 'dirty' in JavaScript the label dynamically changes to 'Save and Preview'
  • Revert the change entirely so that the button only says 'Preview' and the user has to manually save changes to preview
  • ... open to other ideas that are feasible and easy in the very short term

Moving forward I think we should move this discussion but in the mean time it's worth knowing the limitations that exist.

  • With the current XML Cache structure, memory usage is a giant concern. This concern exists today already unfortunately. If two administrators preview at the same time, this means that the entire XML cache is loaded into memory for each preview along with the real front-end cache. If you have a ton of content, memory usage will be huge. To make this work better we really need to wait for the new cache implementation in v8.
  • In the case of physically not actually saving data for preview, this isn't totally possible. Think about media, you cannot upload a new image without saving so that's definitely a limitation. Apart from that, it might be possible to create a new preview context for the current admin (which creates a copy of the whole cache), then serialize the current document preview to this copied cache context which is then used to preview on the front-end.

Douglas Robar 30 Sep 2014, 07:53:20

Thanks for the input, Shannon.

I recommend that, for the interim, the logic for ShouldCreateNewVersion be updated.

I don't recommend any other changes since they all hinge on the larger questions raised in the comments.

In particular, as much as I think changing the label to 'Save and preview' is appropriate given the interim behavior it is entirely possible the long-term solution will be to do something else along the lines already discussed, or in some way not yet imagined. I would hate to introduce a label change (requiring doc changes to user guides, course workbooks, wiki, et al) just to change it back at the next version. It seems to me that too much is up in the air... unless there is consensus that a save event when clicking preview will be part of the long-term solution. If which case I prefer the idea of leaving it 'Preview' unless it is 'dirty' and using JS to dynamically change it to 'Save and preview' as needed.

Shannon Deminick 30 Sep 2014, 07:59:17

Ok will get these things done, might not be for 7.2 beta for def for final release. To be clear though... when you say "I don't recommend any other changes", do you also mean revert the changes to automatically saving before preview, or leave that as-is ?

Douglas Robar 30 Sep 2014, 08:02:42

I meant leave the functionality as it stands (continue to save on preview but only if 'dirty'). That would be the best interim solution IMO. We can discuss the larger issue(s) later.

Shannon Deminick 30 Sep 2014, 08:04:33

Ok thanks :) sounds good.

Per Raknes 01 Oct 2014, 13:43:43

Hi I use Umbraco version 7.1.4 assembly: 1.0.5261.28127.

For me the "Preview" Button behaves like «Save». (not "Save and preview")


Shannon Deminick 02 Oct 2014, 01:06:32

Per I have a feeling that is because your browser is blocking the popup for preview

Per Raknes 06 Oct 2014, 10:29:24

Shanon, yes you are right.

Shannon Deminick 21 Oct 2014, 02:16:22

I've fixed this up now so that if you are previewing and you haven't made any changes, umbraco will not persist any data which means you will not get the little green icon shown. However, if you do make a change and click preview, it will of course save data and you will get the little green icon but currently there is no way around this (as discussed above).

we can open up another ticket and/or discuss future options but for now this should alleviate some confusion... and this also means we will not be creating empty content versions for nothing which is an added bonus.

Søren Reinke 25 Jun 2015, 12:48:32

According to http://issues.umbraco.org/issue/U4-5052

The problem is still around :-(

Murray Roke 14 May 2017, 22:46:45

In 7.5.11, If I open a page, click preview without making any changes, then the green plus appears. I've created an issue to report this here: http://issues.umbraco.org/issue/U4-9912

Priority: Normal

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 7.1.6

Due in version: 7.2.0


Story Points: