I am trying to figure out the correct way to accomplish this, I would like to add some settings to a block list item that is already in use, when i add the block list like
var settings = Model.Settings as RichTextBlockSettings;
it works great for new blocks, but previously created content crashes with a null reference exception - I assume the setting node the content is saved with doesn't exists, since it wasn't present when the content was saved.
Going though and re-saving each content item would fix this, but is sometimes not feasible.
I have tried a few different ways, including casting and Umbraco 9's .SafeCast<Type>() extension method, neither of these work.
The only way I could get to reliably work is this:
var longForm = false;
if(Model.Settings is RichTextBlockSettings settings){
longForm = settings.Longform;
}
I don't really like this pattern as it means I need to null check every use of setting in my view.
Am I missing something here, or is this just something that doesn't work well. I am thinking for large sites a simple work around would be to always add a setting element to the block when it is created, and then use compositions to attach any further settings as and when required.
Did you find any solution for this? I am having the same issue. The previously generated settings always return null whereas the new ones created work perfectly.
I didn't find a way, but was tinkering around and on the latest umbraco 9 patch it seems to work slightly better (or maybe I didn't test this before?)
It still requires me to null check every instance of a setting node (which is disappointing) but seems to work reliably enough. It lets you use the settings if they are set, or a custom fallback if the block list item was saved before settings were added.
var settings = Model.Settings as RichTextBlockSettings;
<p>@(settings?.ContentType.Alias.ToString() ?? "settings was null")</p>
<p>@(settings?.Longform ?? false)</p>
Hope this helps a little, if anyone else wants to pitch in with a better method, or how they are currently managing updating existing content by adding settings elements it would be great to learn how others are approaching this!
Adding block list settings to blocks that are already in use
I am trying to figure out the correct way to accomplish this, I would like to add some settings to a block list item that is already in use, when i add the block list like
it works great for new blocks, but previously created content crashes with a null reference exception - I assume the setting node the content is saved with doesn't exists, since it wasn't present when the content was saved.
Going though and re-saving each content item would fix this, but is sometimes not feasible.
I have tried a few different ways, including casting and Umbraco 9's .SafeCast<Type>() extension method, neither of these work.
The only way I could get to reliably work is this:
or
I don't really like this pattern as it means I need to null check every use of setting in my view.
Am I missing something here, or is this just something that doesn't work well. I am thinking for large sites a simple work around would be to always add a setting element to the block when it is created, and then use compositions to attach any further settings as and when required.
Did you find any solution for this? I am having the same issue. The previously generated settings always return null whereas the new ones created work perfectly.
I didn't find a way, but was tinkering around and on the latest umbraco 9 patch it seems to work slightly better (or maybe I didn't test this before?)
It still requires me to null check every instance of a setting node (which is disappointing) but seems to work reliably enough. It lets you use the settings if they are set, or a custom fallback if the block list item was saved before settings were added.
Hope this helps a little, if anyone else wants to pitch in with a better method, or how they are currently managing updating existing content by adding settings elements it would be great to learn how others are approaching this!
is working on a reply...