Unable to InvokeComponent for Blocktype in conversion project (--

Unable to InvokeComponent for Blocktype in conversion project (--> CMS 12)

Svante Börjesson

Vote:

Hi!

I am converting an asp.net old project to .net core / CMS12 and have now run into an issue that I can't work out.

Now, in the old solution we have made block controllers like so:

    public class ContentAreaBlockController : BlockController<ContentAreaBlock>
    {
        // GET: ContentAreaBlock
        public override ActionResult Index(ContentAreaBlock currentBlock)
        {
            var model = new ContentAreaBlockModel
            {
                CurrentBlock = currentBlock,
                Title = currentBlock.Title,
                TitleHeaderSize = currentBlock.TitleHeaderSize,
            };

            return PartialView(model);
        }
    }

After the conversion I have had the impression we should now be using a BlockComponent/InvokeComponent like so:

    public class ContentAreaBlockComponent : BlockComponent<ContentAreaBlock>
    {
        protected override IViewComponentResult InvokeComponent(ContentAreaBlock currentBlock)
        {
            var model = new ContentAreaBlockModel
            {
                CurrentBlock = currentBlock,
                Title = currentBlock.Title,
                TitleHeaderSize = currentBlock.TitleHeaderSize,
            };

            return View(model);
        }
    }

There will probably be more adjustments to make this work in practice, but my main obstacle now is that the InvokeComponent is never fired. It's like this BlockComponent or its block or view is not wired up properly.

I have pretty much followed the guide here https://learn.microsoft.com/en-us/aspnet/core/mvc/views/view-components?view=aspnetcore-6.0 and elsewhere to confirm the various code files are put in the correct folder structure and so on.

What's more is that I have downloaded the Alloy .net core project to my local added the ContentAreaBlock the same way and added this to a CMS page. Debugging this, the BlockComponent fires and renders as expected.

So what could be missing?

#301928

May 16, 2023 15:41

Scott Reed

Vote:

This looks correct to me, as you said the code is the same as Alloy.

What is rendered for that block? Are you sure that content model is the correct one firing (do your guids match).
Are you sure debugging is working correctly?

#301967

May 17, 2023 12:43

Svante Börjesson

Vote:

Thanks for the answer.

Basically, what should be rendered is the minimal:

@model x.Features.ContentBlocks.Models.ContentAreaBlockModel
<div class="contentAreaBlock @Model.StyleName">
    @if (!string.IsNullOrEmpty(Model.Title))
    {
        @Html.Raw(string.Format(@"<{0} class='contentAreaTitle'><span {1}>{2}</span></{0}>", 
                !string.IsNullOrEmpty(Model.TitleHeaderSize) ? Model.TitleHeaderSize : "h2", 
                Html.EditAttributes(x => x.Title),
                Html.PropertyFor(x => x.Title)
                ))
    }
    <div class="contentArea @Html.Raw(string.Format(!string.IsNullOrEmpty(Model.StyleName) ? "container" : ""))">
        @Html.PropertyFor(x => x.CurrentBlock.MainArea, new
        {
            removeChildContainer = true,
        })
    </div>
</div>

And this is also what comes out in the Alloy site.

I can debug any other section of my site. I can put a breakpoint in the start page controller for instance.

What do you mean by "matching GUIDs"? I suspect that there is something in the conversion of the CMS database that has altered the block objects or cause the "enumerator" to miss these custom blocks.

The page containing these blocks renders the containing property as

 @Html.PropertyFor(x => x.MainArea)

where MainArea is a ContentArea. And here, in my case, all sub blocks are rendered as primitive <DIVs> as opposed to using the block cshtml views.

#301968

Edited, May 17, 2023 13:08

Scott Reed

Vote:

This all looks correct. By matching GUID I just meant going to your model on the content definition you should have specified a GUID, this keep the model model synced with changes. It's worth checking in the admin content types area and checking there's only one block type and the guids match just to be sure nothing in the upgrade process has caused any sort of model type duplication.

#302006

May 18, 2023 7:35

Svante Börjesson

Vote:

I believe the main reason for my problem was that the application output type was wrong. Setting this to "console application" makes the block components load as expected.

#302171

May 22, 2023 12:11