Content Blocks: Handle JArray data (typically when nested)
#391
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… JArray instead of a string In some circumstances eg when a ContentmentBlocks is nested inside the Core Umbraco BlockList (yes I know) and it's moved between environments (uSync/Cloud) then the ContentBlock content although 'transferred' successfully doesn't get rendered by the ContentBlocksValueConverter because of the check to see if it is a string. When Umbraco saves ContentBlocks within the BlockList JSON, then it escapes all the things \\\\\\ and when it's ready in the ConvertSourceToIntermediate it is interpreted as a string as it's no longer valid JArray... but when it's moved by a serialisation/deserialisation tool, then actually the stored value is a valid JArray and Umbraco returns the object to ConvertSourceToIntermediate as a JArray... ... which is why this PropertyValueConverter skips displaying it ... (but it loads the content fine in the backoffice) this pragmatic suggestion sort of caters for this quite niche scenario - but also I don't think does any harm to non-niche scenarios and is the place in the whole setup with the least moving parts, but also also, spiritually I recognise this probably isn't the internationally agreed place to fix this sort of thing...
|
@marcemarc Just to note, I haven't forgotten about this. I'll try to take a look towards the end of this week, (once the Umb v14 RC is release). |
|
Thanks @leekelleher I haven't forgotten either :-P we are running a patched version of Contentment in production and it's solved the issue, it wasn't just an issue when it was embedded inside block list, but also when it was just a contentment blocks property editor.... |
leekelleher
changed the title
JArray data (typically when nested)
leekelleher
approved these changes
Apr 19, 2024
There was a problem hiding this comment.
All good, thanks @marcemarc!
I made an adjustment with the JArray deserialization, to save doing the .ToString() step.
I'll aim to get a patch release out soon.
|
@marcemarc ...and it's been released in Contentment v4.7.0! |
|
Thanking you! @leekelleher |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Handle the 'sometimes' when the stored ContentBlock data appears as a JArray instead of a string
In some circumstances
eg when a ContentmentBlocks is nested inside the Core Umbraco BlockList
(yes I know)
and it's moved between environments (uSync/Cloud) then the ContentBlock content although 'transferred' successfully doesn't get rendered by the ContentBlocksValueConverter because of the check to see if it is a string.
When Umbraco saves ContentBlocks within the BlockList JSON, then it escapes all the things \\\ and when it's ready in the ConvertSourceToIntermediate it is interpreted as a string as it's no longer valid JArray...
but when it's moved by a serialisation/deserialisation tool, then actually the stored value is a valid JArray and Umbraco returns the object to ConvertSourceToIntermediate as a JArray...
... which is why this PropertyValueConverter skips displaying it ...
(but it loads the content fine in the backoffice)
this pragmatic suggestion sort of caters for this quite niche scenario - but also I don't think does any harm to non-niche scenarios and is the place in the whole setup with the least moving parts, but also also, spiritually I recognise this probably isn't the internationally agreed place to fix this sort of thing...
Related Issues?
Here is a related conversation: Jumoo/uSync.Complete.Issues#226
Types of changes
Checklist