U4-1808 - RTE: Image changes to another image when saving

Created by Ralph van Vugt 28 Feb 2013, 15:54:59 Updated by wtct 10 May 2016, 13:49:22

Is duplicated by: U4-1985

When inserting an image in the richtext editor from the media section, the image changes to another image (mostly the first in a media folder) when publishing the page. The website shows the right image, but when republishing the page, the wrong image is shown.

I've recorded it, because it is a little difficult to explain: http://www.screenr.com/zML7

1 Attachments

Download rte_image_fix.patch


Faihou Ze 06 Mar 2013, 03:24:32

I got the same problem even I changed the sort order of the media folder. It always displays the first image that I uploaded.

Ralph van Vugt 06 Mar 2013, 07:19:50

Thanks. I didn't check that.

Faihou Ze 10 Mar 2013, 14:20:26

Maybe I know what's going on there. If you upload images using the bulk upload control, then add these images in a RTE, you would find the issus.

Asbjørn Riis-Knudsen 11 Mar 2013, 18:02:24

Seeing this on an upgrade to 6.0.2 as well. Pretty critical issue in my opinion.

Asbjørn Riis-Knudsen 11 Mar 2013, 19:05:11

From some debugging, this seems to be due to the fact that uploading now uses the MediaSubfolderCounter class to determine the media folder name, whereas the RTE still expects that to be the id of the relevant row in the cmsPropertyData table. Thus, the RTE loads the image by getting the numbered folder from the image path, getting the relevant property via that Id and then loads an image via the version id. This will obviously not work when the folder name has no relation to the data in the database...

Asbjørn Riis-Knudsen 11 Mar 2013, 19:53:16

I have worked around this by eliminating the DB lookup when saving in the RTE (in the TinyMCEWebControl class). This seems like a bit of a hack - but why does that DB lookup exist in the first place? With the new folder structure, there seems to be no way of making this work, as you don't have access to the Media ID from the RTE in the current implementation. That really ought to be changed.

Morten Christensen 13 Mar 2013, 06:57:07

Asbjørn, what you write makes sense and ensures that this should be an easy fix. The media uploads used to have their path set based on the Id of the property that the media was saved in (usually, the name of the property is "umbracoFile"). But as of v6 no id exists prior to actually saving the document/media item, which caused problems for creating a path (theres a bunch of older issues related to this), so we had to find another way to create a path for uploaded media - enter the MediaSubfolderCounter. The db lookup that you found in the RTE should no longer be necessary, so I think you are on to the right thing. Will have a look.

Asbjørn Riis-Knudsen 13 Mar 2013, 10:56:27

I can make a pull request with my workaround, if you are interested.

Morten Christensen 13 Mar 2013, 11:34:02

If you can post a patch with your changes here on this issue that would be great!

Asbjørn Riis-Knudsen 13 Mar 2013, 12:05:12

Here you go. I haven't tried this before, so please pardon any newbie mistakes.

Morten Christensen 13 Mar 2013, 21:58:24

This issue has been fixed for 6.0.3 and I have pushed a nightly build, which you can download here: http://nightly.umbraco.org/umbraco%206.0.3/UmbracoCms.6.0.3-build.9.zip

If you are running 6.0.2 it should be sufficient to copy over the assemblies from the zip above.

Btw. Asbjørn your patch was perfectly fine ;) Thanks for providing the fix for this!

wtct 10 May 2016, 13:49:22

Oh my God...

MediaSubfolderCounter class looks like something strange for me. Now it is impossible to find directory for files of property like umbracoFile.

This functionality is used very often at our websites. It is like tautology for us and it is very helpful to know where files are stored. Umbraco was always storing files in directory associated with property Id.

There is another problem: http://issues.umbraco.org/issue/U4-2412

Now I have to implement some event which will move files to correct directory after media save.

Priority: Critical

Type: Bug

State: Fixed

Assignee: Morten Christensen

Difficulty: Normal

Category: Editor

Backwards Compatible: True

Fix Submitted: Patch

Affected versions: 6.0.0, 6.0.1, 6.0.2

Due in version: 6.0.3


Story Points: