We experience some seriously sluggish behavior in Content Studio, and we think that it may be related to layouts with empty regions.
In the release notes we see this:
Content API no longer reads Page/Layout descriptors to determine regions for every fetched content. Regions are built from components array in content data. This changes the behaviour for regions with no component assigned. Rendering engine is now responsible for reconstructing unused regions from Page/Layout descriptors.
What does this mean, and what are we supposed to do about it? Exactly how does the behavior for empty regions change? We can of course avoid empty regions, but the editors have made some (a lot of) interesting choices here and there which means we can’t just tell them as a quick fix to switch from for example a three-col layout with an empty region to a two-col layout with no empty regions. (There’s a link to a config setting “resolveEmptyRegions” that is deprecated, and we don’t want to go that way even temporarily.)
There’s a link to a config setting “resolveEmptyRegions” that is deprecated, and we don’t want to go that way even temporarily.
“resolveEmptyRegions” config is not deprecated. It was introduced by us specifically to maintain the deprecated behaviour of resolving empty regions for those customers who have them and give them time/opportunity to migrate away from using empty regions.
So is the recommendation to use the resolveEmptyRegions config? (We run on Enonic Cloud, so this is something we must request, we can’t do it ourselves, so I just want to make sure it is something worth requesting before we do so.)
The issue we encounter is probably a different one from the bug in the discussion you link to. Our issue is that we see a lot of JavaScript errors in the console, and they seem to be related to empty regions somehow. And when there are enough of those errors, it seems like Content Studio slows down a lot, in some cases so much that it becomes unusable. A work-around is to refresh the page, but a more elegant solution is preferable.
Bjørn. AFAIK, the change related to empty regions would generally not affect developers that use standard XP templating setup, where each region is predefined in your views.
It is more relevant if people have been implementing their own page rendering / templating logic, i.e. headless. Basically, if this change is a problem for you, the page editor / content studio should be failing, not get slower.
The new solution increases performance of every single getContent significantly, turning on resolveEmptyRegions will actually slow things down - so this sounds like the opposite of what you’re struggling with? But hard to say anything more based on this input. Also, you should easily be able to test the affect of toggling this setting in a local dev environment to see if things change.
Right, we will ignore that config setting. I was just trying to understand what it actually does, but I agree, it sounds like activating it could potentially actually make things worse. The description is still a bit vague, though.
The problem we see is not consistent. Sometimes we get browser console errors, sometimes we don’t. It seems like it typically happens after drag-and-dropping components between layouts, but there’s no obvious pattern in that either.
We’ll keep trying to narrow it down to a more accurate and reproduceable case, and get back to you when we have it.
I see that the description is unclear. It is basically that empty regions were included in the page property of a content item. An empty region is not persisted, so this was (mistakenly) calculated back in the days. Now what has been removed, speeding up every content access.
This would only have caused issues for developers relying on that information to be available in the page tree.
Right now I can’t invoke the demons that I think are most relevant, but we will look into it more next week and share them here. The only one I see right now is here, so feel free to guess based on it, but I do hope we can share something better soon.
