You must resolve the single block element as its original type. List rendering will look up the content type to fetch the correct template, etc., while the standalone implementation won't.
e.g.
var element = _contentLoader.Get<MyBlock>(myBlockDataContentLink);
I do have to add that this is a pretty strange approach to block rendering and modelling your content. Also, I cannot tell whether Razor Pages is able to render blocks this way.
I have a field:
[AllowedTypes(typeof(My1BlockType), typeof(My2BlockType), typeof(My3BlockType))]
public virtual ContentArea MyBlocks{ get; set; }
I can load it as IContent and get correct value.
If i have to use "Get<SpecificType>" then Allowed types attribute doesn't have much point as i cannot generically render it anyway.
I treat it as a bug explicitly because if i render it as IContent it will fail, but if i render it as List<IContent> it will work correctly.
Since you have a content area that's the one you should render, not the block
@Html.PropertyFor(x => x.MyBlocks)
It's not a bug.
While I agree you often will want to use content areas, I've also had view models for a single content property.
I think this may be the same issue I've run into during our CMS 12 upgrade.
There is no default display template for IContent or IContentData, but there is one for ContentData.
Try adding [UIHint("ContentData")] to your view model properties.
Here's my thread when I was encountering an issue:
https://world.optimizely.com/forum/developer-forum/cms-12/thread-container/2022/7/displayfor-on-icontentdata/
you cannot render IContent but you can render List<Icontent> and it is not a bug, it's a feature. Todd Howards would be proud.
Why i'm doing it like that:
<div class="hero">propertyFor(myFirstItem)</div>
PropertyFor(otherItems)
Hi
I'm having issues rendering blocks that are not casted directly to block type when they are single elements, but it works when they are list: