Bug: Page.Level not correctly hydrated

[iJungleboy]

Background

We're working on creating a really advanced theme as a template for well designed solutions.

As such we need the ability to create various kinds of navigation, typically based on configuration, so that a designer doesn't have to always code every detail how it works.

The goal is to have something similar as DDRMenu in DNN.

One of the needs of these menus is to be able to specify things such as

• give me all the items below the current page
• give me all the items below level 2 which contain the current page (eg for side-menus which appear after hitting a top level menu)
• and much more BTW

Problem

We ran into the problem that the Page.Level is always 0. After some research into the code it appears that the Page.Level is only ever set once in Oqtane, but normally not set. The only case where we could find it being written to is

1. private static List<Page> GetPagesHierarchy(List<Page> pages) in PageService
2. which is called by public async Task<List<Page>> GetPagesAsync(int siteId) in the same PageService
3. which is exclusively only used in the RecycleBin

So PageState.Pages always report an incorrect Level of zero. It appears this is always derived from

• Site.Pages
• which seems to be hydrated in the SiteController.cs
• which itself doesn't seem to set the Level at all - and it's not stored in the DB

Likely Fix

The level should always be calculated up front, probably in the SiteController. That would also make any calculations in the PageService obsolete.

[sbwalker]

The Level and HasChildren properties on the Page entity are not stored in the database - they are run-time properties. They are populated when the GetPagesAsync() method is called by the client (this method calls a private GetPagesHierarchy() method which recursively sets Level and HasChildren). GetPagesAsync() is called by the SiteRouter which loads the PageState.Pages collection into memory so that it is available in every UI component. So your theme should reference PageState.Pages and the Level and HasChildren properties will always be populated. These are run-time properties by design as the pages collection can vary based the permissions of the currently logged in user.

[iJungleboy]

I'm actually using PageState.Pages and the Level is not hydrated. It's always zero, I verified this.

From my understanding of the code, it's populated from the Site.Pages which is not populated by GetPagesAsync.

PageState.Pages has this code:

        public List<Page> Pages
        {
            get { return Site.Pages.Where(item => !item.IsDeleted).ToList(); }
        }

and the PageState.Site is set in the SiteRouter.razor. There it's loaded from line 164:

site = await SiteService.GetSiteAsync(SiteState.Alias.SiteId);

[sbwalker]

I believe this may have been caused by the performance refactoring for the next release. I will have to take a closer look.

[sbwalker]

I confirmed this was caused by the performance refactoring for the next release. #2385 resolves the issue - it also offloads the recursive hierarchy ordering logic from the client to the server so that it can benefit from the higher CPU and caching

[iJungleboy]

Awesome, the solution looks great, just what's needed. thx!