This is a follow-up post to my prior two blogs on content resolvers and the issues we've run into with them in play. I felt it was important to share this information with the community, especially as in the days since I wrote the blogs, I actually saw folks posting about using the content resolvers, and I wanted to warn them off.
First bit of news, we've had some a small testing group testing our alterations on a QA instance, and I'm pleased to report that so far, Edge publishing is working as expected again. To be clear, when you have Edge publishing (AKA v2) running, you should be able to change an item, like a datasource or a subitem to a datasource, and have associated page(s) reflect that change to Edge with only publishing the changed item in question. For example, we have a masthead datasource that's connected to a rendering in a partial view in a shared site, and I made a couple of changes to it and did a smart publish. When I check the Edge Playground for the homepage of my specific site, I see the change reflected. And when I refresh the page after a Netlify revalidation period, I see the change reflected on the front-end as well.
To be clear, content resolvers do work. But their use has the effect of putting your site into the original "v1" publishing state, where you'll have to republish your site to get things to render out. This was the whole reason Sitecore invented the Edge publishing model, to bring things closer to the "legacy" model that clients came to expect...change and publish something, it appears.
So this morning, we received this back from Sitecore Support. I wanted to share it, as I believe it justifies the effort we went through (and these blogs), and also it is going to result in documentation changes on their end. I should also give Support a lot of credit, as they diagnosed the issue based on a specific case we provided them among publishing frustrations that we were experiencing...it ended up being the string to pull on to untie the proverbial knot, it seems. So big kudos to them!
After a thorough review of the current architecture, we have to admit that there doesn't seem to be a straightforward way to change the behavior associated with the Navigation Resolver without needing to republish a large number of additional entities. As a result, rendering content resolvers are currently considered incompatible with Edge runtime publishing. We will update the documentation accordingly to reflect this. Thank you for highlighting this point.
For navigation components, we recommend you consider using either one of the following approaches:
Use the "Component Level Data Fetching" approach described in the Performance-optimized page listing article. This way, you will be able to handle rendering parameters in your component and modify the query to fetch the needed data.
Alternatively, you can use integrated GraphQL as mentioned earlier. However, please note that this approach doesn't allow integrating rendering parameters into queries.
The methodology they describe in item 1 is what my last blog on the navigation resolver was all about. Fair warning: the out-of-the-box Navigation rendering that ships with Sitecore XM Cloud - or maybe some starter kits in the Content SDK era - uses the navigation content resolver, so if you're thinking of using it, I advise against it.
I'm glad we were finally able to slough through this for our client, and I really hope this information helps out others in the community. Cheers!
Top comments (0)