[talhamalik4025]

Fixes #110

ContentBlocksValueEditor.FromEditor passed each nested property's incoming editor value as currentValue. File-based editors (Image Cropper, File Upload) use currentValue to find the existing file, so clearing an image in a block left the file on disk and stored the text "null", after which Actions → Publish… failed with a 500.

This matches the stored blocks by id and their values by alias, as Umbraco's own block editors do (BlockValuePropertyValueEditorBase.MapBlockItemDataFromEditor), and passes the stored value.

Tested on Umbraco 17.7.1 with this branch built from source, on a page with one block keeping its image and one clearing it:

	Before	After
Clear file(s), Save and publish	stores "null"; file stays on disk	stores null; file deleted
Actions → Publish…	500	200

The other block's image, its file and its text values are unchanged. A later save with no edits still stores "null" through Umbraco's own cropper code (umbraco/Umbraco-CMS#24335), which this PR doesn't touch.

Not included: Umbraco also deletes the files of blocks that are removed entirely. Happy to add that here or in a follow-up.

[PerplexDaniel]

It's hard for me to oversee the consequences of this where you change from prop.Value to currentPropValue. Will this not introduce regressions with other property editors that do not need this fix to begin with? I don't know the answer here either but I am a bit hesitant to update this very import method without knowing the possible effects of this change.

[talhamalik4025]

Thanks for looking at it, fair question. I went through every value editor in Umbraco 17.7.1 that overrides FromEditor. The links below are pinned to the release-17.7.1 commit.

Before this change, nested editors never saw the stored value. propData is built from prop.Value, and the same prop.Value is passed as currentValue (ContentBlocksValueEditor.cs#L123-L128), so currentValue was always the incoming value.

Everywhere else in Umbraco, currentValue is the stored value:

• For a document property, ContentEditingServiceBase passes content.GetValue(...) (ContentEditingServiceBase.cs#L767-L768).
• For Block List, Block Grid and RTE blocks, MapBlockItemDataFromEditor matches the stored blocks by key and their values by alias, and passes the stored value (BlockValuePropertyValueEditorBase.cs#L192-L245). This PR matches the same way.

Most editors never read it. 13 of the 21 core overrides don't reference currentValue at all (list below). Date Time, Date Time (new), Media Picker and Multi URL Picker only pass it on to base.FromEditor; their base is DataValueEditor, whose FromEditor ignores it (DataValueEditor.cs#L164-L175).

The editors that do read it expect the stored value:

• Image Cropper reads the stored file path from it to replace or delete the file (ImageCropperPropertyValueEditor.cs#L131-L152).
• File Upload does the same (FileUploadPropertyValueEditor.cs#L129-L140), and returns it unchanged when a temporary file is missing (#L145-L151); with the old code that fallback returned the incoming value instead.
• Block List and Block Grid (BlockEditorPropertyValueEditor.cs#L107-L118) and Rich Text (RichTextPropertyEditor.cs#L390-L421) use it to map their nested blocks, so file editors nested inside those now get the stored value too.

A new block, or a property the stored block doesn't have, gets null, as a new document does.

So the change only affects editors that read currentValue, and gives them what Umbraco passes them everywhere else. An editor that depended on getting the incoming value would already misbehave as a document property or inside a Block List. In the test in the description, the other block's image, its file and its text values were unchanged.

The 13 core overrides that never read currentValue

• Content Picker
• Decimal
• Integer
• Markdown
• Member Group Picker
• Member Picker
• User Picker
• Multinode Treepicker
• Repeatable Textstrings
• Multiple values (dropdown, checkbox list)
• Slider
• Tags
• Toggle