U4-386 - Image cropper - two saves needed before cropper kicks in

Created by Sebastiaan Janssen 19 Aug 2012, 14:52:28 Updated by Shannon Deminick 30 Mar 2016, 11:56:39

Is duplicated by: U4-710

Is duplicated by: U4-1283

When uploading an image you need to hit save twice before you are able to set any crops. Can this be changed so that the image is available to the cropper on the first save?

''Originally created on CodePlex by [Charnae|http://www.codeplex.com/site/users/view/Charnae]'' on 4/11/2011 7:07:53 AM [Codeplex ID: 30240 - Codeplex Votes: 12]

Imported comments

''Comment by [Myster|http://www.codeplex.com/site/users/view/Myster] on 6/8/2011 1:50:22 AM:'' I find you have to click save 3 times.

''Comment by [bluecherry|http://www.codeplex.com/site/users/view/bluecherry] on 11/13/2011 2:48:50 PM:'' I just submitted a pull request which will fix this issue.

''Comment by [shearer3000|http://www.codeplex.com/site/users/view/shearer3000] on 1/15/2012 9:26:03 PM:'' seems this is still an issue.

''Comment by [bluecherry|http://www.codeplex.com/site/users/view/bluecherry] on 1/16/2012 11:44:40 AM:'' That's because the fix wasn't included with the latest release ( As I understand, 3rd party contribution were not considered because of a lack of resources.

I had an email exchange with Niels and he assured me more resources would be commited towards maintaining the v4.x branch. This should allow them to include 3rd party contribs again.

No ETA on when the fixes will actually be included in a release, so I'll be building my own release to patch with this and some other fixes (update of TinyMCE, Safari support, Virtual Directory support in package installer, .. http://umbraco.codeplex.com/SourceControl/network/Forks/bluecherry/bluecherryContrib471TinyMCE/contribution/1639 http://umbraco.codeplex.com/SourceControl/network/Forks/bluecherry/bluecherryContrib471/contribution/1638

Let me know if you're interested, I would be happy to share the patch.

2 Attachments

Download imagecropper create crops.patch

Download RefreshOnFileUpload.cs


Jeroen Breuer 23 Aug 2012, 15:26:41

In DAMP in the [http://damp.codeplex.com/SourceControl/changeset/view/62425cfc1854#DigibizAdvanceMediaPicker%2fDAMP_Helper.cs DAMP_Helper.cs] file there is a method called CallImagecropper. If this method is fired in the Media.BeforeSave event it will make sure the crop is created and doesn't need 2 saves. Might be useful for in the core.

andrew shearer 29 Aug 2012, 07:57:57

still an issue in 4.8.1

Robert Bullock 14 Mar 2013, 21:39:50

Still an issue for me even on 4.11.1. Gonna try upgrading to 4.11.5 but I'm skeptical...

Asbjørn Riis-Knudsen 23 Mar 2013, 15:14:15

Also happens in v6. This is a major problem with the ImageCropper datatype. From a short look a the code, the problem seems to be that the images are generated in the DataEditor.Save() method - but that is only called when clicking the Save button in the editor. Not when using the API.

Asbjørn Riis-Knudsen 23 Mar 2013, 16:19:54

I have created a patch that moves the creation of images from the DataEditor.Save() method to a new event handler. This seems the simplest and most reliable way to ensure that crops are always created. This works in my testing, but I may have overlooked a better solution...

Timothy Beutels 24 Mar 2013, 10:06:28

@Asbjørn a fix is not the issue. I submitted a fix (for this and another image cropper bug) late 2011. Almost 1.5 years later it hasn't been included yet.

This seems to be the norm for contributed bugfixes, so I won't even bother anymore.

Asbjørn Riis-Knudsen 25 Mar 2013, 13:29:40

@Timothy Yeah - this issue has certainly been there for far too long. Sorry for ignoring your work - I just hoped a fresh patch might have a better chance, as yours seemed to have a few unaddressed comments.

Jeroen Breuer 25 Mar 2013, 13:43:03

As a workaround you can install DAMP 2.5 on v6. It will make sure the crop is created after media is created or saved.

Asbjørn Riis-Knudsen 26 Mar 2013, 09:31:21

Yes, I have been doing that - thanks for an excellent datatype by the way! But a fix for this really belongs in the core...

Asbjørn Riis-Knudsen 29 Mar 2013, 10:12:49

Can we please get this fixed in 6.0.4? This bug has been around ever since the ImageCropper was included in Umbraco - isn't it time, it was fixed?

Sebastiaan Janssen 29 Mar 2013, 10:32:55

We're still very open to contributions and it's a shame that we've been bad at using your hard work before. But since November I've made sure that at least new contributions got a fair evaluation and we've been accepting a LOT of contributions since then.

Unfortunately we haven't had time to properly evaluate and test the cropper contributions at the moment as there were more pressing issues to be dealt with (and as said, I did leave some questions on Timothy's pull request that didn't get answered). That said, my hands are itching to fix the cropper if I do get some time.

I'm discussing an alternate solution with Morten next week. In the mean time a workaround is to reload the page after a file has been uploaded, the attached EventHandler can be used.

Asbjørn Riis-Knudsen 29 Mar 2013, 10:46:05

Thanks! Just wanted to make sure this hadn't somehow dropped off the radar. Enjoy the Easter holidays!

Dirk 29 Mar 2013, 19:43:08

I have send a pull request for this issue: http://umbraco.codeplex.com/SourceControl/network/forks/dseefeld/imageCropperIssues2/contribution/4275 Until it is validated you may have a look at http://our.umbraco.org/projects/backoffice-extensions/imagecropper-patches Yours Dirk

Ernst Utvik 17 Apr 2013, 11:25:26

Tried Dirks patch and it doesnt seem to work when using the upload button from media folders. Umbraco 4.11.4

Dirk 17 Apr 2013, 15:08:44

Well my patch was build on release version 4.11.6! There might have been changes since version version 4.11.4. Have you checked the "Automatically generate crops" option in the cropper data type?

Ernst Utvik 17 Apr 2013, 15:43:31

Hi Dirk. Automatically generate crops was not checked, but changing it does not seem to fix it for me. Crops are generated on right click/create, but not when using the upload button. I'll try upgrading the site tonight and see if it makes a difference. Thnx for the reply.

Casey Neehouse 17 Apr 2013, 17:55:30

@Dirk, I think @Ernst is saying the crops did not create on the quick upload (drag and drop) or on the Desktop Media Uploader where the editor page is not seen, but rather the API is used. An event may be the way to correct this, in that it looks for the upload to occur (on save) and generates the crops based on that.

Dirk 17 Apr 2013, 19:02:27

@Casey, no I do not think so. Actually the auto generation is handled by an event, but this is only triggered if the correspondent checkbox is checked. If anything is properly configured, the defined crops are generated by drag and drop and by Desktop Media Uploader. @Ernst, in case you can not update to version 4.11.6 (official release), I have compiled a version for v4.11.4. At this very moment our.umbraco.com fails during upload so you may download the package here: http://www.idseefeld.de/umbraco/Image_Cropper_Patch_v4.11.4_1.0.zip Please be aware that further updates of core dlls will restore the image cropper! But this should not cause trouble, you will only lose the improved behaviour ;-)

Ernst Utvik 17 Apr 2013, 19:33:52

@Casey Yes thnx for clearifying. @Dirk Thank you for the 4.11.4 dll. After further investigation I realized the crops where actually created (kudos) but using the following Razor snippet (<img src="@mediaItem.crops.Find("@name", "article").url" />) crashes the script unless an additional manual save of the media item is performed. From the debug trace before manual save: 'umbraco.MacroEngines.DynamicXml' does not contain a definition for 'url'. Any idea?

Dirk 18 Apr 2013, 08:09:24

Ah, now I know what is missing: 1. the cropper property is not set after upload, 2. The cropper should provide a RazorExtension. I will check and see how to fix this. @Ernst: Thanks for the hint. The only solution for the moment might be injection of the crop name + _ ("_article") into @mediaItem.umbracoFile - not nice but I have no other idea.

Dirk 18 Apr 2013, 13:29:51

@Ernst: Now you will find an update version on http://our.umbraco.org//projects/backoffice-extensions/imagecropper-patches (see: archived files for version 4.11.4). Razor snippet (<img src="@mediaItem.crops.Find("@name", "article").url" />) works now immediately.

Ernst Utvik 18 Apr 2013, 13:51:33

Awesome! It works :) Thank you for fixing this so quick. Great job!

Asbjørn Riis-Knudsen 06 May 2013, 11:41:29

Still happening in 6.0.5. Will this be fixed in 6.1 at least? There are now no less than 3 fixes and Dirk's looks particularly promising...

Sebastiaan Janssen 06 May 2013, 12:42:54

@Asbjørn And there's also workarounds for it that work. :)

Sorry, we don't have the resources at the moment to look at it properly, it might be best for Dirk (and maybe some other enthusiastic people) to create a full-fledged package for this, a full cropping datatype that works and has all the nice bells and whistles Dirk added.

Jeroen Breuer 06 May 2013, 12:45:22

Or you can keep using DAMP which also fixes it ;-)

MK 11 Jul 2013, 10:49:46

@Dirk when creating media item one by one, its working perfectly.. but when uploading multiple files using Media Uploader its not working...

Tom Fulton 11 Jul 2013, 18:26:59

Just an FYI if you're using Sebastiaan's workaround - you might wish to bypass the handler if its running through the new Multiple Media Uploader thing instead of the normal Media UI. Otherwise, it screws up the DAMP events which can create the crops automatically. To do that, just add this at the top of the event:

if (HttpContext.Current.CurrentHandler.GetType() == typeof (using umbraco.presentation.umbraco.webservices.MediaUploader)) return;

Or even better, maybe it should only run on the editContent/editMedia pages, so its not triggered by other events:

if (!HttpContext.Current.CurrentHandler.GetType().ToString().Contains("umbraco_editmedia_aspx") && !HttpContext.Current.CurrentHandler.GetType().ToString().Contains("umbraco_editcontent_aspx")) return;

Shannon Deminick 30 Mar 2016, 11:56:39

Closing, no longer an issue

Priority: Normal

Type: Bug

State: Closed


Difficulty: Normal

Category: Architecture

Backwards Compatible: True

Fix Submitted: Patch

Affected versions: 6.0.0, 6.0.1, 4.11.5, 6.0.2, 4.11.6, 6.0.3, 6.0.4, 4.11.7

Due in version:


Story Points: